Home | News | Download | Packages | Forum | Wiki | Github

[SOLVED] Neither dracut nor mkinitcpio working with encrypted root and syslinux


#1

Hello all, newly arrived Arch escapee here.

I am trying to install Void with musl on an encrypted root, using an lvm group inside a luks container. I think I’m having the same issue as this guy. I set it up according to these two different wiki pages and set up syslinux as described on the Arch wiki.

Syslinux appears to boot fine. I’m using the following config:

PROMPT 1
TIMEOUT 50
DEFAULT void

LABEL void
        LINUX ../../vmlinuz-4.4.19_1
        APPEND cryptdevice=UUID="th3-uu1d-h3re":lvm root=/dev/mapper/base-void resume=/dev/mapper/base-swap add_efi_memmap rw
        INITRD ../../initramfs-4.4.19_1.img

At first I tried with dracut generated initramfs, which failed and gave a kernel panic without much useful info. Then I tried with mkinitcpio, and added the hooks encrypt lvm2 resume (in that order) between block and filesystems in /etc/mkinitcpio.conf. When running mkinitcpio, it gives the error “Hook ‘udev’ cannot be found”, which I assume is because Void uses a non-systemd version of udev.

When booting the mkinitcpio generated initramfs, it seems to go through the hooks in the wrong order. lvm comes before encrypt, for example, making them both useless.

Edit: I tried changing the mkinitcpio hook scripts to make encrypt an “earlyhook” and lvm a regular “hook”, which changed their initialized order, but still won’t boot. Running the usual cryptsetup luksOpen /dev/sda2 base from the initramfs system complains that the device doesn’t exist, which should indicate that I need udev.

How do I add udev to the initramfs generated by mkinitcpio?


#2

I can only say that dracut definitively works, as its the default I only use dracut.
For mkinitcpio I guess you have to install mkinitcpio-udev.


#3

That did it! Thanks a lot!


#4

I tested to see if I could get dracut to work, and I didn’t have to change anything: now it just worked. The output of sudo dracut -f says things about a “stored kernel commandline” containing information about the luks container UUID and the partition mount points.

dracut: *** Store current command line parameters ***
dracut: Stored kernel commandline:
dracut:  rd.luks.uuid=luks-th3-uu1d-h3re
dracut:  rd.lvm.lv=base/swap
 rd.lvm.lv=base/void
dracut:  resume=/dev/mapper/base-swap
dracut:  root=/dev/mapper/base-void rootfstype=ext4 rootflags=rw,relatime,data=ordered
dracut: *** Creating image file '/boot/initramfs-4.4.19_1.img' ***
dracut: *** Creating initramfs image file '/boot/initramfs-4.4.19_1.img' done ***

None of these parameters are written like this in the bootloader config, so am I on the right track suspecting it gets this info from the currently booted system? I.e. the mkinitcpio ramfs booted successfully, and indirectly provided info to the system running dracut. So even though dracut is now independent from mkinitcpio, is it a chicken/egg situation? Was I just lazy for not adding these parameters to dracut before?


#5

After some more sporadic testing, it turns out this isn’t a musl specific issue. I tried installing a glibc system and got the same problem. Adding the command line flags from the previous comment had no effect.