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.

Source Material:
Let me begin by offering my humblest thanks to whomever is/are responsible for: http://wiki.edseek.com/guide:mount_loopback I love your work! Not just another guide on mount -o loop… covers partitions within disk images! It offers three methods… …below is the easy option believe it or not!

(Links to Intro and Part 2)

We now need to unzip the Asus supplied image, locate the first partition and mount it through a loop back, with an offset:

0x0065 working # gunzip P701L.gz

0x0065 working # fdisk -l -u P701L 
You must set cylinders.
You can do this from the extra functions menu.
Disk P701L: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000
Device Boot      Start         End      Blocks   Id  System
P701L1              63     4819499     2409718+  83  Linux

So we already know that 63*512=32256, but it is worth checking as we'll see later.

0x0065 working # mkdir -p /mnt/backup

Mount the first partition from the image through a loopback:

0x0065 working # mount -o loop,offset=32256 P701L /mnt/backup/

0x0065 working # ls /mnt/backup/
bin   disks  initrd      media  proc  srv  usr
boot  etc    lib         mnt    root  sys  var
dev   home   lost+found  opt    sbin  tmp  vmlinuz

We now have our new image and the Asus image mounted. Let's transfer

0x0065 working # rsync -vax /mnt/backup/ /mnt/key/
...
... # yawn
...
... # make coffee
...
var/www/htdig/star_blank.gif
var/www/htdig/star_blank.png

sent 1979996787 bytes  received 1600506 bytes  4898880.82 bytes/sec
total size is 1974897837  speedup is 1.00 

0x0065 working # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/loop1             3774912   2150484   1432668  61% /mnt/key
/dev/loop0               69978      4996     61370   8% /mnt/key/boot
/tmp/working/P701L     2371820   2147312    104024  96% /mnt/backup

0x0065 working # umount /mnt/backup/

We're now done with the original disk image. You can 'file it with the others' or keep it for reference.

0x0065 working # gzip -9 P701L

Fixing the stock Xandros initrd to remove unionfs is covered quite well in another tutorial titled Removing UnionFS/aufs that's really very good. To my mind though, the initrd is seriously quick & dirty. The more I touch it, the more I hate it. It is responsible for 80% of the revisions to this set of five tutorials!

It is worth noting that once the mounting of unionfs root is done, the initrd basically just hands off to fastinit anyway. It doesn't even load any modules. There is filesystem checking code, but it looks more like code optimised to blat the user partition (which we don't even have anymore) & start again with a clean install…

As a counter-point fastinit requires the root filesystem to be mounted read/write, so I seriously doubt it does any filesystem checking… …at least you'd think not. It's really your call. If you want to edit the initrd file & include it, then I assume it's an informed decision and that you can work out the changes that need to be made to what follows. Removing the initrd file completely, however solves all of my problems.

The initrd file is gzipped, but has no .gz file extension. Inside is a cpio archive. (That's like your grand daddy's tar file.) It seems as though the initrd file needs to remain a gzipped cpio file because the default switchroot program in the initrd doesn't support unmounting and swapping out an ext2 loopback initrd file. If you want to have a go at working a loopback anyway, don't forget that current Grub doesn't support the default inode size of current mkfs.ext2. Have fun. Let me know how you do.

Speaking personally, I'm more done with the Xandros initrd file than words can say.

0x0065 working # cd /mnt/key/boot/grub

The default grub setup is seriously annoying. We're going to use a better /boot/grub/menu.lst. We'll also get rid of the hiddenmenu rubbish & give a brief flash of grub menu rather than that F9 obfuscation business. We're not pretending to be Windows 98 here. Just hitting the down arrow will then take you to the grub menu.

0x0065 grub # vim menu.lst

#
# Configured by Xandros Configuration system.
# and then fixed for your convenience
# hiddenmenu
default=0
fallback=1
timeout=1

title Normal Boot
        root (hd0,0)
        kernel /boot/vmlinuz root=/dev/sda2 rw init=/sbin/fastinit

title Backup Boot
        root (hd0,0)
        kernel /boot/vmlinuz.bak root=/dev/sda2 rw init=/sbin/fastinit

# /sbin/fastinit performs no filesystem checks.
# If you feel inspired you can setup init to check the filesystem & then either go to a rescue shell or reboot.
# FYI: There are problems with Xandros' shutdown/reboot if you boot with /sbin/init & login through kdm.

