Roman Shaposhnik's

I still remember the coolness factor that the first fully functional, user friendly LiveCD with Linux had. From a technical stand point it wasn't really that much of a novel concept (all major Linux distributors had a capability of booting into a function Linux kernel for the installation and troubleshooting purposes) but as everything with Linux -- it had some significant social implications. What Klaus Knopper singlehandlely changed was not what Linux was capable of, but rather how it presented itself for the first time. All of a sudden just about anybody could take it for a spin. It got friendlier, it got less intrusive and even if you didn't like it -- hey, at least it hadn't made you slave away for a day installing it (and trashing your Windows partition along the way). Fast forward to 2008 and you can see that one of the most prevalent Linux distributions, Ubuntu, still uses ideas from Knoppix to advance Linux adoption. Life is good, if only... boring. Yep, that's right -- there's nothing exciting about a Linux LiveCD from major vendors anymore. It is polished, mature and leaves nothing to blog about. Not to worry though, with the Project Indiana debuting its Live CD of OpenSolaris a couple of weeks ago we now have a brand new frog to dissect and marvel at.

NOTE: This article is the first one on my blog using GTOC: Geek's Table Of Contents. A concept pioneered by Mick Bauer. On one hand, GTOC is nothing but a cleaned up version of my UNIX session. On the other hand it is the quickest way to figure out whether the article has something of an interest to you or not. Here's how I use GTOC: I follow the stream of UNIX commands until I exclaim: "I didn't know that was possible!". At that point it might be useful to follow the article. If you don't exclaim (not once!), then perhaps the added value of my ramblings and musings would be too small to justify wasting your time. At any rate: the decision is yours. GTOC is small, easy to follow an best of all -- it is crosslinked to the actual content of the article.

0. GTOC

Don't be a jock -- jump to the GTOC!

1. First impression

First thing one notices (right after the brand new "we-are-the-bubbly-in-the-.com-bubble" logo) is that Windows sometimes has troubles reading the LiveCD. Once you look at the file layout it isn't all that difficult to see why: OpenSoalris team has decided to really make the most out of what an ISO9660 filesystem is capable of. The CD has files with long names containing '@' and ':' characters, it has symbolic links and all sorts of other stuff. In fact, the only thing missing from it are device and pipe nodes (not that ISO9660 would permit it, but you've got the idea): $ sudo mount /tmp/os200805.iso /mnt -o ro,loop $ find /mnt \! -type d -a \! -type f -exec ls -go {} \; lrwxrwxrwx 1 9 Apr 26 18:43 /mnt/bin -> ./usr/bin lrwxrwxrwx 1 30 Apr 26 18:43 /mnt/boot/solaris/bin/root_archive -> ../../../usr/sbin/root_archive lrwxrwxrwx 1 11 Apr 26 19:03 /mnt/dev/nvidia0 -> fbs/nvidia0 lrwxrwxrwx 1 11 Apr 26 19:03 /mnt/dev/nvidia1 -> fbs/nvidia1 lrwxrwxrwx 1 11 Apr 26 19:02 /mnt/dev/nvidia2 -> fbs/nvidia2 lrwxrwxrwx 1 11 Apr 26 19:02 /mnt/dev/nvidia3 -> fbs/nvidia3 lrwxrwxrwx 1 11 Apr 26 19:02 /mnt/dev/nvidia4 -> fbs/nvidia4 lrwxrwxrwx 1 11 Apr 26 19:02 /mnt/dev/nvidia5 -> fbs/nvidia5 lrwxrwxrwx 1 11 Apr 26 19:02 /mnt/dev/nvidia6 -> fbs/nvidia6 lrwxrwxrwx 1 11 Apr 26 19:02 /mnt/dev/nvidia7 -> fbs/nvidia7 lrwxrwxrwx 1 38 Apr 26 19:02 /mnt/dev/nvidiactl -> ../devices/pseudo/nvidia@255:nvidiactl lrwxrwxrwx 1 6 Apr 26 18:42 /mnt/dev/stderr -> ./fd/2 lrwxrwxrwx 1 6 Apr 26 18:42 /mnt/dev/stdin -> ./fd/0 lrwxrwxrwx 1 6 Apr 26 18:42 /mnt/dev/stdout -> ./fd/1 Speaking of ISO9660 lacking device nodes, notice how all the symbolic links in /dev are dangling. They have nothing to point to. In fact, if you look at the root of the CD you may notice that /dev and /bin are not the only indications of it trying to be an actual FS for running Solaris. There's also: /.cdrom, /devices, /jack, /mnt, /proc, /system and my personal favorite /tmp. Oh, oh, and there's also /root which I, frankly, have nothing against, but I'm sure all dyed-in-the-wool Solaris admins are going to appreciate. Immensely. ;-) But anyway, it really seems like the business with trying to coerce ISO9660 into being a good root filesystem is flawed on two accounts:

1. ISO9660 just isn't a good enough FS to be used as a UNIX root filesystem
2. Everybody and their uncle (that would be OpenSolaris) uses ramdisks for root FSes anyway. There's one on the OpenSolaris's LiveCD: /boot/x86.microroot. And it is the one that matters

It seems, there's really very little need for anything but /boot, /platform, /solaris.zlib and /solarismisc.zlib to be on the LiveCD. In reality, /jack and /root are also needed and if you would like to install from the LiveCD you'd also need /.image_info and /.catalog. Oh, and to apease the mighty lawyers: you really need /COPYRIGHT and /LICENSE. Everything else can be pretty much cut out of the LiveCD without compromising its functionality.

2. The challenge

Deconstruction is cool. Just ask Derrida if you don't believe me. Although in my book creating something is even cooler. So lets see if we can construct a LiveUSB with OpenSolaris while deconstructing the Live CD. Why? Well, mainly to show-off, to learn more about its structure and also to let me finally install OpenSolaris on the tablet that lacks a CD drive.

3. The prep work

We still need to do a bit of prepwork and sleuthing around the content of the LiveCD before we understand it well enough. Three files on it seem to be of a particular interest: /solaris.zlib, /solarismisc.zlib and /boot/x86.microroot.They look suspicious: they are big, they don't have a well known type (/usr/bin/file simply says "data") and the last one is mentioned in /boot/grub/menu.lst as a module. A crash course in bootstrapping: when you power on any modern computer the first thing that gets exectued is BIOS. It first takes care of some really basic low-level hardware configuration. Then it tries to figure out where to get the software that is supposed to run on the machine. Finally it loads it up and relinquished the control. Once the dust settles we find our computer running an operating system of some sorts. Although not everybody realizes, that BIOS almost never loads up a kernel of any operating system. What it loads up instead is a intermediary piece of code known as a bootloader. Bootloader lets you have a higher degree of control over what particular kernel gets loaded for real and what arguments get passed to it (OS kernels are a bit like applications in that respect, they have command line arguments as well). Simply put: bootloader is what makes it possible for Windows, Solaris, Linux, Plan9 and any other OS to peacefully co-exist on the same hardware. Not only that it lets the user decide what gets loaded. And how. That "how" question is a bit trickier than it appears. You see, any storage device is nothing but an array of numbered sectors filled with information. At least at the level of BIOS there's no such concept as a filesystem -- just an endless stream of blocks. That means, if you want to load a kernel that is stored as a file you have to teach your bootloader how to "mount" the filesystem that stores it. Modern bootloaders thus become a micro operating systems, capable of some degree of file operations and running a limited shell (I guess, it is the closest one can come to what a proto-UNIX must have felt like in 70s). GRUB is a bootloader that does exactly that. Although it is quite far from being an elegant piece of software (to say the least) it gets the job done via the following 3 commands: root ([device]) is used to "mount" any partition of any of your storage devices, just like mount [device] /mnt would do in real UNIX; kernel /path/to/the/file/with/kernel copies the kernel into memory; module /path/to/the/file/with/auxilary/kernel/data does what its name implies -- it copies content of a file into memory and passes the kernel a pointer to it; and finally there's boot which simply transfers control over to the kernel and thus "exits" the bootloader. Once again, notice that the magic of GRUB being a micro operating systems makes all the file names be real file names in whatever filesystem they happen to reside on. You can access anything ranging from FAT all the way to ZFS, just the same way you would access these files once the OS is up and running. This is quite exciting if you ask me, and if it wasn't for the GRUB being as sucky as it is life would be very, very good. Here's a sequence of events that happen when you insert a bootable OpenSolaris LiveCD into your CD drive and power-on your desktop:

