Disclaimer: This part of the tutorial will require the use of hard disk manipulation tools. You should only follow this tutorial if you understand what you are doing. You are entirely responsible if something goes terribly wrong.

(Link to Intro and Part 3)

Xandros is quite different from gentoo. Xandros is reported to have customised their distro for the EEE-PC. I'm afraid I find their EEE-PC package to be a thin veneer of custom desktop over a painfully generic setup with a few fixes for support of unusual hardware.

Why continue to use it? Their work on the integration of unusual hardware into the thin veneer of custom desktop environment is really very very good. It makes stuff like that 'sugar' business look like… …exactly what it is. Refer also the brief for this whole exercise: “Why I Bother”

We've already been down a few paths on this bit that might seem obvious. Support for some pretty basic stuff (like mounting a root filesystem on a USB key by it's UUID) is broken by the Xandros kernel's config (designed for installation on generic hardware) and some of the bits that are missing from the Xandros busybox ?source/build?. Someone has also monstrously mangled something that affects the assignment of devices to device files. This makes guessing the correct device name pretty chancy. There are no filesystem tools in the initrd's busybox build. We could have used tune2fs to find filesystems by UUID, but alas it's not there…

We have a new plan though. It's less elegant than plan A, and plan B. It's a damn site more elegant than plan X though.

OK. I've made a bit of a mess of my working directory. Let's tidy up shop. We really only need:

0x0065 working # ls -l
total 1802792
-rw-r--r-- 1 root root 922562767 2008-07-02 20:05 loop-eee.gz
-r-xr-xr-x 1 root root 915895685 2008-07-01 20:11 P701L.gz
-r-xr-xr-x 1 root root   4194304 2008-07-01 20:12 usb.img

0x0065 working # fdisk -lu usb.img 
You must set cylinders.
...
...
Units = sectors of 1 * 512 = 512 bytes
  Device Boot      Start         End      Blocks   Id  System
usb.img1              62     2738105     1369022    6  FAT16

See? Never assume.

0x0065 working # bc       
62*512
31744
quit

0x0065 working # mount -o loop,offset=31744 usb.img /mnt/tmp/

0x0065 working # cp -r /mnt/tmp/boot .

0x0065 working # umount /mnt/tmp/

0x0065 working # cp boot/initrd.gz .

0x0065 working # gunzip initrd.gz 

0x0065 working # file initrd 
initrd: Linux rev 1.0 ext2 filesystem data (mounted or unclean) (errors)

Nice! It's not all hard work! () this Xandros restore key has some interesting features. While you're in the initrd rescue image, don't forget to check out the /sbin/xanfwloader shell script.

0x0065 working # mount -o loop initrd /mnt/tmp/

0x0065 working # chroot /mnt/tmp/ /bin/sh

# busybox mount -t proc none /proc/

# busybox ls /bin/
busybox  init     sh

# busybox ls /sbin/
udev         xanfwloader

# busybox --install -s

