Altering /sbin/init

In x86.microroot, we need to alter /sbin/init to prepare the ZFS boot volume and call up the proper init. This appears simple, but there are a few adjustments that need to be made to ensure that when we hand control over to init, it has all the environment characteristics it needs. After conclusive tests, I have come up with the following replacement /sbin/init, to be inserted in x86.microroot.
Basically what we is import the real root filesystem (ZFS) from the barebones(but functional) ramdisk image...Once that is done, we need to move/remount the special filesystems that kernel has setup in /device(and other places) to our new root. This is the bulk of the script, as these needed to be tweaked in just the right way...
Before you implement this, ensure that the following modifications have been made to x86.microroot:
- /mnt2 exists inside x86.microroot AND it is empty.
Further, you may want to copy the kernel modules present in /usr/kernel to /kernel; even though they are non-essential, they will initialize devices like /dev/pts, which are essential to the *correct* function of certain programs (eg. terminal/gterm).

#!/bin/bash -x

export PATH=/bin:/usr/bin:/sbin:/usr/sbin

exec >/dev/msglog 2>&1
exec
# /bin/bash

echo "initializing devices"
echo "remounting root"
mount -F ufs -o rw,remount /devices/ramdisk:a /

echo "preparing devfsadm"
devfsadm
devfsadm -I
devfsadm -P
#/usr/lib/devfsadm/devfsadmd -v
echo "finding devices"
ls /dev/dsk

echo "Importing rpool..."
zpool import -f rpool
zfs umount /opt
zfs umount -f /export/home
zfs umount -f /export
echo "Mounting root file system..."
mount -F zfs rpool/ROOT/opensolaris /mnt2
ls /mnt2

echo "mounting /proc, dev, etc.."
chroot /mnt2 /sbin/mount -F mntfs mnttab /etc/mnttab
chroot /mnt2 /sbin/mount -F proc /proc /proc

chroot /mnt2 /sbin/mount -F tmpfs /etc/svc/volatile /etc/svc/volatile

mount -F lofs /devices /mnt2/devices
PATH=/mnt2/bin:/mnt2/usr/bin:/mnt2/sbin:/mnt2/usr/sbin
(cd /dev && tar -cf - .) | (cd /mnt2/dev && tar -xf -)
PATH=/bin:/usr/bin:/sbin:/usr/sbin
chroot /mnt2 /sbin/mount -F dev /dev /dev

chroot /mnt2 /sbin/mount -F ctfs ctfs /system/contract
chroot /mnt2 /sbin/mount -F objfs objfs /system/object

chroot /mnt2 /sbin/mount -F sharefs sharefs /etc/dfs/sharetab
echo "autopush and soconfig..." >/dev/msglog
chroot /mnt2 /sbin/autopush -f /etc/iu.ap
chroot /mnt2 /sbin/soconfig -f /etc/sock2path

#/bin/bash
echo "Executing chroot /sbin/init"
exec chroot /mnt2 /sbin/init $@

Save this as /sbin/init. Make sure it has the same permissions as the /sbin/init originally had. You may need to change the owner as well:
in a superuser shell (su)

$ ls -l /sbin/init
-r-xr-xr-x 1 root sys 58044 Apr 26 18:42 /sbin/init

if it doesn't look like that (not including filesize or timestamp

$ chown root:sys /sbin/init
$ chmod 555 /sbin/init

Good Hunting!

Previous Step
Next Step

Problem of the ZFS live boot

The Problem:
We want a live ZFS boot that can be installed on a usb drive and booted on any machine.

Target Selection:

Opensolaris is the only OS that really can harness ZFS in a stable manner, so it has to be a target...The problem is that the Opensolaris ZFS boot processes listed above are tied to the boot hardware. Let me explain--

The ZFS boot from 2008.05 uses the file zpool.cache to find where the boot device is, and zpool.cache stores record of where the device was plugged in as of the last boot. Reading from zpool.cache, kernel is able to find out what device contains the zfs-bootfs, as well as what pool it is a part of. This method relies on the fact that whatever was true (with regard to device locations) remains true when you start the computer next. It's great if you know your HD won't be moved, but a USB drive moved to a different port (on the same or different machine) will hold a different device number, and kernel will try to find the drive at a previous port during the boot, only to fail horribly.
I tried this and the verdict is that no boot from this method could ever be considered live...

The ZFS boot from SXCE b9X sounds a great deal better; it should, in theory, discover your ZFS pool, volume, etc. and then boot off of it regardless of its location. GRUB has actually been modified in this case to be able to read ZFS volume data from a drive, and thereby find the boot device. Unfortunately, this mechanism has some evil dependencies. While GRUB's findroot() finds the zfs volume to be booted from, it doesn't know that device's location, so it queries the volume for that information. Because kernel has not started yet, and device have not really been set up, the zfs volume simple recalls where it was last connected, and returns that to GRUB. GRUB passes this potentially invalid information on to kernel, and in the case of a live or moved disk, kernel vomits it right back out. No live boot here...

The Live CD/USB doesn't boot off ZFS, but it provides an interesting model for a boot; load a self-contained ramdisk image, start kernel, and mount the USB drive's filesystem and nonessential files shortly thereafter. This means we have a running system before any media has been mounted, and we can mount things from there.

Previous Step

Next Step

<<<<>>>>

Intro ZFS live boot

Hacking Project: Create the first live ZFS boot setup using Opensolaris.

Background:

Linux users are well aware of the great number of distributions that are available in a live cd form; since Knoppix first demonstrated its practicality, the Linux live distro has become the quickest way to avoid using Windows on any platform. Today, linux live distros are cleverly setup with read-write capable filesystems and on-the-fly hardware recognition. Suffice to say that ramdisk and creative volume mounts/symlinks no longer rule the business.

OpenSolaris is also available in a live cd form: 2008.05
While the 2008.05 live cd is not as sophisticated as the Ubuntu or Slax live distros, it is smooth enough to use.

Linux Live USB distros have allowed users a mobile, persistent OS in a form that has become even more useful than live CD; usb media is cheap enough that pocketing one's desktop AND files is practical.

OpenSolaris has a live USB distro based on 2008.05(developer preview), as well as tools to build one with an ISO (distroconstructor project).

ZFS is one of the most amazing filesystems in existence. It is powerful in its ability to separate FS from hardware, and thereby expand or contract to accomodate varying numbers of storage devices with redundancy and decent performance. Sun does a better job of explaining it than I will here. Opensolaris has been tailored to live and breathe ZFS, and is the only OS with fully functioning ZFS support.

Continue to Next Step