Initramfs with root partition using lvm and luks encryption fails to boot as its looking for a nonexistent kernel module #47

Lunarequest · 2021-03-09T17:23:35Z

I'm trying to install arch linux using luks with lvm and booster for the initramfs. On boot I get the following error /usr/lib/modules/5.11.4-arch1-1/luks.ko I've had similar errors with both the lts and zen kernels as well.

Any idea why I get these errors and how to fix them?

The text was updated successfully, but these errors were encountered:

anatol · 2021-03-09T17:37:24Z

There is no such module as luks.ko.

What is config file you use?

Lunarequest · 2021-03-09T17:51:28Z

universal: false
strip: true
compression: zstd

anatol · 2021-03-09T17:53:58Z

It is really weird then. Please post the full output of booster -debug. Also add booster.debug=1 to the boot parameter and share the boot output with me (e.g. using a photo camera).

anatol · 2021-03-09T17:54:34Z

Also post your lsmod.

Lunarequest · 2021-03-09T18:15:33Z

attached is the output of booster.debug=1, I've used a tar since github complained about the size of the mp4. I'll add the other stuff tomorrow morning since its pretty late for me and I can't figure out a way to upload the other stuff
booster-boot-debug-output.tar.gz

anatol · 2021-03-09T18:25:49Z

I see it now. It looks like you specified luks' UUID as a root. And it is wrong. You should specify UUID of a filesystem that sits on top of LUKS partition. That top filetype should be have type like ext4, btrfs, ...

TODO: booster should provide a more helpful and actionable error message for such situation.

Lunarequest · 2021-03-10T01:16:40Z

What's the variable I should use to pass through the fstype?

anatol · 2021-03-10T01:20:11Z

What's the variable I should use to pass through the fstype?

Per man booster:

rootfstype=$TYPE (e.g. rootfstype=ext4). By default booster tries to detect the root filesystem type.

But booster will detect filesystem type automatically.

In your case the problem that you specified wrong root= boot parameter.

Lunarequest · 2021-03-10T02:08:06Z

So root=/dev/mapper/device right?

anatol · 2021-03-10T05:19:49Z

So root=/dev/mapper/device right?

I do not know. It depends on your configuration.

Post your lsblk and the boot parameters.

Issue #47

Lunarequest · 2021-03-11T08:49:19Z

sorry I took so long to send these but I had some irl stuff
lsblk

blkid

boot options

anatol · 2021-03-11T17:08:34Z

In your bootloader config:

you don't need cryptdevice parameter
instead of rd.luks.uuid you need to use rd.luks.name=$UUID=cryptroot this will open a partition with this $UUID as /dev/mapper/cryptroot
the partition where the LUKS resides is /dev/sda2 and its UUID is ead379...... It means the luks parameter will be rd.luks.name=ead37914-21<....>=cryptroot.
you don't need rootfstype parameter, booster will it figure out automatically.

Lunarequest · 2021-03-11T17:24:47Z

I do get a password prompt now but on entering the correct password I get

Lunarequest · 2021-03-11T17:29:24Z

Wait it kernel panicked

anatol · 2021-03-11T17:36:44Z

The kernel panic is expected and the result of the timeout.

The real culprit is "Error allocating crypto tfm" that I am not sure where it comes from. Try to add debug to the boot parameters. It might provide more information about what is going on.

anatol · 2021-03-11T17:46:29Z

The problem might be due to some extra cryptographic modules are missing in initramfs.

As a workaround for it you can try to add universal: true to your config file and regenerate the images.

anatol · 2021-03-11T17:52:12Z

And also show me the output of sudo cryptsetup luksDump /dev/sda2 | grep -i ciph that will give more information about what cipher do you use for your LUKS device.

Lunarequest · 2021-03-11T18:12:29Z

anatol · 2021-03-11T18:23:21Z

The ciphers look fine (these are default versions) and it should work.

Anyway try to use universal: true images.

Lunarequest · 2021-03-11T18:26:08Z

Tried that didn't do anything different here is the output with booster.debug=1

anatol · 2021-03-11T18:34:56Z

It is still the same "error allocating crypt tfm" problem. Try also adding debug boot parameter for more logs from the kernel itself.

Also post your cat /proc/crypto.

Lunarequest · 2021-03-12T04:21:12Z

out put of cat /proc/crypto https://pastebin.com/mPeqtivH

anatol · 2021-03-12T04:36:09Z

Thanks for sharing it. All modules used by your crypto subsystem are part of the universal booster image. I do not see how your booster unable to initialize crypto.

Lunarequest · 2021-03-12T04:37:33Z

shall I try reinstalling?

anatol · 2021-03-12T04:39:40Z

Try with the default config file (i.e. empty /etc/booster.yaml) and install booster-git from AUR.

anatol · 2021-10-12T15:57:48Z

