crypted lvm on raid does not boot (lvm device name ... does not begin with /dev/mapper/)

Since this has been fixed in Debian, hopefully this can be fixed in time for 10.04.1, if that applies. I'm relatively certain this would not qualify for an SRU since the bug is likely to only affect a very small percentage of users.

Debian bug #576488 is reported to be fixed by a patch taken *from* Ubuntu, so this is not the same bug.

Please post your /etc/crypttab.

I have crypted / over RAID1 "working" (appearing to work anyway), but if the RAID is degraded (which I just faked for testing purposes) then I get this error "cryptsetup: lvm device name (/dev/disk/by-uuid/...) does not begin with /dev/mapper/" .

The error message is odd given that, when the RAID is not degraded, the device name still doesn't start with /dev/mapper and yet cryptsetup seems to accept it.

% cat /etc/crypttab
md0_crypt UUID=8fa35b52-fc55-4f45-b31c-766296ab3a42 none luks

I also seem to have this problem but it is not RAID/MD, just encrypted LVM. I installed Lucid on my Thinkpad laptop a few weeks ago - a small /boot partition (/dev/sda1), the rest of the disk encrypted LVM (/dev/sda5). Everything worked. But a recent update has caused a boot failure. I only noticed this on Friday because I have been suspending, not restarting my laptop.

Trying to boot the new kernel FAILS :

menuentry 'Ubuntu, with Linux 2.6.32-22-generic'

I get the error :

cryptsetup: lvm device name (/dev/disk/by-uuid/fb9559fc-9bf7-4f74-b1a1-a44e49d82d92) does not begin with /dev/mapper/

I can boot the previous, original kernel OK :

menuentry 'Ubuntu, with Linux 2.6.32-21-generic'

Software :

initramfs-tools 0.92bubuntu78
cryptsetup 2:1.1.0~rc2-1ubuntu13
grub-pc 1.98-1ubuntu6

I will attach some information files :

/etc/crypttab
blkid (output)
fdisk -l /dev/sda (output)
/etc/fstab
/etc/default/grub
/boot/grub/grub.cfg
pvdisplay (output)
vgdisplay (output)
lvdisplay (output)
uname -a (output)

Well, I had to "fix" this for myself today because I did an update and some linux-image stuff was removed ("no longer used") and I couldn't boot any kernel afterwards. Previously, only the 2.6.32-23 kernel gave me the error and the 2.6.32-22 kernel was OK. I set GRUB to default to .22 because I was hoping it would get fixed and I was worried about breaking things worse (encrypted LVM, UUID's, boot, GRUB etc. scare me).

I managed to boot "recovery mode" - but before this I had an "initramfs" shell and :

1) cryptsetup luksOpen /dev/sda5 sda5_crypt
2) mount /dev/mapper/vgthera--n-root /mnt/root
3) backup the /etc/crypttab file (.bak) ([1] below)
4) create a new /etc/crypttab file ([2] below)

This above might have been what allowed me to boot "recovery mode", single user and see a correct "passphrase" prompt.

[1] /etc/crypttab - From :

sda5_crypt UUID=fb...d92 none luks

[2] /etc/crypttab - To :

sda5_crypt /dev/sda5 none luks

Booted single-user "recovery mode" - and recreated the initrd for each kernel I had i.e.

mkinitramfs -u -k 2.6.32-21-generic
mkinitramfs -u -k 2.6.32-22-generic
mkinitramfs -u -k 2.6.32-23-generic

On a reboot, I get prompted for the passphrase correctly :

Unlocking the disk /dev/sda5 (sda5_crypt)
Enter passphrase :

I am happy I am back running properly - but a bit of a disaster really. Something broke 10:04 seriously for me, some update soon after the release. The average user (let alone my Mum, who I have using Ubuntu) would have been dead in the water. Even here, I was seriously considering a complete reinstall.

After upgrade I've got the same problem.
Can't boot anymore, because of '...does not begin with /dev/mapper/...' error.

