Post new-boot Solaris on 128Mb systems


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:

  1. Embedded systems.
    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.
  2. 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).
  3. 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 \\

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:



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.

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.

# 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
        mv $i/C .
        rm -rf $i/\*
        mv C $i

# 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/ 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.


<hr><center><big>Excellent !</big></center><hr>
This is an insane amount of work for what some people may think is a useless exercise.

Not So !

The potential for OpenSolaris on small embedded systems is of great interest to some people ( see ) and the need to cram a useful OS into a small footprint is of great value.

I want to thank you and applaud you in all the work that you did here and want to let you know that it is of value and will definately be used.

Dennis Clarke
Blastwave and Blastware Projects <hr>

Posted by Dennis Clarke on September 28, 2005 at 12:01 PM PDT #

Great document!

Removing the pf\*sh didn't likely save anything since they are just hard links to the normal shells.

Stripping the /usr/lib/security/pkcs11_\* modules makes the unusable since the ELF signatures on them will now fail to verify (this is only true of the signatures on crypto modules not on all ELF binaries). The same is also true of the stuff in kernel/crypto.

Speaking of kernel/crypto you can drop all of the following rsa, sha2, aes, arcfour, blowfish, des. You need to keep md5, sha1, swrand since those are used.

I'd also dump all amd64 stuff for kernel and userland since it is very unlikley that a system with an amd64 processor has only 128Mb RAM.

Posted by Darren Moffat on September 28, 2005 at 07:27 PM PDT #

Darren, thanks for providing details on the crypto bits. I was mostly guessing with them.

As for the 64-bit binaries, everything (kernel, executable and library) is already dumped from the stock miniroot. This is appropriate since at the moment, all x86 systems can load the 32-bit kernel.

Posted by Jan Setje-Eilers on September 29, 2005 at 03:55 AM PDT #

hi Jan, I wanted to know the following: 1. What are the components(kernel/userland libs) in x86.miniroot, which are responsible for x64 support? Do we need to add something more to x86.miniroot? (I wanted to add complete x64 support in x86.miniroot, to run 64 bit applications ). Please point me to relevent resources if you can. my email id : ameyaagnihotri22(at)

Posted by ameya on February 20, 2007 at 03:03 PM PST #

Are you trying to create a smallest image with x-window? I prepared the iso with twm(47 mb) -

Posted by Alexander on April 23, 2007 at 12:15 AM PDT #


I have a "Net Install Image" of solaris 10.
Is it possible to convert this to installable iso image, which can be written to DVD and get the system installed?
if yes, can you please give me the complete command?


Posted by Narendra Kumar on November 25, 2007 at 07:45 PM PST #

I think this is extraordinarily importand, I did write some notes with reference to this article on I tried the SOL_EMB_X86.iso which worked as a live CD, but I did not capture how to install it to a hard disk. I have written an article about solaris on intel ATOM processor, but I'd like to know more, how to get solaris on Qualcomm and samsung processors. Please?

Qualcomm® MSM7201A™, 528 MHz

Samsung S5PC100 (both previous iPhones used the Samsung S3C6400). It runs at 600MHz,

Posted by Morten Gulbrandsen on December 04, 2009 at 10:25 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed



« April 2014