lvm2 over Luks: kernel panic

Question

lvm2 over Luks: kernel panic

royneary opened this issue 12 years ago · comments

Hi tokiclover,

first of all thank you for sharing your great script. I've been using version 0.5 for some time and now wanted to upgrade to the ebuild from your overlay. My setup is as follows:

/boot on /dev/sda1 (ext2)
Luks encrypted /dev/sda2 with lvm2 volume group 'vg' in it
vg contains logical volumes 'root' (ext4) and 'swap'

Version 0.5 worked for this setup with the following kernel options:

kernel /boot/kernel-3.0.6-gentoo iroot=vg-root:c:ext4 iswap=swap:vg-swap ilvm=sda2_crypt-sda2,sda2_crypt-sda2 ikmap=de-latin1-nodeadkeys-x86_64.bin:

Back then I built the image as described in the DM-Crypt with LUKS article on the gentoo wiki:

find . | cpio --quiet -o -H newc | gzip -9 >/boot/initramfs-gentoo-crypt

So now after installing your ebuild (init version 0.10.0 2012/07/08 15:59:11) with useflags

bash bzip2 cryptsetup device-mapper e2fs symlink xz

from working directory /usr/local/share/mkinitramfs-ll/ I ran

/usr/local/sbin/mkinitramfs-ll.bash --luks --lvm --keymap

I moved '/usr/local/share/mkinitramfs-ll/usr' for it wouldn't start to build otherwise. The only thing I changed in grub.cfg was removing the colon at the end of the kernel line (I think it had to be added because of a bug in earlier versions). Then I tried to reboot and got a kernel panic.

When I built the image myself from the folder the script created I didn't get a kernel panic but for some reason init didn't run cryptsetup and then of course didn't find my volume group. It dropped me into a shell and I could run cryptsetup manually.

Do you have any idea what I'm doing wrong?

tokiclover · Answer 1 · Tue Jul 10 2012 01:53:59 GMT+0800 (China Standard Time)

Thanks for reporting, just move back the "usr" directory back and make an empty `usr/root' directory to solve the issue. Or else, remove $DISTFILES/mkinitramfs-ll-0.10.0.tar.gz file and resync my overlay in a few sec and merge back the package, after I push a new commit to solve this issue.

tokiclover · Answer 2 · Tue Jul 10 2012 02:01:40 GMT+0800 (China Standard Time)

Well, I forget to say that `usr' is almost required for version >=0.8, previous commit should solve it because I use a similar setup for my laptop: LVM on top of LUKS.

tokiclover · Answer 3 · Tue Jul 10 2012 03:01:42 GMT+0800 (China Standard Time)

Well, looking at you kernel cmdline, you could or rather should set up `ikroot=pwd ikswap=pwd'; this should avoid ebing dropped into a minimal shell when checking if ikroot and ikswap in getkey().

tokiclover · Answer 4 · Tue Jul 10 2012 03:03:32 GMT+0800 (China Standard Time)

Actually you shouldn't have to set up both for pwd mode, however set theme if you get kernel panic again.

Christian Ulrich · Answer 5 · Tue Jul 10 2012 03:29:31 GMT+0800 (China Standard Time)

Wow thanks for your replies. I resynced and merged again and now the image was built with existing usr directory. I tried

/usr/local/sbin/mkinitramfs-ll --luks --lvm --keymap

and

/usr/local/sbin/mkinitramfs-ll --all --keymap

and got the kernel panic in both cases. Adding ikroot and ikswap options didn't change it.
I also built it from the initramfs-3.0.6-gentoo-B10 directory with find/cpio/gzip again and got

volume group "vg" not found

just like before. In this case there are some more messages, I don't know if they're interesting for you. E.g.

mdev: unknown user/group '0:video' on line 57

tokiclover · Answer 6 · Tue Jul 10 2012 03:46:21 GMT+0800 (China Standard Time)

I don't get it, that kernel cmdline should work. Could you copy /run/log/init.log and attach it to this issue?

tokiclover · Answer 7 · Tue Jul 10 2012 03:53:12 GMT+0800 (China Standard Time)

As you have a kernel panic, try adding `ishrl=3m' to your kernel cmdline. So you will be dropped to a minimal shell before getting a kernel panic.

tokiclover · Answer 8 · Tue Jul 10 2012 03:56:12 GMT+0800 (China Standard Time)

