- Building a Bootable Installation from CD-ROM
- Recovering a Failed System with JumpStart
- Altering the Boot Process
- Adding Utilities and Manual Pages
- Meeting Challenges Unique to the Miniroot
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Meeting Challenges Unique to the Miniroot
As previously discussed, the miniroot is a subset Solaris OE kernel and filesystem. The miniroot must fit in a prescribed amount of physical memory and so does not contain all of the software packages that an installed system would contain. In addition to the size limitations, there are challenges in installation that are unique to the miniroot. This section covers these specific challenges:
- Read-only media
- Files in /var
- path_to_inst file
Read-Only Media
While it is obvious that the boot image on a Solaris OE Software CD is read-only, it may not be obvious that the client's boot image served by the JumpStart server is also read-only. Because of this, all systems booted from this image for recovery or installation mount their filesystems read-only. Whether booted from a CD or over the network from a JumpStart server, the /tmp memory-mapped tmpfs filesystem is the only writable space for any utility or service that requires writable media.
The Solaris OE tmpfs filesystem is fashioned from the virtual memory in the client and as such, it loses all its contents when the client reboots. Any file or directory on the remaining filesystems that must behave as if it is writable must be redirected to /tmp by means of a symbolic link. For example, the /etc/vfstab file must be writable, but /etc is on a read-only filesystem. The file /etc/vfstab is actually a symbolic link, created at the client's boot, to a writable vfstab file in /tmp. All such writable file links are created on the read-only CD image or on the client's boot image on the JumpStart server. The targets of all such symbolic links are then created in /tmp when the miniroot is booted.
The same mechanism can be used to provide writable space for tools added to the recovery boot image. The following commands provide a writable log space for NetBackup in $ROOTDIR/usr/openv/logs.
server01# cd /jumpstart/OS/Solaris_8_2001-04/Solaris_8/Tools/Boot/usr/openv server01# ln -s /tmp/_openv_logs ./logs
However, this approach addresses only half the problem. The target of the symbolic link, in /tmp, must still be populated at boot. Any required link targets in /tmp can be populated by one of the following methods:
Create a start script that executes mkdir /tmp/_openv_logs.
Utilize the built-in script for populating /tmp.
Method one is a brute force approach, but effective on a small or limited scale. The second method takes advantage of the existing method that the miniroot uses at boot to populate /tmp.
A prototype (or template for) /tmp is maintained on the miniroot and is copied into /tmp very early in the boot cycle. This prototype is the directory $ROOTDIR/.tmp_proto. Early in the startup sequence (in $ROOTDIR/sbin/rcS), cpio is used to populate /tmp from this prototype. These prototypes become the targets referenced by symbolic links throughout the miniroot image.
For our example above, creating the directory $ROOTDIR/.tmp_proto/_openv_logs ensures that /tmp/_openv_logs are created when the client miniroot is started.
Files in /var
The /var directory tree is an extension of the writable directory problem outlined in "Adding Utilities and Manual Pages" on page 26. Most facilities in the Solaris OE utilize /var/tmp or write temporary files into some subdirectory of /var. Because so many utilities expect /var to be writable, the entire /var filesystem is made writable by means of a symbolic link from /var to /tmp/var. This is accomplished by the same mechanism as described in "Adding Utilities and Manual Pages" on page 26. The prototype for the /var hierarchy is in $ROOTDIR/.tmp_proto/var. For a file or directory to be relocated into the client's /var, the file or directory must be the $ROOTDIR/.tmp_proto/var prototype.
path_to_inst File
The Solaris OE device instance number file, path_to_inst, is a special case. It is special because this file must be created from scratch each time a system boots from the miniroot. The path_to_inst file must be writable; however, it cannot simply link to /tmp.
The miniroot cannot possibly have a valid device tree and instance number file for each client that might boot from it. The path_to_inst file and the /dev and /devices directory trees must be created by the miniroot each time a system boots from the CD or JumpStart boot image. The OBP is responsible for probing the bus and inventorying all of the devices in the system. The OBP hands off the result of this inventory (the OBP device tree) to the kernel when it begins loading. The OBP device tree is used as the basis for the kernel to map the device location (path) to the device driver instance numbers. This mapping is what is stored in the path_to_inst file. For a boot from read-only media (for example, from CD or from a JumpStart server) the newly created path_to_inst file is generated and written to /tmp/root/etc/path_to_inst early in the miniroot boot process.
Because a valid /etc/path_to_inst is required by the kernel very early in the boot cycle, using a writable surrogate in /tmp is not possible, since /tmp is not yet populated when the instance number file is needed.
For the kernel to be redirected to the real path_to_inst file that was written in /tmp/root/etc/path_to_inst, two path_to_inst files are used. The real path_to_inst, which contains valid device paths mapped to the correct instance names, is created in /tmp/root/etc/path_to_inst. The bootstrap version, required by the kernel but invalidated after the kernel loads, is in /etc. This bootstrap version of $ROOTDIR/etc/path_to_inst consists only of the line:
#path_to_inst_bootstrap_1
This bootstrap path_to_inst can cause problems for utilities that are hardcoded to reference /etc/path_to_inst for the device instance number file.
System utilities and diagnostic tools, like SunVTSTM software or older versions of STORtools, that must build internal tables of the devices attached to the system typically read /etc/path_to_inst directly, rather than obtaining the device instance information from the kernel.
Unfortunately, if these utilities hardcode the path name for /etc/path_to_inst into their object modules, libraries, or binaries, the path name is not easily changed. This situation prevents the use of such utilities while the client is booted from the JumpStart server or CD.