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

Bug #385305 reported by Steve Dodd on 2009-06-09
This bug affects 3 people
Affects Status Importance Assigned to Milestone
casper (Ubuntu)

Bug Description

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.

Related branches

Steve Dodd (anarchetic) wrote :

Slight correction to the earlier post: the problematic code in question only seems to be called for non-USB/SCSI/IDE devices (anything whose udev path doesn't match "usb|pci-[^-]*-(ide|scsi|usb)") - I've no idea what devices these might be - onboard flash memory (MTDs) in embedded systems??

Anyway, removing the code in question solved my problem - patch attached.

Tormod Volden (tormodvolden) wrote :

I don't think it is necessary to rebuild the initrd to experience this bug. The shipped initrd has built-in support for dmraid for example, which creates dm-* devices. So you can't boot a Desktop CD if a RAID is around. See bug #388407.

Steve Dodd (anarchetic) wrote :

No dmraid machines around here, but yes, any "virtual" block devices look as if they would cause problems, ditto any odd (non-PCI, non-USB/IDE) hardware (perhaps on non x86 platforms.)

Do you know of / can you think of any situation where the "ugly hack" would do anything useful? If not, I'd be inclined to simply remove it.

If it does do something, then checking for a magic file in /.disk in the same way we do for loopback mounts would probably be the way to go.

Tormod Volden (tormodvolden) wrote :

Yes, I guess the "ugly hack" feature does more harm than good. Anyway, see alternative patches in bug #388407.

Changed in casper (Ubuntu):
status: New → Confirmed
summary: - rebuilt initrd with lvm fails to find live fs
+ [PATCH] fails to boot if RAID (dm-) devices are detected
Changed in casper (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Tormod Volden (tormodvolden)
Changed in casper (Ubuntu):
assignee: Tormod Volden (tormodvolden) → nobody
Colin Watson (cjwatson) wrote :

Thanks, I think this patch is probably the right answer - I've merged it for the next casper release.

Changed in casper (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.199

casper (1.199) karmic; urgency=low

  [ Tormod Volden ]
  * Scan device-mapper (RAID) devices for live filesystem (LP: #385305).

 -- Colin Watson <email address hidden> Tue, 06 Oct 2009 23:39:57 +0100

Changed in casper (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers