Skip to end of metadata
Go to start of metadata

This document will help prepare you to build the source code for illumos. It assumes some familiarity with development on Unix-like systems.

You need an illumos-based operating system to build illumos (cross-compilation is not supported). If you don't have one installed, the quickest way to get started is to download and install OpenIndiana from openindiana.org/download, possibly into a virtual machine (compilation performance may suffer, but it is functional). Some other distributions support self-hosting, including compilation of illumos-gate, as well. If you have an existing system with OpenSolaris installed, see Updating OpenSolaris.

Note: All commands in this guide assume you run them as an unprivileged user. sudo will be prepended to commands which need additional privileges; on some systems pfexec can be used instead, if your user has the correct RBAC profiles. The generic commands below use a $USER variable to define the current (unprivileged) user account's name which will ultimately be used to compile the project. If you are not using a stock shell or have manipulated the $USER variable in your environment at a site, system, or user level, you are responsible for diagnosing and addressing any consequences.

Note: VirtualBox has proven unfit for purpose in building from source (builds can take days instead of hours) and running debug kernels (systems have problems with clock discipline and are slow or become unresponsive). If you're interested in developing for illumos, consider running on bare metal or using an alternative virtualization product (KVM, VMware, Xen).

Update (2013-06-28): Some users have reported reasonable build times with recent (>= 4.2) versions of VirtualBox on recent Apple hardware. It is as yet unknown what specifically changed to resolve the issue, but presently it appears that recent VirtualBox may be more feasible. Until we know the specifics, consider VirtualBox unsuitable or experimental at best. More testing welcome! This only applies to building illumos, and not running debug kernels.


Installing required packages

You need to install these packages in order to build illumos:

Shell: Installation of packaged dependencies for build

Installing compilers

The source code was traditionally built using Sun's closed-source compiler suite, which was named Sun Studio at the time of the illumos fork.  We now build illumos with GCC, but you will still need some tools from Sun Studio and those are available as packages in the legacy OpenSolaris repository.

GCC

The primary version of GCC necessary for development and integration 4.4.4 (4.4.4-il-3) should have been installed on your system when you installed the prerequisites above.  If for some reason that didn't happen (old build system, or the like), tarballs are available as described in the initial heads-up notice  2012-06-15 Illumos will now build with GCC 4.4.4 + patches.

Note that the compiler for building illumos-gate installs into /opt/gcc/4.4.4 and is not available in the default PATH for building application programs. You can add PATH="/opt/gcc/4.4.4/bin:$PATH"; export PATH to your profile to reference this compiler, or install one of the other GCC builds, destined as the current default compiler for application programs (versions ranging from 3.4.3 to 4.6.x, see pkg info -r '*gcc*' for details du-jour).

Unfortunately, Sun Studio dmake (Distributed Make) and lint are currently required even for GCC-only builds. We currently deliver Lint libraries built using the closed Sun Studio version of lint.  The lint from the unpatched (but redistributable) version of Sun Studio 12.1 in the opensolaris.org repository can be used, regardless of its utility for actually checking the software.

Run:

Sun Studio compilers

If you wish to build with Sun Studio, you need specifically patched versions of both Studio 12 (used to compile) and 12.1 (used for lint) to get consistent results. These are no longer distributed by Oracle and can not be legally found in the open Internet. If you do not have access to these versions, skip this section and use GCC.

illumos-gate does not build correctly with Sun Studio versions released after 12.0. Reportedly using a newer version of the compiler will produce a system containing grave, data-corrupting bugs.  Patched compilers were previously available from Sun Microsystems, however not licensed for redistribution. After a recent Oracle site reorganization, the necessary compilers are no longer available.

If you have the patched versions of both Sun Studio 12 and 12.1, they should be installed in /opt/SUNWspro (Studio 12), and /opt/SUNWspro/sunstudio12.1 (Studio 12.1), respectively. Pay attention, the Studio 12.1 location is different from how it was in OpenSolaris, i.e. it's not /opt/sunstudio12.1.

The meta-procedure for cleaning up optionally prepackaged Sun Studio installations and installing the ones you require for building illumos (assuming your stashed Sun Studio 12 distribution archives are now pre-copied to /tmp) is as follows:

The first archive contains the product component sub-directories directly at the top-level, and the second has similar sub-directories under the top-level sunstudio12.1 as its children. Thus you receive the structure outlined above.

You can check if you have the correct versions installed as follows. All of the following tests must succeed and return these specific product/patch versions:

You must then adjust your nightly(1) environment file (i.e. by adding a line in illumos.sh) to specify that Studio should be used as the default compiler, by adding:

Building illumos

Preparing the source-code directory

You can use any location, but for the purposes of this guide, we will assume that you have a directory /code owned by your user ID, which you are using to obtain source and build.

For a less naive example, see the Build datasets page and some more industrious details on Managing multiple workspaces and Working on several bugs at once.

Getting the source

You may use the Git or Mercurial source code management systems to retrieve the illumos source code. Both tools will be able to retrieve the same history. Ensure about 6 gigabytes of free space for the source and binaries combined.

Note that currently the origin of illumos-gate development is the GitHub repository (or its easily created forks) used by one or another distribution, such as OpenIndiana Hipster; some other distros, like OpenIndiana Dev releases, still use Mercurial as the main repository but may migrate to Git in the future.

Getting the source with Git

The repository is available from GitHub using the Git source code control system.

The Git repository URI is: git://github.com/illumos/illumos-gate.git

Or, if the Git protocol is firewalled at your site: https://github.com/illumos/illumos-gate.git

The illumos-gate source can then be cloned using:

Getting the source with Mercurial (hg)

illumos.org hosts a Mercurial repository containing the illumos source code.

The Mercurial illumos-gate URI is:

Additional Mercurial mirrors:

Mercurial pulls a complete replica (clone) of the repository, including all history, from a remote source, and then updates a working copy of the files from this clone. The working copy is the files you may edit and compile. You may update the working copy from any versions of files in the repository history.

When cloning an external source code repository, Mercurial starts by creating a new directory, and fails if one already exists and is not empty. The directory may be a mountpoint for an empty ZFS dataset. Mercurial creates a .hg directory under this to store the repository history. After the history has been fully populated, a working copy of the files is deposited in the parent directory.

The following example creates a clone of the "Mercurial repository" ssh://anonhg@hg.illumos.org/illumos-gate containing the illumos source code under /code; this will create a sub-directory illumos-gate under that.

Updating the source with Mercurial

If you want to get latest version of illumos-gate merged with your private development code, you need to hg pull new changes into your clone and hg update the working copy. This can be done in one command as hg pull -u. If you have committed changes prior to updating, you may be wish to hg merge them with the new changes.

For more details see: http://mercurial.selenic.com/wiki/FAQ.

There is also a simple script to update the repository.

Getting closed binaries

There are still closed components in illumos that have not yet been replaced. You must get the latest closed binaries from Sun/Oracle, since illumos currently needs those in order to build:

Note that if you had a crypto tarball from an earlier build, do not use it here, as it is no longer required to build illumos. You should remove it from your tree if already present.

According to the gcc-4.4.4-il heads-up note, the kernel modules among the closed binaries might need some fixup for proper compilation. According to several developers, however, they've never needed to do this in practice. Just in case you are trying to build some older branch of illumos which might require this modification and inexplicably breaks without it, the steps are outlined below in the troubleshooting section.

Preparing the build environment

General build configuration

The build is configured using a shell script with environment variables, a template for this file is included:

The settings we are going to focus on for now are the following:

  • NIGHTLY_OPTIONS - You may remove the "l" (lowercase L) option from the string, this will disable lint checking of the code to save some time during the build, but patches should be linted.
  • CODEMGR_WS - This should be the root of the directory with the code. If you followed the previous example, it will be /code/illumos-gate.
  • STAFFER - Change this to the name of the non-privileged user you use on the system
  • VERSION - Set this to illumos-gate or whatever version string you want for the build

ImportantONNV_BUILDNUM specifies the build number which is used in packaging. If you intend to upgrade a system whose build number is greater than the one in illumos-gate (currently 148), such as OpenIndiana, you need to specify this to allow upgrades until issue #1118 is addressed. Run:

If you see, for example, "Branch: 0.151.1", you must choose a number greater than the part after the leading "0.". For example, add

to the illumos.sh script.

Building with only GCC-4.4.4-il (i.e. without using Sun Studio at all)

If you are building with solely GCC 4.4.4 (i.e. you do NOT wish to use Sun Studio at all), you must append these lines to the end of illumos.sh:

This should suffice for compilation of modern illumos-gate sources executed on a modern distribution. Older branches (circa 2012) might need some more setup which, along with explanation of the options, can be found below in the troubleshooting section.

We understand that the required version of Sun Studio is no longer publicly available and will accept contributions that were tested only with GCC.

 

Starting the build

You are now ready to start the illumos build.

Since this process may take up to several hours depending on your system (reference build times are in a chart below), it may be wise to start the build job in a VNC session, GNU Screen (screen), or tmux. The screen program can be installed with the pkg:/terminal/screen package.

Run the following command to start the full build:

Note that the command does not give any progress output. You can instead follow the log file at log/nightly.log, which is updated (slowly) during the build process. In another terminal, run:

To only track the running build for warnings and errors you might instead run:

After the build is complete, the nightly.log file and some other generated logs are moved into a uniquely named subdirectory log/log.$TIMESTAMP/ (i.e. /code/illumos-gate/log/log.2012-04-20.04\:17/ ).

A dry overview of the build progress (hopefully small – about 2KB in size – with no errors) is saved in log/log.$TIMESTAMP/mail_msg file intended for mailing to the build administrator after the build completes (this automation is out of the scope of the nightly.sh script). If you do receive any errors in the mail_msg report file, you can grep the error lines in the larger nightly.log file.

Performing an incremental build

If you've made changes after completing a nightly build, you can perform an incremental build without discarding the already built files.

To make this the default, edit illumos.sh and add the character i to NIGHTLY_OPTIONS.
Before submitting a patch, we request that you perform a full, non-incremental build including the lint stage.

Building specific components, and other info

Installing built software

Installing the nightly build on local machine with onu script

The build process will generate updated packages. Depending on the NIGHTLY_OPTIONS variable in illumos.sh script, the packages will be written either to $PWD/packages/i386/nightly (with debug, the typical default) or to $PWD/packages/i386/nightly-nd (without debug). Therefore there are two possible commands to install the software you you just built. You need choose the proper onu command, typically the first one listed below.

Typical install: you can install with onu for debug builds (the default, with 'F' and 'D' characters in NIGHTLY_OPTIONS variable in illumos.sh):

The non-typical installs are detailed in the following pages:

Possible problems

In any case, if you have build errors or other "inconsistencies", it would be wise to revise the mail_msg logfile that can contain short error descriptions, and grep for those errors in the longer nightly.log file. If that doesn't help, you should also recreate the build in a "clean lab" environment, which may be set up as a local zone according to the Building in zones instructions and rule out the local environment's influence (conflicting libraries and binaries, perhaps from your own earlier builds, come to mind first).

Localization bugs #167 and #168

illumos has entirely different localization infrastructure from Solaris, so your existing system locales will not work.

The English locales for illumos are in pkg:/locale/en (NOT pkg:/system/locale/en), and if you wish to use them, you'll need to install that package after you reboot. Likewise, other locales are in pkg:/locale/<language code> where <language code> is a two letter ISO 639-1 code, except for zh_cn/zh_hk/zh_mo/zh_sg/zh_tw.

If your locale is not installed, it will cause problems with software which behaves badly if setlocale() fails. This includes, at least, time-slider and svcs(1M). The pkg(5) commands print a warning, but function normally.

If this is a problem, you can  "export LANG=C LC_ALL=C" as a workaround, and change the LANG setting in/etc/default/init to 'C' (and reboot) to make the change permanent.

Package repository (path /code/illumos-gate/packages/i386/nightly/repo.redist) is not created and onu script fails