1. BIOS gets executed and initializes the low-level system hardware
2. You select your CD drive as a boot device by hitting a well-known (for your BIOS, anyway) key
3. BIOS loads a a couple of sectors from the LiveCD (more on how it works here) and starts executing that code
4. The code happens to be GRUB and the first thing it does is it loads /boot/grub/menu.lst and presents you with a set of options of what to boot
5. Each option corresponds to a section in the /boot/grub/menu.lst that looks like this:

          title OpenSolaris 2008.05
              kernel$ /platform/i86pc/kernel/$ISADIR/unix
              module /boot/x86.microroot
         

   and selecting it makes GRUB execute commands: kernel$, module and finally boot. There's no magic. In fact, instead of selecting an item from the menu you can press 'c', get to the GRUB shell and manually enter the same commands
6. kernel$ places the content of the file under /platform/... into the well-known memory location and module does the same for /boot/x86.microroot. That's why these two files are important to us. Although the later much more so than the former
7. boot (either implicit or explicit) starts executing the kernel

The /boot/x86.microroot is, to some extent, our gift to the kernel. It is our way of matching the kernel with the "user land" counterpart thus creating an image of the Operating System. In short, /boot/x86.microroot usually holds an image of a filesystem that gets mounted as the root (/). Lets take a look at what OpenSolaris has decided to put inside the /boot/x86.microroot: $ file /mnt/boot/x86.microroot /mnt/boot/x86.microroot: gzip compressed data - deflate method $ gzip -dc < /mnt/boot/x86.microroot > /tmp/image $ file /tmp/image /tmp/image: Unix Fast File system (little-endian), last mounted on /export/home/indiana/proto/boot, last written at Sat Apr 26 19:21:20 2008, clean flag 1, number of blocks 181800, number of data blocks 170535, number of cylinder groups 38, block size 8192, fragment size 1024, minimum percentage of free blocks 0, rotational delay 0ms, disk rotational speed 120rps, TIME optimization Nice! Not only does the output tell us what filesystem it is (UFS) but it also suggests that the Indiana team was on a rather short schedule (this FS was last mounted on 26 of Apr 2008 which gave them about a week for the production cycle) and they were working night shifts (19:21:20) on weekends (26th happens to be Saturday). Way to go!
Now, the UFS filesystem is still a bit obscure (although it has been used as the default FS in Solaris for ages) but it seems that the latest versions of Linux kernel have no troubles mounting it natively. This is great -- it makes it much easier to browse through the files there and understand what happens once the kernel is up and running and /boot/x86.microroot is mounted as a root filesystem. As any UNIX 101 will tell you the first process that gets created is /sbin/init. It used to be controlled by the content of /etc/inittab, but these days the real work happens elsewhere. On Linux, scripts specified under /etc/rc.d/ are the place to look. In fact, we used to have the same mechanism on older versions of Solaris as well, but at some point it was decided that in order for the OS to be accepted by the Web2.0 generation it just has to have a pinch of XML here and there. The SMF was born with actual scripts migrating to /lib/svc/method/, /lib/svc/bin/svc.startd being the headman for them and the rest of the architecture intoxicated by sqllite and XML being too scary to be describe here. What matter for us, though, is that once the control is passed to the Solaris kernel for the first time the following sequence unfolds:

