[PATCH] fails to boot if RAID (dm-) devices are detected

Binary package hint: casper

I set up a persistent live USB and installed some updates that triggered an initrd rebuild, so I thought I'd copy the new version into /casper on the USB stick and use it. Sadly, booting failed, apparently because I'd also installed the lvm2 package. The problem seems to be that casper sees the filesystem on one of the logical volumes and decides to use that as the livefs. From casper.log:

+ echo /sys/block/dm-0 /sys/block/dm-1 /sys/block/dm-2 /sys/block/dm-3 /sys/block/dm-4 /sys/block/dm-5 /sys/block/dm-6 /sys/block/loop0 /sys/block/loop1 /sys/block/loop2 /sys/block/loop3 /sys/block/loop4 /sys/block/loop5 /sys/block/loop6 /sys/block/loop7 /sys/block/ram0 /sys/block/ram1 /sys/block/ram10 /sys/block/ram11 /sys/block/ram12 /sys/block/ram13 /sys/block/ram14 /sys/block/ram15 /sys/block/ram2 /sys/block/ram3 /sys/block/ram4 /sys/block/ram5 /sys/block/ram6 /sys/block/ram7 /sys/block/ram8 /sys/block/ram9 /sys/block/sda /sys/block/sr0
+ tr \n
+ grep -vE /(loop|ram|fd)
+ sys2dev /sys/block/dm-0
+ sysdev=/block/dm-0
+ /sbin/udevadm info -q name -p /block/dm-0
+ echo /dev/mapper/vg-jaunty
[..]
+ [ ext3 = squashfs -o ext3 = ext4 -o ext3 = ext3 -o ext3 = ext2 ]
+ ln -s /dev/mapper/vg-jaunty /dev/mapper/vg-jaunty.ext3
+ echo /dev/mapper/vg-jaunty.ext3
+ return 0
+ livefs_root=/dev/mapper/vg-jaunty.ext3
+ [ /dev/mapper/vg-jaunty.ext3 ]
+ break

The problem is this code in casper:find_livefs() :-

[..]
        elif [ "${fstype}" = "squashfs" -o \
                "${fstype}" = "ext4" -o \
                "${fstype}" = "ext3" -o \
                "${fstype}" = "ext2" ]; then
            # This is an ugly hack situation, the block device has
            # an image directly on it. It's hopefully
            # casper, so take it and run with it.
[..]

I'm not sure this works anyway, as it is only called for non-cdrom, non-partitioned devices - otherwise this bug would manifest far more often. Unless anybody is known to be relying on it, my strong suggestion would be to remove it. The alternative is to (a) move it into check_dev to make it work for all devices, and then (b) build a list of possible locations for the livefs in the order of likelihood, and then chose the best after a certain arbitrary amount of time has elapsed (because we have to wait for SATA and USB devices to be detected) -- all of which seems pretty horrible. If there is a need to have to live filesystems directly on block devices, wouldn't it be easier to require them to have a .disk/casper-uuid-generic file we could check?

This was seen in casper 1.173, but I presume the code's been there for ages.