This error has happened to me whenever I ran the default checkout and full-build procedure outlined above (in VirtualBox VMs); I don't yet know why (possibly due to a wrong setup of my SunStudio compiler stack, as was later discovered).
However, rerunning with an incremental build has created the package repository correctly (as well as full builds with proper SunStudio setup):

Fixing the closed binaries for GCC-4.4.4-il

According to 2012-06-15 Illumos will now build with GCC 4.4.4 + patches the closed binaries should be fixed for compilation of illumos-gate with the newer gcc-4.4.4-il compiler. However, several developers stated that they've never needed to do this for current versions of illumos-gate (as of March 2014).

Just in case, the command to run is:

Ensuring a build with only GCC-4.4.4-il for older branches of illumos

Current illumos-gate (as of March 2014) should compile cleanly with GCC with the simplified instructions above. However, some earlier versions of the gate needed more configuration steps to compile properly, and the settings below shouldn't break anything for the newer source code as well (wink)

If you are building with solely GCC 4.4.4 (i.e. you do NOT wish to use Sun Studio at all), you must append these lines to the end of illumos.sh:

Explanation of these settings:

  • CW_NO_SHADOW - Set this to 1 to prevent the shadow compiler from running (for instance, if you do not have Studio at all, in which case a regular build would fail due to "cw: error: couldn't run /opt/SUNWspro/bin/cc (No such file or directory)" and inability to run the shadow compilation and thus verify the fitness of code for both supported compilers).
  • ONLY_LINT_DEFS - This is needed so the lint is able to find the proper note.h include file.
  • If __GNUC is defined, then a GCC would be the primary compiler. If __GCC4 (or legacy __GCC3) is defined, then the particular version of the compiler is used. Remember to unset __SUNC to properly use just one primary compiler (wink) and use CW_NO_SHADOW=1 as described above to completely disable a secondary (shadow) compiler.

The last two lines make sure the patched version of GCC-4.4.4 is used (the default gcc version shipped with e.g. earlier OpenIndiana, gcc-3.4.3, is not suitable for building illumos), as described here.

If you are trying to build with GCC 4.4.4 and your build fails because of some invalid GCC warning options, try setting the variables GCC_ROOT and CW_GCC_DIR as shown above and described here.

While recently rebuilding a historical 2012 version of illumos-gate with GCC-4.4.4-only setup per instructions above, I've still got Sun Studio errors in my mail_msg file like:

 or more frightening:

 However, the files in proto/ and packages/ were created successfully. So... even error reports may need manual verification before panic and frantic fixes (wink)

Build times

As a convenience, we will try to assemble some build times for various hardware configurations here, so you can get an idea in advance of how long it will take:

