Arch Linux

Profjim

Member

From: NYC

Registered: 2008-03-24

Posts: 658

Can't mount LUKS volume anymore during ramdisk stage of boot [SOLVED]

I have a custom initcpio hook, whose purpose is to mount multiple LUKS-encrypted volumes at the ramdisk stage of the boot sequence. One such volume contains my root; the other contains (among other things) my swap partition. Those volumes are lvm on-top-of LUKS on-top-of software RAID. It's complex, but it works well. I describe it here, and probably elsewhere too.

Anyhow, this has served me well for a year or two now. Only once did the custom hook need tweaking to stay in synch with the "encrypt" initcpio hook that's installed by core/cryptsetup.

This morning I finally pacman -Syu'd after a few weeks delay, and rebooted, and whoops, now it's broke. A few hours debugging later, I'm back into my machine, but puzzled by what's going on.

During the initcpio process, we get to this point:

/sbin/cryptsetup luksOpen /dev/md4 multicrypt

And that line seems to succeed. `/dev/mapper/multicrypt` now contains an alias to `../dm-0`, which is a block device. However when we then try to do this:

/bin/mount -t ext2 -n -r /dev/mapper/multicrypt /mountpoint

This now fails with an error saying something "mount failed -- no such device." (Although I mentioned lvm before, lvm isn't a factor here. The volume that isn't mounting is just straight LUKS on-top-of a software raid volume.)

What does work:

• I can boot from a USB key, mdassemble, luksOpen, and mount all my volumes just fine

• Downgrading what seems like the most likely culprit, mkinitcpio-busybox, back to 1.17.2, doesn't fix the issue. (Of course I re-ran mkinitcpio when appropriate.)

• I discovered that I can boot just fine using the fallback ramdisk.

Given the last point, my current best guess is that the versions of kernel + mkinitcpio-busybox + cryptsetup + ??? that I've now got installed require some extra module or something to be present on the ramdisk, that wasn't required before. With that piece missing, I can luksOpen my device---or at least appear to do so---but it won't be mountable. With the fallback ramdisk, the needed module or whatever is present on the ramdisk. (Does that sound like a likely diagnosis to others, too?)

Any ideas what I might now need? Or how I might go about figuring it out? There is no obviously relevant information displayed on my screen when the mount fails. There's an error about the padlock-sha module failing to load, but that message has been there for a long time.

My mkinitcpio.conf reads:

MODULES="aes-x86-64" # I'm guessing I now need to include some additional modules here.
BINARIES=""
FILES=""
HOOKS="base udev autodetect sata mdadm multicrypt lvm2 resume filesystems"

The "multicrypt" hook is my custom hook. Its "install" component (/lib/initcpio/install/multicrypt) is essentially the same as the /lib/initcpio/install/encrypt from core/cryptsetup. Both of those scripts copy the dm-crypt module, and all the modules underneath /lib/modules/2.6.37-ARCH/kernel/crypto/ to the ramdisk.

(BTW, is the gz-compresing of those modules something new? Does my hook need to do anything to accommodate that? The encrypt hook from the current version of cryptsetup doesn't.)

The "hook" component of my multicrypt hook is modestly different from the encrypt hook, but I believe everything can be ignored but the two lines I quoted above. The `cryptsetup luksOpen ...` line seems to work, but then the `mount ...` line fails.

Any ideas, or strategies for finding such, are welcome.

Last edited by Profjim (2011-02-26 16:21:20)

Synchrotron

Member

From: Kyiv, Ukraine

Registered: 2009-01-08

Posts: 13

Re: Can't mount LUKS volume anymore during ramdisk stage of boot [SOLVED]

Hooray, I am not alone with this issue.
The symptoms are very similar. The exceptions in my setup is the standard encrypt hook and that I don't have a software RAID.
Interesting enough is that I do have software RAID+LUKS+LVM2 in my another machine and that config continues to boot.
I am also able to boot normally with fallback image too.
I think the key problem to this is the unability to mount USB drive partition with the LUKS key on /ckey (that strange "no such device" message).
Would be nice the devs to see this topic.

Synchrotron

Member

From: Kyiv, Ukraine

Registered: 2009-01-08

Posts: 13

Re: Can't mount LUKS volume anymore during ramdisk stage of boot [SOLVED]

Profjim, you were absolutely right about the modules.
After posting my message I thought that perhaps the reason that partition can't be mounted is the absense of the filesystem module and that link almost proved my assumptions.
I have added the ext3 module in mkinitcpio.conf. The difference in my setups is that the live one uses ext3 and ext4, so both modules are included in boot image and USB partition is mounted normally.
While the broken one uses only ext4, ext3 module is not included and ext3 USB partition can't be mounted.
Hope that helps you.

Last edited by Synchrotron (2011-02-26 14:44:37)

Profjim

Member

From: NYC

Registered: 2008-03-24

Posts: 658

Re: Can't mount LUKS volume anymore during ramdisk stage of boot [SOLVED]

Thanks Synchroton. Indeed, the volume I cannot mount is an ext2 volume, and when I run /sbin/mkinitcpio, there are no live ext2 volumes, so the ext2 module is not copied to the ramdisk. The solution is to add ext2 to the MODULES lines in my /etc/mkinitcpio.conf. I will look for a place in the wiki to point this out.