Could you join an `ls -alh /dev/mapper' as well?

Christian Ulrich · Answer 9 · Tue Jul 10 2012 04:21:54 GMT+0800 (China Standard Time)

Adding `ishrl=3m' doesn't prevent my kernel to panic so I don't know how to get the log file. When I boot using the manually built image this the init.log:

[0]: export PATH=/sbin:/bin:/usr/bin:/usr/sbin HOME=/root
[0]: umask 0077
[0]: mkdir -p dev/pts proc run sys newroot mnt/tok
[0]: mount -t proc proc /proc
[0]: mount -t tmpfs -o mode=755 tmpfs /run
[0]: mkdir -p /run/log
[0]: mv -f /init.log /run/log

[0]: mount -t sysfs sysfs /sys

[0]: _modprobe boot
[0]: mount -t devtmpfs devtmpfs /dev
[255]: mount -t devpts -o gid=5,mode=0620 devpts /dev/pts
[0]: echo >/dev/mdev.seq
[0]: mdev -s
[0]: echo /sbin/mdev > /proc/sys/kernel/hotplug
[0]: ln -fs /proc/self/fd /dev/fd


[1]: test -f /etc/msg
[0]: _modprobe gpg
[0]: _modprobe remdev
[0]: test -n pwd
[1]: getkey pwd swap
[0]: which lvm
[0]: bck lvm
[5]: lvchange -ay vg/swap
[0]: which cryptsetup
[0]: bck cryptsetup
[0]: _blkid sda2 _dev
[0]: cryptsetup isLuks /dev/sda2
[0]: test -b /dev/sda2
[1]: test -b /dev/mapper/sda2_crypt
[1]: dmopen sda2_crypt-sda2
[5]: vgchange -ay vg
[5]: vgchange -an vg
[4]: cryptsetup luksClose sda2_crypt
[4]: cryptsetup remove sda2_crypt
[4]: dmclose sda2_crypt-sda2 vg-swap
[1]: umount -f -l /mnt/tok
[1]: cmd exit

By ls -alh you mean, when the system is booted up, don't you? So here's the output:

# ls -alh /dev/mapper/
total 0
drwxr-xr-x  2 root root      120  9. Jul 22:09 .
drwxr-xr-x 15 root root     4,0K  9. Jul 22:09 ..
crw-------  1 root root  10, 236 10. Jul 2012  control
brw-------  1 root root 254,   0  9. Jul 22:09 sda2_crypt
brw-------  1 root root 254,   2  9. Jul 22:09 vg-root
brw-------  1 root root 254,   1  9. Jul 22:09 vg-swap

Christian Ulrich · Answer 10 · Tue Jul 10 2012 04:31:15 GMT+0800 (China Standard Time)

The parser cuts out some lines. I put the init.log into pastebin:
http://pastebin.com/yFsyTCKB

tokiclover · Answer 11 · Tue Jul 10 2012 04:44:04 GMT+0800 (China Standard Time)

should be fixed with the last fix, thanks for reporting. that was an easy fix... it has only to be encountered to be able to fix it.

Christian Ulrich · Answer 12 · Tue Jul 10 2012 05:28:50 GMT+0800 (China Standard Time)

Great, I got it working!
When I boot using the image which is built by mkinitramfs-ll I still get a kernel panic but when I build it manually using find/gpio/gzip as described in my first post, it works. I still get the message

volume group "vg" not found

but after that i get the passphrase prompt.
So thank you very much, I'm looking forward to new versions from you.

tokiclover · Answer 13 · Tue Jul 10 2012 05:34:34 GMT+0800 (China Standard Time)

At which point do you get a kernel panic?

tokiclover · Answer 14 · Tue Jul 10 2012 05:36:37 GMT+0800 (China Standard Time)

that message error is important as it's just a message from lvchange when trying to activate an lv when the volume group is not available. that error is there as expected.

tokiclover · Answer 15 · Tue Jul 10 2012 05:38:04 GMT+0800 (China Standard Time)

mkinitramfs-ll.$SHELL should built an init ramfs just like you're doing with the extra files copied from usr and extra files depending on /etc/mkinitramfs-ll.conf.

Christian Ulrich · Answer 16 · Tue Jul 10 2012 05:47:06 GMT+0800 (China Standard Time)