Processor(s)No. of coresMemoryTime (HH:MM)Notes
2 x Xeon X5570 2.93GHz2 x 436 GB00:19NIGHTLY_OPTIONS='-FnCDmprt'
4 x Opteron 6172 2.1 GHz4 x 12128 GB00:21NIGHTLY_OPTIONS='-FnCDmprt'
Xeon E3-1270 3.4 GHz416 GB00:23NIGHTLY_OPTIONS='-FnCDmprt'
Xeon E3-1245V2 3.4 GHz416 GB00:31NIGHTLY_OPTIONS='-FnCDmprt'
Core i7-2600K 3.4 GHz48 GB00:35NIGHTLY_OPTIONS='-nClmprt'
2 x Xeon E5620 2.4 GHz2 x 448 GB00:38None
1 x Xeon E5607 2.27GHz1 x 412 GB00:46NIGHTLY_OPTIONS='-FnCDmprt'
Xeon E3-1245V2 3.4 GHz416 GB00:47NIGHTLY_OPTIONS='-FnCDlmprt' (with lint)
2 x Xeon E5540 2.53 GHz2 x 424 GB00:50With lint
2 x Xeon E5506 2.13 GHz2 x 424 GB00:50No dmake check
1 x Xeon X5650 2.67 GHz1 x 612 GB00:51With lint, default NIGHTLY_OPTIONS
2 x Xeon E5506 2.13 GHz2 x 424 GB01:03None
Core i7-960 3.2 GHz49 GB01:03With lint
2 x Xeon E5506 2.13 GHz2 x 416 GB01:06VMware Workstation guest
Core i7-930 2.8 GHz48 GB01:07VMware ESXi guest
Core 2 Quad Q6600 2.4 GHz42 GB01:16None
2 x Xeon E5310 1.6 GHz2 x 432 GB01:24None
1 x Athlon II X2 240 2.8 GHz22 GB01:27NIGHTLY_OPTIONS='-FnCDmprt', on a low end SSD
Core 2 Quad Q9300 2.5 GHz47 GB01:32None
2 x Xeon E5420 @ 2.50GHz2 x 44 GB01:33Default NIGHTLY_OPTIONS; an incremental rebuild takes 13 min to walk all Makefiles
2 x Opteron 2218HE 2.6 GHz2 x 216 GB01:42None
Core i5-540M 2.53 GHz24 GB01:54None
Core i3-370M 2.40 GHz22 GB02:30None
Core 2 Quad Q8200 2.33 GHz45 GB02:30Default NIGHTLY_OPTIONS.
Core 2 Duo T8300 2.3 GHz (T61)22 GB02:58VMware Workstation 2 CPUs
Core 2 Duo E6750 2.66 GHz28 GB02:59Sun Ultra 24 (with lint)
Core 2 Duo Celeron E3200 3.2 GHz24 GB03:282.4 GHz CPU over clocked to 3.2. Everything running on a low end SSD. With lint.
Core 2 Duo T5600 1.8 GHz23.3 GB04:26None
Opteron 146 2 GHz14 GB07:28None
4 x Dual-Core Opteron 8218 2.6 GHz (8-vCPU VM) 16 GB (2GB VM)35:47 + 9:05VirtualBox 3.0.12 VM, with 8 vCPUs and 2GB vRAM; local vHDD; with lint and default NIGHTLY_OPTIONS='-FnCDlmprt'

NOTE: Package repo did not get built at all with the first nightly run, only with the second, incremental nightly run (another 9 hours)

 

Notes:

  1. "Bare Metal" just slightly faster than VMware guest. On the other hand, VirtualBox painfully slow.
  2. More cores faster but not linear increase.
  3. SSD use seems to provide nice speedup.
  4. As expected, lint checking results in longer build times.

 

 