title Perform a Filesystem Check
        root (hd0,0)
        kernel /boot/vmlinuz root=/dev/sda2 ro init=/sbin/init

# the entries below are to avoid the need to teach a user how to edit the bios...
# If you know how to change the disk boot order in the bios then they aren't needed.

title Boot from USB Rescue System
        root (hd1,0)
        kernel /boot/vmlinuz
        initrd /boot/initrd.gz

title Boot from USB Erase and Restore Tool
        root (hd1,0)
        kernel /boot/vmlinuz REEESTORE=y
        initrd /boot/initrd.gz

Please note the four menu entries:

1. A normal option that boots as the default after 1 second.You'll note that:
   • we are avoiding the initrd file completely as it causes me pain.
   • it references a kernel with a shorter name. It's standard practice to link a default kernel name to the kernel you want to use as your default.
   • Asus/Xandros have 'bodgied up' the EEE-PC such that it's hard disk always REVERTS to be /dev/sda. This is why when you change the bios to boot from a USB disk, it ends up at /dev/sdc… …looking at the 'rescue' key's gzip | dd line in the restore script gives a hint as to why. It will make you feel ill. Maybe you can guess already.
   • Mount by UUID support seems to be broken in Xandros.
   • You need to mount root as rw, else fastinit will fail.

1. A backup option that boots as the fallback. You'll note that:
   • it references a link to a backup kernel… …in case one you're testing doesn't work out.
   • It's otherwise much the same as the above.

1. A couple of boot option for the restore key so we can avoid having to explain what a bios is to someone with English as a second language on the other side of the globe who's contacting you through their laptop & is about to re-image their laptop… …You'll note that:
   • Unfortunately UUID support is broken here too, at this stage at least. It would solve lots of problems.
   • We will be customising the initrd file for this, as the initrd image contains both the rescue disk & restore script. It's really 100x better that the main one.
   • You can safely ignore them if you know how to configure a bios.

Some basic house keeping / good practice… (>_<)

0x0065 grub # cd ..
0x0065 boot # ln -s . boot
0x0065 boot # ln -s vmlinuz-2.6.21.4-eeepc vmlinuz
0x0065 boot # ln -s vmlinuz-2.6.21.4-eeepc vmlinuz.bak

and some spring cleaning:

0x0065 boot # rm initramfs-eeepc.gz startup.fb

0x0065 boot # ls -l
total 4972
lrwxrwxrwx 1 root root       1 2008-07-09 21:50 boot -> .
-rw-r--r-- 1 root root   44421 2007-09-25 03:57 config-2.6.21.4-eeepc
drwxr-xr-x 2 root root    2048 2008-07-09 21:48 grub
drwx------ 2 root root   16384 2008-07-02 20:50 lost+found
-rw-r--r-- 1 root root      49 2007-09-25 04:10 patches-2.6.21.4-eeepc
-rw-r--r-- 1 root root 1228800 2007-10-19 22:57 shutdown.fb
-rw-r--r-- 1 root root  736915 2007-09-25 04:10 System.map-2.6.21.4-eeepc
lrwxrwxrwx 1 root root      22 2008-07-09 21:51 vmlinuz -> vmlinuz-2.6.21.4-eeepc
-rw-r--r-- 1 root root 1295928 2007-10-15 08:04 vmlinuz-2.6.21.4-eeepc
lrwxrwxrwx 1 root root      22 2008-07-09 21:51 vmlinuz.bak -> vmlinuz-2.6.21.4-eeepc

Don't worry. We'll add grub to the MBR after we install & then bring it back here when we customise & update our restore image.

0x0065 working # umount /mnt/key/boot 

0x0065 working # umount /mnt/key 

0x0065 working # losetup -a
/dev/loop0: [0833]:17285128 (loop-eee), offset 32256
/dev/loop1: [0833]:17285128 (loop-eee), offset 74027520 

0x0065 working # losetup -d /dev/loop0

0x0065 working # losetup -d /dev/loop1

0x0065 working # losetup -a

0x0065 working # gzip -9 loop-eee 

0x0065 working # ls -l
total 1807412
-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

So our disk image is a pinch over 900MB. It'll fit on the 1.3G partition that the Asus Boot Image puts on my 2G USB Key, but only having acess to part of the USB key is just… …irritating… …also there are some checks & balances, a few dirty hacks & general shadiness that need to be removed from the USB restore key… …so:

Now we're ready to Adapt the USB Restore Script to be More Simple & Flexible