I haven't copied anything to usr (except for bin/gpg and share/gnupgconf-skel but I think they're not used) and in mkinitramfs-ll.conf I only added my keymap. It's hard to say at which point the panic occurs because a bunch of addresses is being written to the screen with

Code: Bad RIP value.

and

Kernel panic - not syncing: Attempted to kill init!

somewhere in between

tokiclover · Answer 17 · Tue Jul 10 2012 06:56:47 GMT+0800 (China Standard Time)

there's something peculiar when generating an initramfs in /usr/local/share/mkinitramfs-ll or in $DISTDIR/git-src/mkinitramfs-ll. I've just runned this `diff -u <(./xcpio -l /boot/initramfs-3.4.3-git.cpio.xz) <(./xcpio -l /mnt/tok/initramfs-3.4.3-git.cpio.xz)' to compare the contents of two generated initramfs-ll and it's a bit odd.

you could post something similar for your kernel, i'm going to see what i can do to fix it.

tokiclover · Answer 18 · Tue Jul 10 2012 06:58:13 GMT+0800 (China Standard Time)

or else, try cloning directly my tree and build everything there: git clone git://github.com/tokiclover/mkinitramfs-ll.git $DISTDIR/git-src/mkinitramfs-ll

tokiclover · Answer 19 · Tue Jul 10 2012 07:18:37 GMT+0800 (China Standard Time)

found the issue: /etc/mkinitramfs-ll.conf is not sourced so many things miss to the initramfs. trying to fix it...

Christian Ulrich · Answer 20 · Tue Jul 10 2012 07:48:58 GMT+0800 (China Standard Time)

good to hear you found it. I cloned your tree, built the image with mkinitramfs-ll.bash and "manually" and this is what diff said:
http://pastebin.com/zHTufwhF

Christian Ulrich · Answer 21 · Tue Jul 10 2012 08:00:52 GMT+0800 (China Standard Time)

"unsupported compression format"
ok, this was not very helpful :-D

Christian Ulrich · Answer 22 · Tue Jul 10 2012 08:06:11 GMT+0800 (China Standard Time)

when I consider the compression format, diff finds no difference:
http://pastebin.com/vSHEtb6D

tokiclover · Answer 23 · Tue Jul 10 2012 08:43:44 GMT+0800 (China Standard Time)

that's where puting a proper *.cpio.$compression is handy... anyway, closing the issue, the previous fix should be the last one: /etc/mkinitramfs-ll.conf wasn't sourced anywhere whatsover... despite getting a proper install when running `make DESTDIR=/tmp install_{ba,z}sh' in my local tree.

tokiclover · Answer 24 · Tue Jul 10 2012 08:51:57 GMT+0800 (China Standard Time)

and thanks for the help debuging those silly/tiny issues.

Christian Ulrich · Answer 25 · Tue Jul 10 2012 09:42:21 GMT+0800 (China Standard Time)

I'm very sorry, but I still get the kernel panic. And when I build the image manually now and boot it drops me into a rescue shell saying

ikswap=:: device field empty

I tried to set ikswap=pwd as you said earlier but no change. I'm going to bed now and if you live somewhere in Europe I'd recommend you to do the same. Good night.

Christian Ulrich · Answer 26 · Tue Jul 10 2012 20:16:36 GMT+0800 (China Standard Time)

Here's the init.log in case I boot from the self-built initramfs:
http://pastebin.com/1WjNFzNe

tokiclover · Answer 27 · Tue Jul 10 2012 20:56:39 GMT+0800 (China Standard Time)

That init.log is not complet. I see that the latest (0.10.1) is not stable with pwd key mode, it just fails to try to decrypt the cyphertext. Just checkout 0.10.0 which works just fine for now: `git checkout 0.10.0' in your local tree or use sys-kernel/mkinitramfs-ll-0.10.0 ebuild. I've just test init-à.10.0 and it works just fine with the previous fix (6c98ef9). Keeping this issue closed as it's a new issue that should be fixed.

tokiclover · Answer 28 · Tue Jul 10 2012 22:41:31 GMT+0800 (China Standard Time)

Just rm-ed preivous initramfs image and build another one and it works as expected with pwd mode with or without `ikroot=pwd'; there's no reason it woudn't work with ikresume or ikswap.