Friday, July 07, 2006

How small can you make Open Solaris - Part 1

Solaris started its life as operating system for workstations and then progressed to servers. It has always been an operating system dominated by features, showing Sun's R&D capability. This is great if you are installing a server or a desktop, but has far too many features for building an appliance. Luckily the installing comes with some reduced installation clusters which tries to bring the installation down to the bare minimum. Unfortunately the last time I looked the smallest install was still several hundred megabytes. Linux on the other hand has had a project going for while now called "Damn Small Linux", which strips Linux down to around 50 megabytes. This is a perfect base to start building an appliance, build your own distro, or strip the kernel down further for an embedded device.

Can Solaris become as small as "Damn Small Linux". The answer is a resounding yes (and probably smaller). Lets investigate how this can be done. The first thing to do is to state the goal, which is to be able to successfully boot into a shell and execute a simple command such as 'ls'. The logical place to start is with the smallest running version of Solaris supplied by Sun. If you have a x86 grub version of Solaris you will find a 52 megabyte file in your /boot directory called x86.miniroot-safe. This file is a gzipped UFS image that is booted when you select "Solaris failsafe" from the grub menu. Using it to boot to single user mode will mount the root filesystem and give you a root shell. It also contains the code to start a Solaris installation.

Now we have found an ideal candidate, lets start ripping it apart. The first step is to copy it (as you may need it if you break something), and setup new menu option in grub.

cd /bootcp x86.miniroot-safe x86.microrootcd /boot/grub

Edit the file menu.lst, copy the failsafe section and modify it to look something like this -

If you want you now can reboot and select "Solaris Micro Root" when the grub menu comes up. It should boot into your copy of failsafe. After you have finished testing, reboot into multiuser mode and mount this image so you can change it.

The file '/boot/x86.microroot' is actually a gzipped UFS filesystem image, which with a couple of commands can mounted and change. The following is the an example of the procedure to make changes. I would suggest you create mount and unmount scripts to automate the process. (Note: You will need superuser privs for the following steps, the root user or atleast sys_mount, file_dac_read, file_dac_write)

Important - Make a backup before making changes, and document your changes

cp /boot/x86.microroot /boot/x86.microroot.bak

Unzip image to /tmp

gzcat /boot/x86.microroot > /tmp/microroot.img

Create a loopback device for this file. The environment variable 'dev' catches the device name for later use.

dev="`lofiadm -a /tmp/microroot.img`"

Finally mount the image using the loopback device.

mount -F ufs ${dev} /mnt

At this point your image is mounted and you can cd to /mnt and make your changes. Note: Be VERY VERY CAREFUL that you are changing or removing the file in /mnt and NOT in the root filesystem. It could get very ugly if you make this mistake. Take your time and be very careful. Once you have made the changes DONT REBOOT. You will need to follow the next steps and commit the changes before you reboot. Also rather than deleting a file or a directory, it is a better practice to move them to a backup directory and then test the changes. If the changes were good then you can delete the backup directory later. If the changes caused problems you can simply move the files and directories back in your next editting session.

Umount the image and delete the loopback device.

cd /umount /mntlofiadm -d /tmp/microroot.img

Copy/gzip the changes back to the /boot directory

gzip -c /tmp/microroot.img > /boot/x86.microroot

You can now reboot and test your changes. If the system hangs, just reset the system and undo what you did and try something else. If the system reboots too fast for you to read the kernel messages, a handy tip is to add the "-kd" options in the grub menu (combined with or after the '-s'). This will put the kernel straight to debug mode. To continue the boot type ':c' at the prompt. If the kernel panics it should print a message and then wait for you to press a key before rebooting.

Using this method I reduced the entire image to around 42 megabytes (uncompressed) without touching the 32bit kernel. I then was able to create a 18 megabyte bootable Solaris. The next part I will list the areas you should remove or modify. Hopefully, in Part 3, I will have finished a script which takes a Open Solaris build from the prototype directory and builds the microroot for you.

I think it only fair to point out that Damn Small Linux does rather a lot more than allow you to go 'ls' in single user mode. I'm sure you know that, but the article might give someone who hasn't tried DSL (or Puppy, or SLAX) the wrong impression.

The whole idea of the article is to do the same for Solaris as does D.S.L for Linux. My inspiration for this came from the great work that has overtime has built D.S.L. I am sure that later it will run more than ls. It probably also fair to point out that D.S.L has been going for many as years as has Linux. Open Solaris is only just a year old, and I have only put a couple of days effort into reducing it size. Rome was not built in a day :)

Thanks for this very useful article. It inspired me to start experimenting withsmall installations.By the way, the ramdisk image doesn'tactually have to be gzip'ed. If you leaveit uncompressed you don't have to worryabout umounting and re-gzipping it wheneveryou make a change; in fact you can put it in/etc/vfstab and forget about it. (I wishSolaris provided a nicer way to make lofifiles persistent; I used an rcS.d script.)

You may want to look at the boot/x86.microroot file on the BeleniX LiveCD (www.belenix.org).

It is an extremely small root filesystem whose uncompressed size is just 57MB of which 49MB is actually occupied and rest free space. It however lacks some stuff in /usr that can be added. This can be starting point.