Booster 0.7 added numerous fixes for LUKS and LVM. Could you please try 0.7 and see if you still have the issue.

Lunarequest · 2021-10-12T16:03:01Z

I'm no longer on archlinux and actually on fedora Kinonite so I can no longer test/reproduce this issue.

If a user specifies non-standard encryption like xts-camellia then booster fails to use it, and fails with error: [ 8.853839] device-mapper: table: 254:0: crypt: Error allocating crypto tfm (-ENOENT) [ 8.854683] device-mapper: ioctl: error adding target to table [ 8.871073] booster: dm ioctl (cmd=0xc138fd09): no such file or directory To fix it we need mimic kernel's codepath for this case. If modules for encryption mode/block cipher are not used then it asks userspace to load it with `modprobe crypto-$MODE`, when crypto-$MODE is an alias that points to other modules. To fix the issue we load the required `crypto-*` alias before setting up a device mapper for dmcrypto. As a result of this change 'modules' and 'modules_force_load' handles aliases as well. So user can add `modules: cryto-camellia` to their config. Add an integration test for loadable crypto module. Fixes #188 Fixes #47

If a user specifies non-standard encryption like xts-camellia then booster fails to use it. The error message is [ 8.853839] device-mapper: table: 254:0: crypt: Error allocating crypto tfm (-ENOENT) [ 8.854683] device-mapper: ioctl: error adding target to table [ 8.871073] booster: dm ioctl (cmd=0xc138fd09): no such file or directory To fix it we need to mimic kernel's codepath for this case. What kernel does in case of loadable crypto modules are not loaded - it asks userspace to load the module with `modprobe crypto-$MODE`. `crypto-$MODE` is an alias that points to other modules. To fix the original issue we load the required `crypto-*` alias before setting up a device mapper for dm-crypt. As a result of this change 'modules' and 'modules_force_load' now handle aliases as well. So user can add `modules: cryto-camellia` to their config. Add an integration test for loadable crypto module. Fixes #188 Fixes #47

anatol added a commit that referenced this issue Mar 10, 2021

Warn user if it tries to mount non filesystem block device

c83c9f0

Issue #47

Lunarequest closed this as completed Oct 12, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initramfs with root partition using lvm and luks encryption fails to boot as its looking for a nonexistent kernel module #47

Initramfs with root partition using lvm and luks encryption fails to boot as its looking for a nonexistent kernel module #47

Lunarequest commented Mar 9, 2021

anatol commented Mar 9, 2021

Lunarequest commented Mar 9, 2021

anatol commented Mar 9, 2021

anatol commented Mar 9, 2021

Lunarequest commented Mar 9, 2021

anatol commented Mar 9, 2021

Lunarequest commented Mar 10, 2021

anatol commented Mar 10, 2021 •

edited

Loading

Lunarequest commented Mar 10, 2021

anatol commented Mar 10, 2021

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021 •

edited

Loading

Lunarequest commented Mar 11, 2021

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021 •

edited

Loading

anatol commented Mar 11, 2021 •

edited

Loading

anatol commented Mar 11, 2021 •

edited

Loading

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021

Lunarequest commented Mar 12, 2021

anatol commented Mar 12, 2021

Lunarequest commented Mar 12, 2021

anatol commented Mar 12, 2021

anatol commented Oct 12, 2021

Lunarequest commented Oct 12, 2021

Initramfs with root partition using lvm and luks encryption fails to boot as its looking for a nonexistent kernel module #47

Initramfs with root partition using lvm and luks encryption fails to boot as its looking for a nonexistent kernel module #47

Comments

Lunarequest commented Mar 9, 2021

anatol commented Mar 9, 2021

Lunarequest commented Mar 9, 2021

anatol commented Mar 9, 2021

anatol commented Mar 9, 2021

Lunarequest commented Mar 9, 2021

anatol commented Mar 9, 2021

Lunarequest commented Mar 10, 2021

anatol commented Mar 10, 2021 • edited Loading

Lunarequest commented Mar 10, 2021

anatol commented Mar 10, 2021

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021 • edited Loading

Lunarequest commented Mar 11, 2021

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021 • edited Loading

anatol commented Mar 11, 2021 • edited Loading

anatol commented Mar 11, 2021 • edited Loading

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021

Lunarequest commented Mar 11, 2021

anatol commented Mar 11, 2021

Lunarequest commented Mar 12, 2021

anatol commented Mar 12, 2021

Lunarequest commented Mar 12, 2021

anatol commented Mar 12, 2021

anatol commented Oct 12, 2021

Lunarequest commented Oct 12, 2021

anatol commented Mar 10, 2021 •

edited

Loading

anatol commented Mar 11, 2021 •

edited

Loading

anatol commented Mar 11, 2021 •

edited

Loading

anatol commented Mar 11, 2021 •

edited

Loading

anatol commented Mar 11, 2021 •

edited

Loading