Initial Experiments with OpenSolaris Base Install Profile
By ckamps on Oct 21, 2009
This post is a follow-on to the entry describing how to set up an OpenSolaris Automated Installer (AI) environment using the JeOS prototype and VirtualBox. In this entry I describe how to use a custom AI manifest representing an experimental base installation profile to install a greatly reduced or minimized form of OpenSolaris in a VirtualBox virtual machine - just ~90 or so packages and an installed footprint of ~570 MB. The resulting installations are text-oriented, headless server installations containing only enough features to enable developers to add more packages and customize the environment to suit their specific needs.
A slightly modified form of the AI manifest can be used to realize similarly reduced installations in other system virtualization and bare metal environments.
Experimenting with base installation profiles is part of the OpenSolaris JeOS project's effort to help define a formal base installation profile for OpenSolaris.
Base Installation Profile
The notion of a base installation profile is familiar to Solaris and Linux users that are keen to deploy their applications on top of heavily reduced or minimized OS installations. Such a profile is typically the smallest set of features that are generally supported for the OS. An early draft of a base installation profile specification for OpenSolaris is in progress in the OpenSolaris JeOS project and provides more background and one view of the features that might make up a base installation profile.
JeOS - Just enough Operating System
JeOS, or Just enough Operating System, is the notion of developers being able to start with a base installation profile and customize it by adding only those features required by their particular application. Using a formally supported base installation profile enables developers to deliver stacks of software that are built on a solid, supported foundation.
The JeOS project is exploring and demonstrating ways in which developers can realize JeOS-based installations. Providing ready-to-run JeOS "building block" VM images is one example of how the project is helping developers quickly deliver their own application-specific appliances. Helping to spur the formal definition of base installation profiles along with supporting base install profile meta packages and Automated Installer examples are other examples of where the JeOS project is making contributions in this area.
What's the difference between a base installation profile and the JeOS building block VM images?
The JeOS building block VM images contain a modest number of additional features beyond the bare bones or minimalist base installation profile. For example, the DTrace Toolkit and several other features that developers would typically use are included in the example JeOS images, but are not part of the minimalist base installation profile. Beyond containing a handful of additional features and their supporting packages, the JeOS images are also configured to provide a more hardened environment and to help enable appliance developers to automate customization of the images for their own application needs. See the JeOS documentation for details.
In the future, the JeOS building block VM images will at least be built on whatever formal base installation profile emerges in OpenSolaris. Doing so will help ensure that these examples are using a formally supported starting point.
Recap of the Install Environment
In this example we're using an Automated Installer environment in which the AI server used a JeOS VirtualBox VM image as it base and empty VM images as the install clients. The latest OpenSolaris development build 126 underpins the install server and is the version of AI ISO image executed on the install clients. This deployment is documented in the earlier blog entry.
Initially, the example uses a remote package repository as the source of the package content. In a later blog entry, I described how to significantly improve the installation process by using a heavily reduced repository colocated on the install server. Even though this a minimized form of OpenSolaris is being installed, there is a significant amount of package content to download from the remote package server.
Using a Custom AI Manifest
As a demonstration of an early form of a base installation profile, a custom AI manifest was created to specify only those packages pertaining to features outlined in the draft base installation profile specification. Beyond the bare bones base set of features, several drivers were added to enable the installation to operate in a VirtualBox environment. Eventually, base installation profiles will be represented in the form of pkg(5) metapackages, but for now this example simply lists the packages directly in an AI manifest file.
So as to remain on the cutting edge of OpenSolaris development builds, the AI manifest specifies the OpenSolaris development package repository and lists packages that are compatible with that iteration of the OS. Since dependency specifications and even package names are evolving across development builds, the manifest used in this example won't necessarily work when using earlier builds and the base 2009.06 release repository.
Here's the AI command I executed to replace the default AI manifest with the experimental base install profile AI manifest:
$ pfexec /usr/sbin/installadm add -m osol-base-ai-manifest-dev.xml -n 1002-126-x86
You should review the custom AI manifest and modify it to suit your needs. For example, consider changing the URL of the development package repository and adding or removing driver packages per your particular platform needs.
Creating AI Clients as VM Instances
Since the objective of this example is to install text-based, headless server form of OpenSolaris, the install client's VM instance is configured as follows. Within VirtualBox, create a new VM with the following settings:
- I've used the recommended 16 GB size for now. There's a bug outstanding in AI concerning its restriction of a minimum 12 GB disk size for installation when a device is not explicitly listed in the AI manifest. As mentioned in the bug, you can work around this issue if you specify the device in the manifest.
- I've used either SCSI (Lsilogic) with Slot SCSI Port 0 or the default setting of IDE. Functionally, both work.
- Base Memory: Can be rather low. Say, 512 MB or so.
- Boot Order: Check "Network" and move it to the top.
- Network: Accept the default Adapter Type and select "Internal Network" - the same network as used for the internal interface of the install server.
- CD/DVD-ROM: Not mounted
- Audio: Disabled
- Serial Ports: Disabled
- USB: Disabled
Performing the Installation
Make sure that the install server is running and then start the newly created client. Assuming that your install server is configured properly, the client will:
- obtain an IP address from the DHCP server
- download a miniroot from the install server
- download an boot the AI ISO image
- discover the install service
- download the manifest
- begin installation
Monitoring the Installation
As the installation progresses, on the install client, you can sign in as "root/opensolaris" and monitor:
# tail -f /tmp/install_log
You might also find it convenient to check out the content of the pkg(5) history under:
# ls /a/var/pkg/history
Or list the history in a nicely formatted manner:
# pkg -R /a history -l
You can also get a rough feel of which package is currently being installed:
# ps -ef | grep pkg
Part of the enhancements under development for AI include improved progress information.
For reference, you can see the full install_log.
Post Installation Steps
Remount New Boot Environment
Since some of the steps below require access to the newly installed system and the installer automatically unmounts the new boot environment, I needed to remount it:
# beadm mount opensolaris /a
Remove Graphical Boot
Before you reboot your newly installed system, you'll want to edit the Grub menu.lst file to remove the graphical boot references. Since we just installed a text-oriented, headless server profile of OpenSolaris, there no need for the graphical boot support. You'll also need to specify "console=text" rather than "console=graphics" as one of the kernel parameters.
(There might be a way to customize the Grub configuration via the AI manifest, but I haven't delved into that aspect).
Make the following modifications to /rpool/boot/grub/menu.lst:
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris Development snv_126 X86
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=text
Clean Up Package Download Cache
If you'd like to recover ~200 MB from your installation, you can remove the pkg(5) download cache area (note the /a/... location):
# rm -rf /a/var/pkg/download
As part of cleaning up the installed image, you can also purge the pkg(5) history data. But doing so doesn't save that much space:
# pkg -R /a purge-history
Modify VM to Boot From Hard Disk
Shutdown the client such that you can modify the system boot order and network settings of your VM.
# shutdown -i0 -g0 -y
Once OpenSolaris has shut down, make these modifications to your VM:
- System Boot Order: Uncheck "Network" and ensure that at least "Hard Disk" is checked.
- Network: Modify the network adapter configuration to suit your needs. e.g. Use NAT or Bridged.
Restart the VM
As you restart the VM, the initial boot will take an extended period of time due to SMF service descriptions being loaded for the first time. Once the login prompt appears, log in as "osol/justone1", the predefined account with administrative privileges. For future installations, you can change that username and password in the AI manifest file.
Since Network Automagic (NWAM) is enabled by default, the client will attempt to obtain an IP address and other information from a local DHCP server.
Establish a Local Development Package Repository
As mentioned earlier, the most significant optimization to this install process is to establish a local copy of the development package repository. I documented in a later blog entry how to use pkgrecv(1) to easily create a heavily reduced form of the the OpenSolaris development package repository.
Publish an Experimental Base Metapackage to Local Repository
As part of the effort to further experiment with a base install profile, I'd like to publish a base install profile metapackage to the local package repository and use it during installation. Doing so will more accurately demonstrate how the profile would be used in the real world by greatly simplifying the AI manifest. Rudolf is already doing this with a slightly longer list of packages in a metapackage as part of the creation of the exmaple JeOS VM images.
Tweak List of Driver Packages for VirtualBox
Perhaps a few of the packages currently listed in the supplemental, VirtualBox-specific list of packages aren't really necessary for VirtualBox. A bit more investigation and experimentation is warranted here.
Learn More About Automated Installer
I am curious to understand what additional customizations can occur from within an AI orchestrated installation. Again, Rudolf has quite a bit of experience here with his JeOS VM image work that is documented via these source files. I plan to further review these files to get a better feel for how he has used AI in that context.