1. kernel mounts the content of the module as its root filesystem
2. kernel starts executing /sbin/init
3. /sbin/init consults /etc/inittab and starts executing /lib/svc/bin/svc.startd
4. /lib/svc/bin/svc.startd executes a bunch of scripts from /lib/svc/method
5. one of these scripts will mount a bunch of real filesystems
6. eventually one of the scripts from /lib/svc/method gives you a login promt of some sorts

The mounting of real stuff is important so lets see if we can understand how LiveCD behaves in that respect. $ sudo mount /tmp/image /mnt -o loop,ro,ufstype=sunx86 $ ls /mnt/etc/fs /mnt/usr/lib/fs /mnt/etc/fs: dev/ hsfs/ nfs/ ufs/ zfs/ /mnt/usr/lib/fs: hsfs/ ufs/ $ cd /mnt/lib/svc/method $ grep mount * .... live-fs-root live-fs-usr live-devices-local live-sysidtool-system .... $ There's good news and bad news. The good news is that live-fs-root and live-fs-usr seem to be exactly the scripts we are looking for. The bad news is that the Solaris kernel on the LiveCD only supports these filesystems: dev, hsfs, nfs, ufs, zfs. Yep, that's right the common denominator of all, the FAT, the venerable MS DOS and Windows filesystem is missing. That pretty much rules out a possibility of easily creating our USB memory stick image (more on that later) and is a first huge oversight on the part of whoever created the LiveCD. They really don't have any excuses here: pcfs module is tiny and not including it is much more trouble than it is worth. But anyway, lets see what the live- scripts can tell us. Here's an interesting portion of the first one:

        # Determine if any of the USB devices contains a UFS filesystem.
        # For devices that do, attempt to mount them to see if the
        # compressed /usr filesystem exists

        /sbin/listusb | while read dev rdev
        do
                /usr/lib/fs/ufs/fstyp $rdev 2>&1 | grep "^ufs$"
                if [ $? -eq 0 ]
                then
                        /sbin/mount -F ufs -o nologging,noatime $dev /.cdrom
                        if [ -f /.cdrom/solaris.zlib ]
                        then
                                echo "" > /.liveusb
                                break
                        else
                                /sbin/umount -f $dev
                                continue
                        fi
                fi
        done

        # ..Else look for CD
        [ ! -f /.liveusb ] && /sbin/listcd | while read dev rdev
        do
                /usr/lib/fs/hsfs/fstyp -v $rdev 2>&1 | grep "Volume id: $volumeid"
                if [ $? -eq 0 ]
                then
                        /sbin/mount -F hsfs -o ro $dev /.cdrom || break
                fi
        done

More good news, it appears that USB is being taken into account by default. This means that in theory we don't have to hack the x86.microroot, although in practice we will be better off doing it anyway (more on that later). Those brave souls who want to explore the option of formating their USB memory sticks with UFS, or, gasp! ZFS filesystems can use everything as-is. For now, lets keep following the breadcrumb trail leading us to the mysterious .zlib files:

        # Explictly create lofi devices for solaris.zlib and
        # solarismisc.zlib

        /usr/sbin/lofiadm -a /.cdrom/solaris.zlib /dev/lofi/1
        /sbin/mount -F hsfs -o ro /dev/lofi/1 /usr
        if [ $? -ne 0 ]
        then
                echo "/usr MOUNT FAILED!"
                exit $SMF_EXIT_ERR_FATAL
        fi

        /usr/sbin/lofiadm -a /.cdrom/solarismisc.zlib /dev/lofi/2

        /sbin/mount -F hsfs -o ro /dev/lofi/2 /mnt/misc