# ls /bin
[                cut              hexdump          mv               test
[[               dd               init             pidof            top
ash              df               installcomplete  ps               touch
bunzip2          dmesg            kill             realpath         true
busybox          echo             killall          reset            umount
bzcat            eject            ln               rm               vi
cat              env              ls               rmdir            volname
checkiso         expr             mkdir            sed              zcat
chmod            fgrep            mkfifo           sh
clear            find             mknod            sleep
cmp              grep             more             sort
cp               gunzip           mount            tar
# ls /sbin/
chroot       init         lsmod        poweroff     switch_root
fdisk        insmod       mdev         reboot       udev
halt         losetup      pivot_root   rmmod        xanfwloader

Where ever you stand on the whole “vi vs emacs” debate, I don't see an emacs symlink. Do you? If you're having fun in here, I'd get used to it's absence.

NOTE: You can exit the change root jail easily by hitting [ctrl]-[d] at an empty command prompt.

On the other hand, something I consider to be not just bog standard, but rather CRITICAL AND ESSENTIAL for a 'rescue' image is filesystem tools. Busybox supports both mke2fs and tune2fs! NEITHER are included in the Xandros build though… breathtaking …The default Xandros 'rescue' image mounts the restored hard disk & chroots over to use filesystem tools, but we have a chicken & egg dilemma. The image containing the filesystem tools is on the partition that we'd sensibly use the tools to find… (tune2fs would be a simple way to search for which filesystem matched our USB restore key's UUID)… …of course if the Xandros 'custom' kernel had support for the EEE-PC's USB subsystem built in… …I'm going to stop talking about our 'half a rescue' image at this point.

Maybe we can easily explain HOWTO build the other half of our rescue image for a 32bit build target more easily in Part 5. We can only hope. It's probably more like a Part 6.

The default Xandros restore key does all this stuff to try & find the EEE-PC hard disk, & then if it succeeds, it ignores the lot & blindly scrubs whatever happens to be /dev/sda at the time. I'm beginning to suspect that this explains some of the hanky panky with hard disk to device file assignment playing musical chairs during the boot process.

So we need a way to identify our USB restore key relatively reliably. Lets go the cludge for now. Once we have a Xandros install worth customising, we'll build busybox properly & add a complete udev. Then we can easily and accurately find our USB restore key by it's filesystem UUID.

The following is a semi-random / uncommon thing of about the right size that I can re-call easily. (I can never remember long numbers)

USB –> 555342 (ascii to hex code)

0x0065 working # bc
ibase=16        # change input to base 16 (hex)
555342          # hex code
5591874         # base 10 (dec) output
quit

0x0065 working # bc
5591874/1024
5460            # Let's make our boot partition 5460K long

You will find that the cut down udev in the initrd only makes device files for the first partition of USB keys. (probably because Microsoft Windows only supports the first partition… …and they want to be like Bill.) Let's make our second partition a vfat partition of an unusual length (ROUGHLY ~5Mb) and put our restore image on a first partition where the length isn't important but the filesystem is to be ext3. My impression is that this is a fairly unusual combination. That way a base level windows user won't accidentally scrub our boot partition, but we can replace & resize the restore partition without major re-work. It also means that our restore script doesn't need to touch it's boot partition. Yes, it's a bit random & cludgie… …but it'll get the ball rolling past the limitation of the default restore image…

0x0065 working # fdisk /dev/sdf

0x0065 working # fdisk -lu /dev/sdf

Disk /dev/sdf: 2063 MB, 2063597056 bytes
63 heads, 62 sectors/track, 1031 cylinders, total 4030463 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xd072c5fa

   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1              62     3905999     1952969   83  Linux
/dev/sdf2         3906000     3921623        7812    e  W95 FAT16 (LBA)

0x0065 working # mkfs.ext3 -I 128 -j -L REEESTORE /dev/sdf1
mke2fs 1.40.9 (27-Apr-2008)
Filesystem label=REEESTORE
...

again you'll want the -I option to mkfs.ext3

0x0065 working # mkfs.vfat -n BOOTEEE -F 16 /dev/sdf2
mkfs.vfat 2.11 (12 Mar 2005)
WARNING: Not enough clusters for a 16 bit FAT! The filesystem will be
misinterpreted as having a 12 bit FAT without mount option "fat=16".

Grub is the only thing that'll be mounting the boot partition once we're done with it. Let's move on.

0x0065 working # mount /dev/sdf1 /mnt/backup/

0x0065 working # cp loop-eee.gz /mnt/backup/

make some coffee

0x0065 working # umount /mnt/backup/

and then drink it.

We'll update the initrd.gz file in boot once we're done with it. First let's:

0x0065 working # mount /dev/sdf2 /mnt/backup/

0x0065 working # cp -r boot /mnt/backup/

and

0x0065 working # vim /mnt/backup/boot/grub/menu.lst 

#
# Configured by Xandros Configuration system.
# Then fixed for your convenience.
#hiddenmenu
default=0
fallback=2
timeout=5

title EEE-PC Rescue Disk
        root (hd0,1)
        kernel /boot/vmlinuz 
        initrd /boot/initrd.gz

title EEE-PC Erase & Re-image Script
        root (hd0,1)
        kernel /boot/vmlinuz REEESTORE=y
        initrd /boot/initrd.gz

0x0065 working # grub

 grub> root (hd5,1)/boot/ ##add a slash & hit [TAB] a few times to check you have the right disk...
 Possible files are: vmlinuz initrd.gz grub

grub> root (hd5,1) 
 Filesystem type is fat, partition type 0xe

grub> setup (hd5)
 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 (hd5)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd5) (hd5)1+15 p (hd5,1)/boot/grub/stage2 /boot/grub/menu.lst
.. succeeded
Done.

grub> quit

Back inside the restore key's initrd file (which we still have mounted at /mnt/tmp) is an /etc/init.d/rcS script that contains a little fancy ninja magic with dd & a lot of recursive “if” statements in order to cludge around the shortcomings of the restore key image. There are some parts of the script that are just earth shatteringly rubbish.

GENERAL NOTES:

• You may wish to feel cool & leet by chrooting into the initrd image & hacking up the rcS script in the spartan clean lines of vi… …take a look at how many recursive 'if' & 'for' statements there are before you decide to discard syntax highlighting & auto-indent
• You'll want a chroot in the initrd available at the same time though. The busybox provided is a bit special.
• I had real problems with resizing the xterm while using vi in the chroot. I'd advise against it.
• THERE IS NO /dev/sdc2 device file… …we have a partial bodge up of udev, but there is no /dev/sdc2.
• I suspect that our USB key ends up at sdc because the devices get shuffled around to allow the Xandros default script to ignore it's code for finding the EEE-PC disk and just blat the whole of sda (hard coded)
• If we boot our rescue key with the internal drive as the primary disk, the usb key ends up at sdb…
• mke2fs, tune2fs, printf and awk are not available inside the initrd.
• the busybox fdisk calls partition type 'e' something different from mine…

Let's adapt the restore script to our new partitioning system & get ready for the day when we have a real rescue disk at the same time.

0x0065 working # vim /mnt/tmp/etc/init.d/rcS 

#!/bin/sh
 
mount -t proc   none    /proc
mount -t sysfs  none    /sys
 
echo "0 0 0 0" > /proc/sys/kernel/printk
 
insmod /modules/usbcore.ko
insmod /modules/cdrom.ko
insmod /modules/sr_mod.ko
insmod /modules/usbhid.ko
insmod /modules/uhci-hcd.ko
insmod /modules/ehci-hcd.ko
insmod /modules/libusual.ko
insmod /modules/usb-storage.ko
#insmod /modules/zlib_inflate.ko
#insmod /modules/isofs.ko
insmod /modules/fat.ko
insmod /modules/vfat.ko
insmod /modules/nls_cp850.ko
insmod /modules/nls_iso8859-1.ko
 
clear
echo "Please wait 15 seconds for the USB subsystem to settle"
# printf timer would be a lot nicer here!
sleep 15
echo "Thank you for your patience"
echo
 
if [ -z "$REEESTORE" ]; then
        echo "Dropping into a rescue shell"
        echo "Please type 'reboot' to exit"
        echo
        /bin/sh
        exit 0
fi
 
for DRIVE in `ls /sys/block/ | grep sd | cut -c 1-3` ; do
        echo "Trying disk /dev/${DRIVE}"
        if [ "`fdisk -l /dev/$DRIVE | grep "MB," | cut -d " " -f 5 `" = "4001292288"  ]; then
                INSTALLTARGET=/dev/$DRIVE
                echo "We've found your EEE-PC hard disk at /dev/${DRIVE}"
                echo
        elif [ "`fdisk -lu /dev/$DRIVE | grep "Win95 FAT16" | cut -c 45-50 `" = "7812" ]; then
        ### elif [ "`tune2fs -l /dev/${DRIVE}1 | grep UUID | awk '{ print $3 }' `" = "ed5a4d9b-0cda-40aa-a597-44dbfbb6ea05" ]; then
                mount -t ext3 /dev/${DRIVE}1 /mnt
                if [ -f /mnt/loop-eee.gz ]; then
                        echo "We've found your restore image at /dev/${DRIVE}1"
                        echo
                else
                        umount /mnt
                        echo "DANGER: $DRIVE looks like a restore key"
                        echo "but the restore image is missing"
                        echo
                fi
        else
                echo "/dev/$DRIVE is not the device you're looking for."
                echo
        fi
done
 
if [ -z "$INSTALLTARGET" ]; then
        echo "       !!! Sorry !!!        "
        echo "No EEEPC hard disk was found"
        echo "Dropping into a rescue shell"
        echo "Please type 'reboot' to exit"
        echo
        /bin/sh
        exit 1
fi
 
if [ -f /mnt/loop-eee.gz ]; then
        echo "We now have everything we need to do a"
        echo "total erase and re-image of the eee-pc"
        echo
        echo "Please enter \"yes\" to continue, or anything else to reboot."
        read APPROVAL
        if [ "$APPROVAL" = "yes" ]; then
                clear
                echo
                echo "Installation should take about 10 minuites."
                echo "We expect to write 7815024 blocks of 512 bytes."
                gunzip -c /mnt/loop-eee.gz | dd bs=512 of=$INSTALLTARGET
                echo
                echo "Thank you for your patience."
                echo "Please remove the USB key and hit enter to reboot:"
                read PAUSEFORUSER
                reboot
                exit 0
        else
                echo
                echo "Rebooting as per your requested."
                umount /mnt
                sleep 2
                reboot
                exit 0
        fi
else
        echo "       !!! Sorry !!!        "
        echo "Can't find the restore image"
        echo "Dropping into a rescue shell"
        echo "Please type 'reboot' to exit"
        echo
        /bin/sh
        exit 2
fi
 
echo "if you are reading this then something has gone terribly wrong."
echo "please report it as a bug."
exit 3

resist the urge to dispense with the error handling code until you understand the full power of the dark side of the Xandros 'rescue' image. I've been giving it a good solid thrashing…

If you've followed my ramblings this far then you could probably take it from here, but I'll continue for the sake of completeness.

You'd note that there's no boot sector in our image yet. That's what part 5 is for.

0x0065 working # umount /mnt/tmp/

0x0065 working # gzip -9 initrd

0x0065 working # cp initrd.gz /mnt/backup/boot/initrd.gz 

0x0065 working # umount /mnt/backup/

And we have enough to be dangerous… It works for me ...Let's give it a crack.