I've tried solution from #13, but doesn't work. Probably change should be done in initrd?
The other problem is that I can't even choose which kernel I want to boot, it's just silent. I've tried already to press TAB.

root@ubuntu:/etc# cat crypttab
sda1_crypt /dev/sda1 none luks

Not sure where the "-u" comes from now (looking at : man mkinitramfs), but the mkinitramfs should recreate the initrd's (used from the "recovery mode").

To get a GRUB menu, try pressing SHIFT. You have to be quick sometimes.

The error message that you get here
"cryptsetup: lvm device name (/dev/disk/by-uuid/...) does not begin with /dev/mapper/" comes due to the fact that the
conf/conf.d/cryptroot in initramfs contains a line with "source=UUID=<uuid>" instead of the intended source="/dev/mapper/<vol-group-path>" if there is a symbolic link from /dev/by /dev/disk/by-uuid/<uuid> to /dev/mapper/<vol-group>. Attaching a cryptsetup patch that fixes this part.

Currently Ubuntu's mdadm faces a few problems in autoassembly. However a assembly based on mdadm.conf with appropriate mdadm array definitions in /etc/mdadm/mdadm.conf (both in real root and initramfs) will help assemble the array at boot time.

I have kept the mdadm fixes for autoassembly to work at: https://edge.launchpad.net/~csurbhi/+archive/lucid?field.series_filter=
(kept in a ppa named lucid)

Note that the uuid needs to be updated for the autoassembly to work at boot time. This can be done by
1) installing the test mdadm ppa.
2) Note your uuid by mdadm --detail --scan
3) update-initramfs
4) try autoassembly by rebooting. This will still fail and you will get to an initramfs prompt. At this time, test if your hostname is set appropriately. If it is, then run "mdadm --assemble -U uuid. Note if your uuid has changed (it should at this point and correspond to your hostname)
3) try rebooting.
Once your uuid has been updated to correspond with your hostname, the autoassembly of the md devices should ideally work. However note that this is a test ppa and yet under testing. Please try at your own risk ;-) and ofcourse let us know if there are any bugs in it if you happen to catch them :-)

For now, the attached patch shall take care of the "/dev/mapper" error message!

Testing by wider audience is appreciated. Please consider this patch for maverick updates.

Guys, make sure what you are seeing is not your machine saving your from data loss. Bug #531240 (root raid_members opened as luks). Especialy if you are only seeing this occasionally/with not all member devices present.

The check to only open /dev/mapper/ is your last hold in preventing data loss by opening a member device (with the same md device UUID and the same filesystem UUID in the raid mirror case).

This seems to pevent cryptsetup to open a raid member device instead of an assembled array.

I think this bug should be addressed along with 531240. I'm not comfortable changing the symlink following in cryptsetup if there is a chance it will lead to data loss.

It seems like some additional work needs to go into the fix.

I'll unsubscribe the sponsors team for now, please resubscribe when ready.

I install Ubuntu Server 10.04.2 on crypted lvm over RAID1 "working" (appearing to work anyway), but if the RAID is degraded (which I just faked for testing purposes) then I get this error "cryptsetup: lvm device name (/dev/disk/by-uuid/...) does not begin with /dev/mapper/" .

@Kradllit
From the bugtracker you can see that ubuntus modifications to the raid package have been unsupported for years.
https://wiki.ubuntu.com/ReliableRaid

Ubuntus mdadm setup is in the general case not capable to degrade gracefully on boot. Instead of fixing the disabled notification of the admin/user in case of a failure, there was even a switch added to officially prevent the booting and graceful degration to happen automatically, as if that would have been possible in other than a most simple setup.

Cryptsetup making sure to open only a mapper device created by the raid system seems to have saved you from Bug #531240.

This is a very old LP bug, but for completeness it worth mentioning here that recently some patches were merged on initramfs-tools and cryptsetup, that allow a good experience booting with LUKS-encrypted rootfs on top of a degraded RAID1 array; for details, please check: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980

Cheers,

Guilherme