Aha! These two weird looking files are nothing but compressed images of the ISO9660 filesystems and they get mounted under /usr and /mnt/misc. "Wait a minute!", I hear you say, "doesn't it make them compressed images of CD roms?". It sure does. And when you think about it, it sort of makes sense. Unfortunately, Solaris doesn't support the same wide array of filesystems as Linux does, so out of the ones it supports ISO9660 is the best one for any read-only device: it lets you optimize the layout of files and it is quite compression friendly. Speaking of compression: it would be awfully nice to mount these two files for ease of inspection, but we can't. Not just yet. We have to decompress them first. It is relatively easy to do so on Solaris, but it is NOT the true hacker's way. Lets see if we can grok the internal format of these files and write a native decompresser. Now, with OpenSolaris being open source, there's not much hacking that needs to be done in order to uncover what the format is. Just Use the source, Luke! Use the source! Armed with the first hand knowledge it was only a matter of half an hour before the delofi decompresser was produced and put to a good use: $ cc delofi.c -o delofi -lz $ ./delofi /mnt/solarismisc.zlib /tmp/solarismisc.image Compression method: gzip; uncomressed block size: 0x20000; # of blocks: 1115; size of last block: 0x1e000 Can't read block 1114 $ ./delofi /mnt/solaris.zlib /tmp/solaris.image Compression method: gzip; uncomressed block size: 0x20000; # of blocks: 14978; size of last block: 0x19000 Can't read block 14977 $ file /tmp/solarismisc.image /tmp/solaris.image /tmp/solarismisc.image: ISO 9660 CD-ROM filesystem data 'compress' /tmp/solaris.image: ISO 9660 CD-ROM filesystem data 'compress' $ ls -log /tmp/solarismisc.image /tmp/solaris.image -rwxrwxr-x 1 1963036809 May 21 18:19 /tmp/solaris.image -rwxrwxr-x 1 146006016 May 21 18:13 /tmp/solarismisc.image For some reason the last block of both files appears to be corrupted. Its either that or a bug in delofi.c. And I stand by my code! Although, despite what it may look like the images do get mounted just fine and browsing through them reveals that they actually hold content of /usr and /opt. Basically, they are what makes this a LiveCD instead of just an installation media. So how does this compare with SquashFS -- a default way of organizing a read-only optimized and compressed filesystem on Linux? The good news is that on the compression side we're not too bad: just a tiny 10% worse. Where it gets a bit more problematic is access times. Solaris's implementation compresses at a block device level, where SquashFS is a full fledged filesystem and Linux is not shy to take advantage of that. Linux is also capable of compressing using LZMA, where Solaris is stuck with older LZW (LZMA is in the works, though).
Do we need to know anything else about the default root filesystem from x86.microroot? How about what accounts are available there -- we will have to login into the box once the kernel is booted, after all: $ cat /mnt/etc/shadow root:wqy8hz4xKqw4o:13817:::::: jack:9Nd/cwBcNWFZg:13817:::::: Its nice to see that Jack has made it onto the LiveCD of Solaris as a default user, but what is a bit of a shocker is that both of the accounts: root and jack are password protected. Password protecting anything on the LiveCD is a bit like installing a military grade security system on one of these gates. Although it didn't take John the ripper too long to find out that jack's password is jack and root's password is opensola (which I believe was meant to be opensolaris, but the default /etc/shadow only groks the first 8 characters anyway) it left a bit of a strange feeling. Similar oversights, like

1. having a DTrace toolkit down at /opt/DTT but not having a /usr/sbin/dtrace to go with it
2. including a full-blown version of medialib in /opt/SUNWmlib
3. not including the very basic UNIX commands like ps and more
4. not inlcuding a swiss-army knife like a BusyBox

just to name a few, suggest a semi-automatic generation of x86.microroot. Quite unlike a lovingly handcrafted Knoppix, but for the first try -- it is ok. I would, however, definetly be interested in seeing a dedicated hacker tacking a stab at making x86.microroot a bit more elegant and lean. Hopefuly my example of adding pcfs support to it will spur some interest in that area.

4. The plan

Ok, now that we've amassed all that knowledge of how OpenSolaris LiveCD is structured, lets see if we can setup a 1Gb USB memory stick in such a way that we don't destroy any existing data on it, but still have its Master Boot Record occupied by GRUB with a capability of booting into Open Solaris LiveCD environment.