Labels:
  1. May 19, 2012

    This piece of advice fell off the official document, but I think it is important (as the default oi_151a bash does not have $USER on my and at least one other user's machine, at least after changing privileges via "sudo su -" for root elevation or "su - username" for lowering the privileges).

    Throughout this manual and subsequent pages, the $USER variable is supposed to mean the username of your non-privileged user account used to download and build illumos software. This account should have configured a means of privilege elevation for system commands, using susudo or Solaris RBAC pfexec.

    This variable may be or not be predefined, depending on your shell program and ~/.profile or other profile files, or some other aspects of system configuration and the installation methods used.

    If you don't have the variable in place, you can define it with such a block in your user's profile or system /etc/profile, but we must disclaim that you are responsible for diagnosing and addressing any consequences:

    UPDATE: As other authors below note, the default OpenIndiana installation should have the variable defined in the first place.
    Alternatively, less clumsy methods of getting the user name are available in OpenIndiana, including "/usr/bin/id -un" and "/usr/bin/logname".

    HTH,

    //Jim Klimov

    1. May 16, 2012

      funny, I have $USER and haven't ever really mucked with things there...

      If $LOGNAME isn't defined, whynot `/usr/bin/logname` ?

      Strange though, because according to the 'login' manpage:

           The basic environment is initialized to:

             HOME=your-login-directory

             LOGNAME=your-login-name

             PATH=/usr/bin:

             SHELL=last-field-of-passwd-entry

             MAIL=/var/mail/

             TZ=timezone-specification

      If not attached to a terminal, I see your point.  Perhaps in this case something like `/usr/bin/id -un`  might be easier...

       

      1. May 18, 2012

        Well... as for "id -un" – that option is not available even on Solaris 10 (and older too), where the snippet above originated (wink)

        As for the logname, it seems tricky... here an ssh login to jack was made, followed by "sudo su -":

        (The snippet above for setting $USER is not in jack's nor root's profile, my build user is separate)

        1. May 19, 2012

          id -un works on illumos. If Solaris 10 is mentioned as a joke, it's a pretty bad one. To the best of my knowledge, jack only exists on installation media, which isn't suggested anywhere as a build environment. Also, sudo will set LOGNAME and USER appropriately unless the default set_logname behavior is negated, where building with sudo from jack on installation media isn't something that's recommended anywhere in any case. It's not clear to me whether we're talking about legitimate corner cases here or over-the-edge ones.

          Also: the account used to build illumos does not need means of privilege escalation to build illumos, and it's probably sound practice not to assign such privileges to an account responsible for automated builds. Installing the bits and preparing the build environment are quite different questions, but the essential distinctions are not clearly called out and seem rather badly muddled.

        2. May 19, 2012

          Well, first of all, thank you both for pointing me to this feature in id – i truly did not realize it is available.

          Regarding the "Solaris 10 and older" reference, part of my job is interoperability - to make sure things "just work" identically in a range of environments, from Solaris 8 to OpenIndiana, as well as in RHEL 5-6. While our other team members make their applications and j2ee servers, I make tons of scripts, profiles and init/SMF methods, to make all those assorted environments seem similar to the apps we launch. It is preferable to maintain just one script body (Sun did so too i.e. in multiplatform SRSS) and use the lowest common denominator like that clumsy textual parser for common id output.

          I hope this piece of explanation sorts it out for the case in question, and I'll try to keep clumsy interoperability cludges like that from polluting the main illumos-and-OpenIndiana documentation if there is a simpler solution and I know of it.

          As for giving the build user permissions to elevate privileges (the need for $USER in the first place) – it was there when I first came to these docs, so I kept and enhanced this part as I could (wink)

          Finally, I concur with the assessment that my installation that I tested the snippet on does deviate from the official installation method from LiveCD (due to HW problems I could not complete an installation from the media, but could mount the ISO over NFS and rsync from it, as I detailed on the Wiki, and things seem to work). I have re-tested the snippets Richard tried below, and results match – the $USER is only lost on "sudo su -", which I do use, so it is not the illegitimate corner case stemming from my installation method. I am not sure what was different/non-standard on the other user's installation.
          BTW, is there a technical specification of what the installer does (i.e. to implement other compliant and compatible installation methods, including manual copying of files from media or another installation a-la-flar)?

          1. May 19, 2012

            sudo su - is absolutely an off-the-edge corner case for purposes of this document, which tells you either to use pfexec or sudo to escalate privilege for an enumerated set of operations to set up the build environment. That's to say: you're running specific commands, not switching to a privileged shell and depending on its environment.

            As we've agreed elsewhere that any environment variables applicable to the current user that are passed to these commands will be interpolated to their current settings, is there any remaining relevance to talking about either USER or LOGNAME here?

            1. May 19, 2012

              > That's to say: you're running specific commands, not switching to a privileged shell and depending on its environment.

              Well, my private procedure happened to differ, as we've now noticed (actually SUing from root into the build user without a permitted interactive login via lack of password, and trying these procedures afterwards). And I might not be the only one like that, since I was asked to add the piece on defining an absent $USER in the first place.

              > is there any remaining relevance to talking about either USER or LOGNAME

              I guess not, and if you have the admin privileges on the Wiki - i agree to having most of this thread removed (to an attic?) for readers' clarity, except for my first post with the workaround – for those people whose ways for any reason deviate from the ivory-tower/greenhouse environment described and expected in the trunk of the documentation (same as "/code is expected for workspaces", but you can also make zfs hierarchies or even whole local zones to similar effect and some benefits although adding complexity too much for the main document to talk about it in detail). Not all is lost for those pesky creative people, and they should know it (wink)

  2. May 19, 2012

    Hmmm, digressing a bit, but does this reveal a bug or perhaps an esoteric feature?

    Why is $USER != /usr/bin/id -un and, separately, $LOGNAME != /usr/bin/logname below?

    updated...

    ~$ echo "LOGNAME='$LOGNAME' /usr/bin/logname '`/usr/bin/logname`' USER='$USER' /usr/bin/id '`/usr/bin/id -un`'"

    LOGNAME='richard' /usr/bin/logname 'richard' USER='richard' /usr/bin/id 'richard'

    ~$ pfexec echo "LOGNAME='$LOGNAME' /usr/bin/logname '`/usr/bin/logname`' USER='$USER' /usr/bin/id '`/usr/bin/id -un`'"

    LOGNAME='richard' /usr/bin/logname 'richard' USER='richard' /usr/bin/id 'richard'

    ~$ sudo echo "LOGNAME='$LOGNAME' /usr/bin/logname '`/usr/bin/logname`' USER='$USER' /usr/bin/id '`/usr/bin/id -un`'"

    LOGNAME='richard' /usr/bin/logname 'richard' USER='richard' /usr/bin/id 'richard'

    ~$ pfexec bash

    ~# echo "LOGNAME='$LOGNAME' /usr/bin/logname '`/usr/bin/logname`' USER='$USER' /usr/bin/id '`/usr/bin/id -un`'"

    LOGNAME='richard' /usr/bin/logname 'richard' USER='richard' /usr/bin/id 'root'

    ~# exit

    ~$ sudo su -

    OpenIndiana (powered by illumos)    SunOS 5.11    oi_151a4    April 2012

    ~# echo "LOGNAME='$LOGNAME' /usr/bin/logname '`/usr/bin/logname`' USER='$USER' /usr/bin/id '`/usr/bin/id -un`'"

    LOGNAME='root' /usr/bin/logname 'richard' USER='' /usr/bin/id 'root'

    ~# exit

    ~$

     

    1. May 19, 2012

      (Explanation that may be needed for other readers) Your first tests all report "richard" because the expansion of shell variables and execution-output substitutes take place in the context of the user who calls the shell command line, before sudo or pfexec are executed. Essentially they execute "echo" with root privileges and a predefined string constructed by the non-root user. This is basically what we want to happen in the privilege elevations throughout the page.
      The last two tests are correct in form, by first executing a subshell, and present the interesting discrepancies in variables and outputs.

      I've also run these tests on my non-default installation and got same results modulo non-privileged user's name.

      Here is one more piece Richard missed:

      So, it seems to be a problem with "su" unsetting the env-vars or keeping them in place (as requested by the dash parameter) – no further program or profile (re-)defines them to something else (i.e. "root").

      /usr/bin/logname seems to retain the value of the user who originally started the shell, i.e. via SSH, throughout the privilege elevations, which may be a good thing for these installation routines: we can elevate privileges once (spawn a shell), set up all needed stuff, and use this program's output to chown (or you'd rather use the ZFS ACL permissions available in OpenIndiana?) and perhaps zfs allow accesses to the specific user we logged in with in the first place – if that matches our wishes.

    2. May 19, 2012

      The problem isn't misbehaviour, it's that variables are interpolated before being passed to sudo. Thus if you take the same thing and make it into a script, you won't have any problems using sudo. The su man page explicitly states that "su -" is meant to behave as though it were a login shell. pfexec isn't changing the user, so you wouldn't expect it to muck with the environment.

  3. May 29, 2012

    Why do we advise on using /code (or, at least, are using in examples) while default illumos.sh sets WS to $HOME/ws/$GATE? Wouldn't it be better to switch examples to ~/ws?

    1. May 29, 2012

      ...with the default GATE="testws"
      I also thought about this, but by the time I got to the Wikis, the "/code" example was already in place in several papers. I confess, I added some more such examples (wink)

      I do agree that somehow aligning the documentation with the script defaults (and requiring minimal to zero change of illumos.sh at that) would be beneficial. Still, the examples on Build datasets can stay in place for people Managing multiple workspaces, while zfs-clones of the golden code repo would become the build user's ~/ws/illumos-gate mountpoint.

  4. Aug 16, 2012

    The warning about slow builds on VirtualBox does apparently only apply on older CPUs without nested page table (EPT) and VPID support. I've done a full build inside a 6-vCPU machine on an Intel Xeon X5670 yesterday, and it took close to an hour.

  5. Feb 21, 2013

    Hi everyone.

    I am new to illumos, but i want to know more about illumos.

    These days, I built illumos on my openindiana  following this elegant guide.

    ---------------------------------------------my openindiana----------------------------------------------

    root@openindiana:~# cat /etc/release

                 OpenIndiana Development oi_151.1.5 X86 (powered by illumos)

            Copyright 2011 Oracle and/or its affiliates. All rights reserved.

                            Use is subject to license terms.

                               Assembled 26 June 2012

    root@openindiana:~#

    ------------------------------------------------------------------------------------------------------------------

    After nearly 7 hours, the building process finished. I used the following command

    time ./nightly.sh illumos.sh

    ------------------------------------------------------------------------------------------------------------------

    As "10 steps to building ON on OpenIndiana" said:

    Check the results (mail_msg logfile should be about 2Kb small in size and contain no errors/warnings; if it does – research the bigger nightly.log to see what went wrong in your build).

    May be I succeeded in building illumos, didn't I?

     

    and then I used this command:

    ./usr/src/tools/scripts/onu -t nightly-`date +%Y-%m-%d` -d $PWD/packages/i386/nightly

    to install the nightly build.

    When installation finished, I restart my computer. I was happy to see a new item appears on grub:nightly-2012-1-13.

    I got into the new system. Still i found that the golden bird logo instead of the Oi logo.

    May i  succeeded?

    Did i switched to the new kernel i just built?

    if yes how can I know the information about the new kernel?

    uname -a  shows that it is still openindiana. I was disturbed...........

    if not i am eager to know  the things that i have missed....

     

    I am looking forward to your reply.

     

    Thanks very much.

     

     

     

     

     

     

     

     

    1. Jan 17, 2013

      Hey,

      First up, I think it's probably best to ask these sorts of questions on the illumos-developer mailing list, where it will receive the widest qualified readership.

      I suspect you have missed setting ONNV_BUILDNUM in your illumos.sh environment file.  That would prevent onu from upgrading to your newly built packages, because IPS does not believe them to be newer than what's on your system.  If you can paste your environment file into http://gist.github.com or some other pastebin, then we can take a look.

      Cheers.

      1. Jan 20, 2013

        Thank you. And i am sorry to reply  here. I will ask this question on the  mail list soon .

        Here is my illumos.sh.

        https://gist.github.com/4578234

        Please take a look.

        =======================================================================

        root@openindiana:~/illumos/code/illumos-gate# pkg info osnet-incorporation | grep Branch:

                Branch: 0.151.1.5

        root@openindiana:~/illumos/code/illumos-gate#

         and ONNV_BUILDNUM=152

        =======================================================================

        May be it's just ok...

         

         

  6. Feb 05, 2013

    cxu

    Hi all, although maybe it's better not question here, but I've meet a problem seems to be general.

    I just wanna build illumos kernel in Openindiana 5.11 oi_151a7 i86pc i386 and etc. And setup step by step just as the article desc and get the log Error says:

    /usr/sfw/bin/gcc

    cc1: error: unrecognized command line option "-Wno-missing-field-initializers"

    cc1: error: unrecognized command line option "-Wno-type-limits"

    and so on.

     

    I guess this maybe the error case by using the system default gcc version installed by pkg install step as the guide first noted, but I've got no gcc setup in illumos.sh. Anybody know how to setup gcc build with Sunstudio 12 compiler and Sunstudio 12u1 lint?

     

    Thx

     

    1. Feb 05, 2013

      Hi there,

      It is best to ask these sorts of questions on the Mailing Lists.  As this is a question related to building and developing illumos, it would probably be best to send it to the illumos-developer list.

      Thanks.

    2. Feb 05, 2013

      hi cxu

      It is best to ask these sorts of questions on the Mailing Lists. 

      If you have "/opt/gcc/4.4.4" on your openindiana, try add the following to your illumos.sh

      ----------------------------------------------------------------

      GCC_ROOT=/opt/gcc/4.4.4

      export GCC_ROOT

      CW_GCC_DIR=${GCC_ROOT}/bin

      export CW_GCC_DIR

      -----------------------------------------------------------------

      good luck