Using a Base Metapackage to Simplify Installation of OpenSolaris
By ckamps on Nov 12, 2009
This entry addresses publishing and using a reduced installation profile metapackage and the Automated Installer (AI) as a means of simplifying the installation of heavily reduced forms of OpenSolaris.
This is the final installment of a series of entries demonstrating the value of using a base installation profile metapackage with the Automated Installer to produce heavily reduced installations of OpenSolaris. These experiments have been performed in the context of the OpenSolaris JeOS project. Earlier posts in this series include:
- OpenSolaris Automated Installer with JeOS and VirtualBox
- Initial Experiments with Base Installation Profile
- Establishing Reduced Package Repository
- 7 Minute Installs
Base Installation Profile Metapackage
The core of the base installation profile metapackage is a manifest file that expresses a dependency for each package that delivers a feature of interest for the base installation profile. In addition to the list of key dependencies, the manifest includes a description and classification of the package. The package list is based on the early draft of OpenSolaris Base Installation Profile Metapackages.
See the latest version of the manifest file.
Publishing the Metapackage
Before publishing the base metapackage, I took a snapshot of my reduced package repository:
$ pfexec zfs snapshot -r repos/devbase@b126-before-base-metapackage
Next, the pkgsend(1) command's include function was used to specify the manifest in a publication session:
$ eval `pfexec pkgsend -s file:///repos/devbase open firstname.lastname@example.org,5.11-0.126` $ pfexec pkgsend -s file:///repos/devbase include pkg-manifest-base $ pfexec pkgsend -s file:///repos/devbase close
The new package was immediately available in the running repository:
Using the Metapackage
I created a much simplified form of the custom AI manifest by replacing most of the package references with a single reference to the base installation profile metapackage. Explicit references were retained for those packages that may vary from one platform to another. In this case, I retained references to the driver packages of interest in my use of VirtualBox. The list of drivers would be different for other platforms such as bare metal x64 and UltraSPARC systems and other virtualization platforms.
Extra packages for VirtualBox platform
Since the experimental base installation profile metapackage is not available in the mainstream OpenSolaris package repositories, I also modified the custom AI manifest to instruct AI to remove the metapackage as part of the installation process. For the time being, I am only using this metapackage to demonstrate the role of such a metapackage during the installation process.
Once a supported metapackage is available via the mainstream repositories, removal of the metapackage would not be needed. In fact, keeping the base install profile package installed would be useful because it would inhibit people from inadvertently removing any of the base set of packages. Presence of the metapackage would act as a marker in helping support and other personnel understand that at least the required packages for minimally supported installations were present. (Any other installed packages that express a dependency on base packages would also inhibit removal of the base packages).
Finally, I used AI's installadm command to replace the default manifest with the new simplified manifest and installed a new client to validate that the overall installation worked as expected.
$ pfexec /usr/sbin/installadm add -m osol-ai-manifest-using-base-profile.xml -n 1002-126-x86
The steps to install a client are covered in the blog entries mentioned earlier. Basically, an empty VM image was created in VirtualBox and configured to use network boot protocol to start a mini-root of OpenSolaris and load the AI installer image from my install server. The installer downloads the AI manifest and installs the specified metapackage and other packages from the installer server.
I'd like to see a refined variation of this experimental base installation profile metapackage published to the OpenSolaris development package repository such that developers can start leveraging it in their own custom installation profiles. Clearly, the content of the metapackage would need to evolve as the detailed definition of base install profile features matures and package boundaries and dependencies are modified. However, the goal would be to insulate most users from those changes by retaining the same overall role and naming of the metapackage as the internals change.