Post new-boot Solaris on 128Mb systems
By setje on Sep 28, 2005
New-boot introduced the install-miniroot ramdisk. This means the entire miniroot for CD/DVD based installs as well as for network installs is mounted on an in memory ramdisk.
The entire x86 miniroot is 273Mb. Since 256Mb systems are still interesting, something had to give. We do not run the X server or the GUI installer on low(er) memory systems. So one obvious thing to pull out for lower memory systems is X. Dropping /usr/openwin and /usr/dt gains back 137Mb. They are stored in a cpio archive on the media and unpacked into tmpfs on systems with sufficient memory. The packaging databases, which in a running miniroot are obscured by the /tmp tmpfs mount, are nearly another 10Mb. They are needed for patchadd -C or pkgadd -R, so root_archive (un)packmedia archives and restores them. This brings the miniroot down to 126Mb. Solaris and the text mode installer officially require 64Mb to run. The memory occupied by the ramdisk needs to be available in addition to this 64Mb. This means it is possible to install Solaris on a system with 192Mb of memory. Please note that I used the word possible. The minimum memory requirement for a supportable system is currently 256Mb which leaves some room for things to grow.
Systems with less memory can still be live-upgraded. However since there is no way to boot the miniroot any more their serviceability is compromised and they fall off the support matrix.
There may be some situation in which it might seem desirable to run Solaris on systems with less memory than that. Most of these tend to fall into one of three categories:
While these seem to keep coming up in this context, no one really runs the installers on embedded systems. Their root (and usr) filesystems are generally constructed on another system and then deployed on the assembly line. So the miniroot install time restriction do not really apply here.
Previously retired systems that have been pulled out of a closet to
try out Solaris 10 or investigate something specific.
In most of those cases, further digging in said closet will reveal another system that the rest of the required memory can be pilfered from. A quick look at one of the mail order price checkers suggests that 128Mb of pc133 SDRAM can be had for as little as $7 (likely around $20 incl. shipping from a reputable retailer), so that's a fairly cheap option (RDRAM is a little more, but still an option).
Large existing deployments of desktop clients.
In nearly all of those cases more memory should be fitted if they are to be moved to Solaris 10. The biggest issue in such a case is likely the fitting of the memory and not the cost of the memory.
Then there's another category which I'll call: "Because I want to."
That last category will have to go to more effort. The most reasonable approach is to further minimize the miniroot.
The hard way to run such a machine:
Disclaimer: The following makes extensive use of rm in ways that violate package boundaries. This may break over time as things are added to the install process (for instance in postinstall scripts) that consume any of these items. It may not work tomorrow, YMMV and it most certainly voids any warranty or support agreement you might have.
First the miniroot needs to be unpacked. For details take a look at root_archive(1m). Note: since we need to hold onto ownership and permissions this is a root only operation:
/boot/solaris/bin/root_archive unpack /cdrom/cdrom0/boot/x86.miniroot \\ root-small
This will result in a copy of the miniroot under root-small. You'll find it's roughly 126Mb in size.
I was hoping that just deleting the non-C locales would be sufficient. However in the end quite a bit more had to go.
Here is rough script that removes things I hope are not used during a basic run through ttinstall:
#!/bin/sh CWD=`pwd` if [ "$CWD" = / ] ; then echo You probably do not want to run this in /. echo Please cd into the top level of an unpacked miniroot to run this. exit fi if [ ! -f sbin/install-discovery ] ; then echo This does not look like an unpacked install miniroot. echo Please cd into the top level of an unpacked miniroot to run this. exit fi # The first thing to go is all the non C locales (if you don't speak C, # you should learn it before proceeding any further): # for i in usr/lib/locale usr/snadm/classes/locale usr/lib/install/data/lib/locale do mv $i/C . rm -rf $i/\* mv C $i done # The iconv modules also do not appear to be used unless the system is in # a non C locale, so they go: # rm -rf usr/lib/iconv # Since there is not enough memory to run the java installers, they # can be deleted. # # On second thought usr/lib/install/data/wizards/apps/launcher.class # and postinstall.class are copied to the installed system and it will # be DOA without them, so better hang on to them. For the record I # learned this the hard way; through reckless experimentation. # mv usr/lib/install/data/wizards/apps/launcher.class . mv usr/lib/install/data/wizards/apps/postinstall.class . rm -rf usr/lib/install/data/wizards/apps/\* mv launcher.class postinstall.class usr/lib/install/data/wizards/apps # Perl is only on the miniroot so folks can write their finish scripts # in perl. So unless such a finish script is to be used, it can go: # rm -rf usr/perl5 # most network services will never be run in the miniroot - remote # access can be useful for debugging, but we really don't have enough # memory to run another shell, let alone telnetd. # rm usr/sbin/in.comsat usr/sbin/in.fingerd usr/sbin/in.rexecd rm usr/sbin/in.rlogind usr/sbin/in.rshd usr/sbin/in.rwhod usr/sbin/in.talkd rm usr/sbin/in.tftpd usr/sbin/in.telnetd rm -r usr/lib/gss usr/lib/mps # Since Solaris is perfect, it will not need any debugging, so we can # ditch the debugger: # find kernel platform usr -name \\\*mdb\\\* | xargs rm -r 2> /dev/null # Other random stuff we should not need for a basic run through ttinstall: # rm -r usr/lib/patch usr/lib/spell usr/lib/lp # while open source is nifty and all, I've never compiled my own zoneinfo's # rm -r usr/share/lib/zoneinfo/src rm kernel/fs/cachefs kernel/fs/autofs rm -r usr/lib/fs/cachefs rm kernel/misc/nfssrv rm usr/sbin/rpc.\* rm usr/bin/localedef usr/bin/genmsg rm usr/bin/mailx usr/bin/pfksh usr/bin/pfcsh usr/bin/rlogin usr/bin/rcp rm usr/bin/rdist usr/bin/rksh usr/bin/rsh usr/bin/telnet usr/bin/tip # note: ping _is_ needed # rm usr/sbin/snoop usr/sbin/traceroute # We don't use ipv6 during install: # rm usr/lib/inet/in.\* # No dr: # rm -r usr/\*/cfgadm # IB support is large on disk as well as in memory, so away it goes: # rm kernel/misc/ibmf rm kernel/misc/ibcm kernel/misc/ibdm rm kernel/drv/tavor # ipsec is cool, but we're not using secure tunnels at install-time (yet): # rm usr/lib/libike.so.1 usr/sbin/ikeadm usr/sbin/ikecert # Most of grub is not needed in the miniroot: # mv boot/grub/stage? . rm -r boot/grub/\* mv stage? boot/grub rm boot/solaris.xpm # audio support and drivers aren't needed # find kernel -name \\\*audio\\\* | xargs rm rm platform/i86pc/kernel/drv/sbpro # how would one use a smartcard during install? # find . -name \\\*smartcard\\\* | xargs rm -r 2> /dev/null # not all libraries and binaries on the miniroot are stripped # - letting strip sort the binaries from other stuff is crude, but # seems safe enough. # find . -type file | xargs strip 2> /dev/null # this likely breaks disk space relocation, but it's another 400k # rm usr/lib/fs/ufs/ufs\* # ditch the optimized copies of libc # rm -r usr/lib/libc
This takes the miniroot down to 71Mb. Due to ufs overhead, this works out to about 78Mb in memory. Some of the bits that have been deleted might be used by postinstall scripts. However my testing produced no errors in the install logs. I have not attempted an upgrade.
I've left all the stuff needed for netinstalls and mirrored root upgrade in place. I haven't tested mirrored root upgrade, but I suspect that md, libsvm and friends will need more memory than a 128Mb system has to spare to run.
Lastly the miniroot needs to be re-packed into its compressed ramdisk image:
/boot/solaris/bin/root_archive pack x86.miniroot.small root-small
This miniroot can then be copied to a netimage or CD under < relative>/boot. If you want to make a CD, the mkisofs incantation I currently use is:
mkisofs -o hacked_Solaris.iso \\ -b boot/grub/stage2_eltorito -c .catalog -no-emul-boot \\ -boot-load-size 4 -boot-info-table -relaxed-filenames -N -L -l \\ -r -J -d -D -V hacked_Solaris
The 128Mb system I used to test was a fairly plain pIII system with only IDE (CDROM, hard disk and ZIP drive) and an iprb. I did not configure networking at install time. I performed a CD based (not DVD) install. I set up 1024Mb of swap just to be on the safe side. Side note: I did experiment with adding swap early, but ttinstall startup requires real memory as it drags in a number of shared objects which all do need to be in memory at load time.
I was able to perform a fresh, full netinstall of nevada build 22 on a large memory system using the same minimized nevada build 22 miniroot.
- Disconnect or remove any devices not used during install. This will keep their drivers from attaching and hence conserve memory.
- Don't try this with gigabit or 10gig NICs and 128Mb. Their drivers have a tendency to set up large buffers. BTW, if you have such a setup, consider trading your NIC for more memory.
- Don't panic when adding SUNWj5rt or updating the boot_archive take a really long time. Since you wanted to run a 128Mb system, this is a great time to get used to watching it swap.
It is possible, and even likely that any number of the items I chose to delete will be required in future builds, which is why this is basically unmaintainable and a blog entry rather than part of the product. As with many things in software that would require more work: If someone wishes to investigate the exact interface and packaging boundaries for the bits that needed to be removed and to establish a stable way of making these items optional, this could become part of the product. Considering how close I had to cut it, it may not be possible to keep this working for much longer without more serious work. More serious work in this case would be to use a compressed filesystem for some or all of the ramdisk.
The 128Mb test system I used is really amazingly slow when compared to the same system with 256Mb of RAM installed. Its interactive performance is bad enough that the time spent figuring out what type of memory it takes, ordering and installing it could easily be recouped in a matter of days. Given just how cheap workable memory for most such systems is, going to the effort of running one with less than 256Mb does not appear to be particularly sensible.