The EEE's init RAM fs

Having usually an initrd.img of about 7 MB in Ubuntu Hardy, the EEE image is small:
lulu:/home/bav> ls -lh initramfs-eeepc.img 
-rw-r--r-- 1 bav bav 1,1M 2008-06-18 19:53 initramfs-eeepc.img
Unpacking gives me: All binaries are links to busybox: I really stumbled at this point:
lulu:/home/bav/tmp/eee> ls modules/
lulu:/home/bav/tmp/eee> 
Oops ! How do they do this ? Let's check init:
lulu:/home/bav/tmp/eee> grep mod init 
#insmod /mnt-system/lib/modules/$VERSION/kernel/fs/aufs/aufs.ko > /dev/null
Used to have initrds with quite a few modules, I now looked at the EEE's init. It is very straightforward. init can be controlled somewhat by environment variables which all start with XANDROS:
XANDROSSCAN and XANDROSRESTORE are set when you boot the appropriate
Grub entries "Perform Disk Scan" and "Restore Factory Settings". If
for some reason you want set set XANDROSBOOTDEBUG, one way is to edit
the GRUB entry "Normal Boot".

Per default, grub is configured to show no menu and to boot the default entry immediately (timeout=0). At least for my EEE there is no point in pressing ESC during startup as some people on the net recommend.

As stated in the Asus "Software-Manual" you have to press F9 instead. When the grub menu appears edit the "Normal boot" entry. Remove the keyword quiet if you want to see all output and append XANDROSBOOTDEBUG=1. Grub does not know your keyboard layout and defaults to an american layout.
The first lines of the init script mount the pseudo file systems /proc and /sys, thus making a lot of kernel data available in user land. Writing "0 0 0 0" to /proc/sys/kernel/printk will suppress a lot of kernel output. In my Ubuntu Hardy I have
lulu:/home/bav/tmp/eee> cat /proc/sys/kernel/printk
4	4	1	7
If you did set XANDROSBOOTDEBUG to some value, you will get a debug shell now.

Normally init will mount the root-filesystem now. Typically this will be /dev/sda1 (see /proc/cmdline for root=), which will mounted READONLY now:
mount -t ext2 -o ro /dev/sda1 /mnt-system
Normally the next step is to put the "System is starting up" splash on the screen. In case of any difficulties it might be a good idea to avoid this splash. To do so, append nosplash to the APPEND line. You will see all kernel messages now, which hopefully will help to analyse the problem.

Next action in init is to mount the user partition. The init script strictly assumes this to be on /dev/sda2:
mount -t ext3 -o rw,noatime /dev/sda2 /mnt-user
Finally another mount is done:
mount -t aufs -o br:/mnt-user:/mnt-system none /mnt
aufs is short for "Another Union Filesystem". Basically it is an Overlay Filesystem, which makes a readonly filesystem appear as writetable. This is achieved by putting a (small) writetable filesystem on top of a (large) readonly filesystem. AFAIK aufs is a spinoff of the Union filesystem.

br stands for branch, followed by the currently writable mounted mnt-user and the readonly mounted mnt-system. The resulting overlay filesystem may be accessed via the mount point /mnt.

Three interesting commands are left. The mounted trees /mnt-system and /mnt-user are atomically moved to other places:
mount --move /mnt-system /mnt/.ro
mount --move /mnt-user /mnt/.rw
and finally
exec switch_root /mnt /sbin/fastinit "$@" /mnt/dev/console
I'm currently unsure of the differences between pivot_root and switch_root. Basically they both move the current root filesystem from RAM to /mnt (the aufs in our case). Additionally the init process is started (with PID 1). It is /sbin/fastinit for the EEE.
Gerd Bavendiek<gerd.bavendiek@googlemail.com>
Last modified: Wed Sep 10 20:29:48 CEST 2008