Now, we all know that the bootloaders typically occupy the first 512bytes of any storage device. They are embeded into the 1st sector together with the root partition table. Of course, the problem here is that you can't really do much in 512 bytes which explains why GRUB is split in two halves. The first one is usually located in /boot/grub/stage1 and is exactly 512 bytes long with a single purpose in life of being able to locate and load /boot/grub/stage2. Stage2, in turn, is much larger and capable of mounting a variety of filesystems. GRUB jumps through quite some hoops to be able to fit into an already partitioned space so that stage1 can remain trim and stage2 can be located pretty much anywhere on the storage device (being just a plain regular file on a particular filesystem). This clever scheme is implemented in stage1.5 and you can think of it as a very restricted stage2: stage1.5 is only as smart as to be able to get a real stage2 from one and only one filesystem. Since in our case we will be using an existing partition on a USB memory stick, chances are it'll be a FAT partition. You have two options for installing GRUB in such a configuration: if your OS can run grub shell natively you can do the following (provided that you've mounted your stick on /media/disk): # su - root # mkdir /media/disk/boot # cp -r /boot/grub /media/disk/boot # touch /media/disk/unique-file-to-be-followed # grub GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename. ] grub> find /unique-file-to-be-followed (hd1,0) grub> root (hd1,0) Filesystem is type fat, partition type 0xb grub> setup (hd1) Checking if "/boot/grub/stage1" exists... yes Checking if "/boot/grub/stage2" exists... yes Checking if "/boot/grub/fat_stage1_5" exists... yes Running "embed /boot/grub/fat_stage1_5 (hd1)"... 15 sectors are embedded. succeeded Running "install /boot/grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded Done. grub> quit # rm /media/disk/unique-file-to-be-followed If you're confused about the funny dance around /unique-file-to-be-followed well, that's because GRUB user's interface was designed by none other than Dr. Strangelove himself. There's not easy way to map your typical UNIX /dev/something into what GRUB considers to be a device. The trick we use here is that we ask GRUB to locate a unique file on *all* of the devices it sees. Hopefully /unique-file-to-be-followed is a name unique enough so that you get exactly one device mentioned in the output of the find and that is exactly the one you have to give to root and setup. Just type the name (together with parenthesis) verbatim.

If your OS can't run GRUB natively, but can access the block device of a USB memory stick, you can use my copy of the Master Boot Record and a FAT stage 1.5 to setup everything manually. Lets assume that the block device corresponding to the USB memory stick is /dev/sdb: $ sudo dd if=/tmp/mbr.bin of=/dev/sdb bs=1 $ sudo dd if=/tmp/stage1.5.bin of=/dev/sdb bs=512 seek=1 $ mkdir /media/disk/boot $ cp -r /boot/grub /media/disk/boot Regardless of which method you use it is extremely important to be VERY CAREFUL. Unlike anything else in this article the commands for setting up your memory stick to be bootable can completely mess up the rest of your system if you make a typo or don't fully understand what is it that you're doing. You've been warned!

Ok, at this point your memory stick can boot. Try it! Reboot, select a USB device as a boot device and when you see a GRUB prompt: grub> remove the stick from your computer and reboot back into whatever OS you're using to read this. Congrats! You're 80% there.

The remaining 20% are rather trivial -- you just need to copy the bare minimum of files from the LiveCD to the USB memory stick. The good news is that we don't have to bother with the files that don't fit on a FAT filesystem, the bad news is that the selection of minimum set of files is not all that obvious. It took me two reboots to get it just right, but you have an advatange of benefiting from my wasted time. Here's what you need to copy and how: $ cd /mnt $ sudo rsync -a boot platform solarismisc.zlib solaris.zlib \ jack root .catalog .image_info COPYRIGHT LICENSE \ /media/disk $ mv /media/disk/boot/x86.microroot \ /media/disk/boot/x86.microroot.old $ cp /tmp/x86.microroot.new /media/disk/boot/x86.microroot The only reason we need the last two commands, of course, is because the default x86.microroot wouldn't be able to work with your USB FAT filesystem. I had to modify it on Solaris to include support for the pcfs. And unless you have a Solaris system handy, the following dump is provided for the entertainment value only, you don't have to do any of that. You can simply download my copy of the x86.microroot and get on with your life. But for those curious ones, here it goes: $ rlogin solaris $ gzip -dc < /cdrom/boot/x86.microroot > /tmp/image $ su - root # lofiadm -a /tmp/image # mount -F ufs /dev/lofi/1 /mnt # cd /mnt/ # mkdir etc/fs/pcfs # mkdir usr/lib/fs/pcfs # cp /usr/lib/fs/pcfs/* usr/lib/fs/pcfs # cp /usr/lib/fs/pcfs/mount etc/fs/pcfs/ # cp /usr/kernel/fs/pcfs kernel/fs/ # cp /usr/kernel/fs/amd64/pcfs kernel/fs/amd64/ # find . -name pcfs ./kernel/fs/amd64/pcfs ./kernel/fs/pcfs ./usr/lib/fs/pcfs ./etc/fs/pcfs # cd `dirname lib/svc/method/live-fs-root` # patch < __EOP__ --- /tmp/live-fs-root Fri May 23 12:46:33 2008 +++ lib/svc/method/live-fs-root Fri May 23 12:54:23 2008 @@ -174,10 +174,12 @@ /sbin/listusb | while read dev rdev do - /usr/lib/fs/ufs/fstyp $rdev 2>&1 | grep "^ufs$" - if [ $? -eq 0 ] + usb_fstype="" + /usr/lib/fs/ufs/fstyp $rdev 2>&1 | grep "^ufs$" && \ + usb_fstype="ufs" + /usr/lib/fs/pcfs/fstyp $rdev 2>&1 | grep "^pcfs$" &&\ + usb_fstype="pcfs" + if [ -n "$usb_fstype" ] then - /sbin/mount -F ufs -o nologging,noatime $dev + /sbin/mount -F $usb_fstype -o \ + nologging,noatime $dev /.cdrom if [ -f /.cdrom/solaris.zlib ] then echo "" > /.liveusb __EOP__ # umount /mnt # lofiadm -d /dev/lofi/1 # exit $ gzip -c < /tmp/image > /tmp/x86.microroot.new That's pretty much it. You're now a proud owner of a bootable USB memory stick that can add Solaris experience to just about any desktop/laptop in the world. Use it wisely, though. Don't sneak up on unsuspecting relatives just yet. Even though OpenSolaris looks remarkably like Ubuntu (and yes, these days its a compliment) it is not quite there yet. The major missing part is the community of developers putting there stuff back into the IPS repositories all over the world. But it is coming. For now, quite a lot of software you take on Linux for granted is, well, just one recompile away.

---

linux(1)> cd /tmp
linux(2)> wget http://dlc.sun.com/osol/opensolaris/2008/05/os200805.iso
linux(3)> sudo mount /tmp/os200805.iso /mnt/1 -o ro,loop
linux(4)> find /mnt/1 # explore the layout of the LiveCD
linux(5)> find /mnt/1 \! -type d -a \! -type f -exec ls -go  {} \;
linux(6)> file /mnt/1/boot/x86.microroot
linux(7)> gzip -dc < /mnt/1/boot/x86.microroot > /tmp/image
linux(8)> file /tmp/image
linux(9)> sudo mount /tmp/image /mnt/2 -o loop,ro,ufstype=sunx86
linux(10)> ls /mnt/2/etc/fs* /mnt/2/usr/lib/fs* # what FSes are there?
linux(11)> grep mount /mnt/2/lib/svc/method/* # what mounts everything?
linux(12)> cat /mnt/2/etc/shadow # what accounts are available?
linux(13)> wget http://blogs.sun.com/rvs/resource/delofi.c
linux(14)> cc delofi.c -o delofi -lz
linux(15)> ./delofi /mnt/1/solarismisc.zlib /tmp/solarismisc.image
linux(16)> ./delofi /mnt/1/solaris.zlib /tmp/solaris.image
linux(17)> file /tmp/solarismisc.image /tmp/solaris.image
linux(18)> ls -log /tmp/solarismisc.image /tmp/solaris.image
linux(19)> sudo mount /tmp/solaris.image /mnt/3 -o ro,loop
linux(20)> sudo mount /tmp/solarismisc.image /mnt/4 -o ro,loop
linux(21)> rlogin solaris

solaris(1)> su - root
solaris(2)# lofiadm -a /net/linux/tmp/image
solaris(3)# mount -F ufs /dev/lofi/1 /mnt
solaris(4)# cd /mnt/
solaris(5)# mkdir etc/fs/pcfs
solaris(6)# mkdir usr/lib/fs/pcfs
solaris(7)# cp /usr/lib/fs/pcfs/* usr/lib/fs/pcfs
solaris(8)# cp /usr/lib/fs/pcfs/mount etc/fs/pcfs/
solaris(9)# cp /usr/kernel/fs/pcfs kernel/fs/
solaris(10)# cp /usr/kernel/fs/amd64/pcfs kernel/fs/amd64/
solaris(11)# find . -name pcfs
./kernel/fs/amd64/pcfs
./kernel/fs/pcfs
./usr/lib/fs/pcfs
./etc/fs/pcfs
solaris(12)# cd `dirname lib/svc/method/live-fs-root`
solaris(13)# patch < __EOP__
--- /tmp/live-fs-root   Fri May 23 12:46:33 2008
+++ lib/svc/method/live-fs-root Fri May 23 12:54:23 2008
@@ -174,10 +174,12 @@

        /sbin/listusb | while read dev rdev
        do
-               /usr/lib/fs/ufs/fstyp $rdev 2>&1 | grep "^ufs$"
-               if [ $? -eq 0 ]
+                usb_fstype=""
+               /usr/lib/fs/ufs/fstyp $rdev 2>&1 | grep "^ufs$" && usb_fstype="u
+                /usr/lib/fs/pcfs/fstyp $rdev 2>&1 | grep "^pcfs$" && usb_fstype
+               if [ -n "$usb_fstype" ]
                then
-                       /sbin/mount -F ufs -o nologging,noatime $dev /.cdrom ||
+                       /sbin/mount -F $usb_fstype -o nologging,noatime $dev /.c
                        if [ -f /.cdrom/solaris.zlib ]
                        then
                                echo "" > /.liveusb
__EOP__
solaris(14)# umount /mnt
solaris(15)# lofiadm -d /dev/lofi/1
solaris(16)# exit
solaris(17)$ gzip -c < /net/linux/tmp/image > /net/linux/tmp/x86.microroot.new

linux(22)> cd /mnt
linux(23)> wget http://mediacast.sun.com/users/rvs2/media/x86.microroot
linux(24)> mv x86.microroot x86.microroot.new # or we could've used the one from Solaris
linux(25)> cd /mnt/1
linux(26)> sudo rsync -a boot platform solarismisc.zlib solaris.zlib \
                  jack root .catalog .image_info COPYRIGHT LICENSE /media/disk
linux(27)> mv /media/disk/boot/x86.microroot /media/disk/boot/x86.microroot.old
linux(28)> cp /tmp/x86.microroot.new /media/disk/boot/x86.microroot
linux(29)> wget http://blogs.sun.com/rvs/resource/stage1.5.bin
linux(30)> wget http://blogs.sun.com/rvs/resource/mbr.bin
linux(31)> sudo dd if=/tmp/mbr.bin of=/dev/sdb bs=1
linux(32)> sudo dd if=/tmp/stage1.5.bin of=/dev/sdb bs=512 seek=1

linux(33)> touch /media/disk/unique-file-to-be-followed 
linux(34)> sudo grub 
   grub> find /unique-file-to-be-followed 
         (hd1,0) 
   grub> root (hd1,0) 
   grub> setup (hd1)
   grub> quit 
linux(35)> rm /media/disk/unique-file-to-be-followed