Binary package hint: casper
ubuntu-9.04-rc-desktop-i386.iso
Casper is unable to find the file casper-rw in the root directory of a FAT filesystem located on partition 1 of a USB drive (/dev/sdb1 on target system). Kernel booted with the "persistence" option.
Inside initrd.gz, the file scripts/casper has the persistence. It looks for casper-rw for whole system persistence and home-rw for home directory persistence. It uses a function find_cow_device() in scripts/casper-helpers. This in turn makes use of /usr/lib/klibc/bin/fstype to report the filesystem type for each partition it finds. Unfortunately, this program is returning UNKNOWN for the usb drive partition, among others. find_cow_device expects this program to return "vfat". This is impossible since fstype has no test for FAT filesystems, as verified by looking at the source for klibc-1.5 and by running strings on it.
This bug may have been introduced in a hurried attempt to prevent casper from mounting, and therefore replaying the journal file, on journaling filesystems on a system in hibernation. Or perhaps a modified version of fstype.c was used which was then reverted.
I am, incidentally, using a manually constructed USB image due to a failure of usb-creator to put the files on the filesystem in a sensible order that can be booted on systems with a BIOS 512MB (no LBA) limit on usb devices presented as floppies. It has been carefully checked using diff and cmp to be identical to the image created by usb-creator except for a sensible file order, syslinux.cfg is in /syslinux/ where it belongs, and isolinux.cfg is still there. The differences are not relevant to this bug. The initrd.gz file on the original ISO image was checked to contain this bug. /usr/lib/klibc/bin/fstype (on running system) and /casper/initrd.gz/bin/fstype (from ISO image) where both checked with "strings $filename | fgrep -i fat". Neither is capable of detecting FAT filesystems and returning the string "vfat".
http://www.freelabs.com/~whitis/linux/usb_ubuntu_9.04RC/index.xhtml
The usb partition was formated using mkfs.msdos (on a debian system). But, again, not relevent since the bit pattern present is irrelevant to detection failure when there is no code to check for FAT in the first place.
Actually, double checking, the get_fstype() function tries a second method if fstype returns "unknown": it uses "/lib/udev/vol_id -t /dev/sdb1". And, in fact /lib/udev/vol_id, when run from within the (initframfs) prompt, does display "vfat" and get_fstype is actually returning "vfat". So, the title of the bug is wrong.
I have found that if I type "persistent" on the kernel command line, I drop out to (initramfs) prompt, which I am exploiting to look around in the (initramfs) environment.
/casper-rw-backing has been created but isn't mounted.
Running try_mount "/dev/sdb1" "/casper-
gives
/bin/sh: head: not found
/bin/sh: head: not found
/bin/sh: head: not found
mount: cannot read /etc/fstab: No such file or directory
/bin/sh: panic: not found
which I fixed using PATH=$PATH:
now try_mount succeeds in mounting.
and
if [ -e "/casper-
says yes.
(initramfs) find_cow_device casper-rw
stdin: error 0
/dev/loop1
but running ". /scripts/casper" still doesn't mount anything on /cow (nor does it report any errors), even though I export PERSISTENT="Yes"
(initramfs) mount -t vfat -o rw,noatime /dev/loop1 /cow
mount: mounting /dev/loop1 on /cow failed: Invalid argument
(my fault, it is ext3, not vfat)
(initramfs) setup_loop "/casper-
/dev/loop2
(initramfs) losetup -a
/dev/loop0: [0811]:30 (/cdrom/
/dev/loop1: [0811]:35 (/casper-
/dev/loop2: [0811]:35 (/casper-
(initrams) mount -t ext3 -o rw,noatimer /dev/looop1 /cow
Works
Can now see /cow/lost\+found
exit 1 leaves (inirtramfs) mode
sleep now