Fatal Error – Encryption kernel module dm-crypt not found

[Member olsztyn]

I am experiencing fatal error on boot after making the following changes, it appears resulting switching kernel from 4.9 to 4.19:
– On encrypted Live installed kernel 4.19 and switched to it
– Activated ufw
– Remastered Live
– Executed Live USB Maker to create a copy to another usb with checked ‘from running system’ and encrypted
– Live USB creator completed without errors
– Booting such created copy results in boot failure at the point when setting an encryption key is expected
Message:
Fatal Error
Required encryption kernel module dm-crypt not found
p – power off
r – reboot
Select p or r and press enter.

It appears the above error results from having switched to kernel 4.19 or Live USB Maker needs an update for this kernel…

Temporary workaround seems to work:
Revert to kernel 4.9 before running Live USB Maker. Resulting Live USB copy boots as expected. Kernel can be updated to 4.19 on Live copy afterwards.

• This topic was modified 3 years, 5 months ago by olsztyn.
• This topic was modified 3 years, 5 months ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Anonymous]

Helpful

Up

0

::

forum search: crpyt
^–v

https://www.antixforum.com/forums/topic/antix-19-install-fail-on-external-hard-drive/
topic: antiX 19 Install Fail On External Hard Drive
date: December 4, 2019
post by: anticapitalista

As the release notes state:

Known Issues:

* sis drivers no longer work (we’ll see if we can get it working for later editions)
* Rox and spacefm desktop RAM usage is higher than expected
* connman does not connect to sdio bluetooth controller (rtl8723bs) on Intel Compute Stick STCK1A8LFC
* The presence of /etc/asound.conf causes repeated second long gaps in HDMI sound
* cli-installer needs to be upgraded before use on full and base. (core and net use the latest versions)
* Creating an encrypted live-USB fails unless an older version of Live_USB Maker is used. The version on antiX-17 does create an encrypted Live_USB of antiX-19
* Although the antiX FAQ has been updated, some parts may need further revision

[Member olsztyn]

Helpful

Up

0

::

Anonymous wrote:

Creating an encrypted live-USB fails unless an older version of Live_USB Maker is used. The version on antiX-17 does create an encrypted Live_USB of antiX-19

If you are referring me to the above then it has no longer been in effect. It was fixed by BitJam some time ago and new version of Live USB Maker published. Updated version has been working correctly.
I think anti was referring to the original release notes.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member olsztyn]

Helpful

Up

0

::

The above encryption issue is probably affecting only users of Live USB who use 4.19 kernel in place of stock 4.9 so it may not attract as much attention. To me, due to portability, Live USB entails a necessity of encryption. The above workaround seems to work fine so there is no urgency for me that a fix would be found soon…

However can someone please explain this mystery to me:
– Dm-crypt kernel module is missing in antiX 4.19 kernel, although it is in 4.9. Not included in antiX version only?
– If the above is indeed the case how is this possible that encrypted Live-USB instance of antiX created with kernel 4.9 seems to run perfectly after kernel is updated to 4.19, if 4.19 is missing dm-crypt kernel module? Is the encryption module of kernel not used during antiX operation for encrypting/decrypting?

I would appreciate if some light can be shed on how this works please…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Anonymous]

Helpful

Up

0

::

Within the /boot/ directory, we should expect to find a “configuration details” file associcated with each kernel file. Examining its content can be enlightening (or, depending on one’s point of view, can be overwhelming). The following, instead, may suffice for gleaning particular details of interest. Shown in a code box here, but do not copypaste ~~ you must supply an actual (on your system) filename

sudo cat /boot/config-{{{{ACTUAL_KERNEL_VERSION_N_NAME}}}} | grep CRYPT
--- OR ---
sudo cat /boot/config-{{{{ACTUAL_KERNEL_VERSION_N_NAME}}}} | grep CRYPT | grep ext4

=y
indicates that a given module was compiled into the kernel at build time
=m
indicates that the configuration declare that a give module can, optionally, be loaded during runtime
=n
indicates that the kernel has been configured without support for a given module

Some of the y/n lines within the configuration file are toggles, declaring whether certain features are enabled.

Wait for others to anwser.
I don’t know whether the problem you’ve described is due to “kernelXYZ is unable to support ext4 encryption” or “yes, kernelXYZ was configured with encryption support enabled, but it expects moduleABC (=m) to be optionally loaded at runtime (during boot, or on-demand) but moduleABC is absent on the system” or…

[Anonymous]

Helpful

Up

0

::

Within the /boot/ directory, we should expect to find a “configuration details” file associcated with each kernel file. Examining its content can be enlightening (or, depending on one’s point of view, can be overwhelming). The following, instead, may suffice for gleaning particular details of interest. Shown in a code box here, but do not copypaste ~~ you must supply an actual (on your system) filename

sudo cat /boot/config-{{{{ACTUAL_KERNEL_VERSION_N_NAME}}}} | grep CRYPT
--- OR ---
sudo cat /boot/config-{{{{ACTUAL_KERNEL_VERSION_N_NAME}}}} | grep CRYPT | grep ext4

=y
indicates that a given module was compiled into the kernel at build time
=m
indicates that the configuration declare that a give module can, optionally, be loaded during runtime
=n
indicates that the kernel has been configured without support for a given module

Some of the y/n lines within the configuration file are toggles, declaring whether certain features are enabled.

Wait for others to anwser.
I don’t know whether the problem you’ve described is due to “kernelXYZ is unable to support ext4 encryption” or “yes, kernelXYZ was configured with encryption support enabled, but it expects moduleABC (=m) to be optionally loaded at runtime (during boot, or on-demand) but moduleABC is absent on the system” or…

_____________________________

If a system has 2 alternative kernels present, and I want to compare side–by-side, check differences, in their configuration:

diff /boot/config-kname1 /boot/config-kname2
--- OR ---
(sudo apt install meld, then) meld /boot/config-kname1 /boot/config-kname2

IIRC, we cannot easily find needles in the haystack of 1000+ line files, so

cat /boot/config-kname1 | sort -u > /tmp/config-kname1.txt
cat /boot/config-kname2 | sort -u > /tmp/config-kname2.txt
--- THEN ---
meld /tmp/config-kname1.txt /tmp/config-kname2.txt

[Member olsztyn]

Helpful

Up

0

::

Thanks skidoo for this insight how to determine whether particular kernel modules are statically compiled or dynamically invoked during execution. I will try to grep kernel distribution to determine which way is dm-crypt.
However this would not remove the mystery for me that using the same kernel 4.19, such (possibly dynamically invoked) function would Fatal Error failed during startup but works fine after kernel is updated after booting (booting with kernel 4.9)…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin BitJam]

Helpful

Up

0

::

olsztyn wrote:

I am experiencing fatal error on boot after making the following changes, it appears resulting switching kernel from 4.9 to 4.19:
– On encrypted Live installed kernel 4.19 and switched to it
– Activated ufw
– Remastered Live
– Executed Live USB Maker to create a copy to another usb with checked ‘from running system’ and encrypted
– Live USB creator completed without errors
– Booting such created copy results in boot failure at the point when setting an encryption key is expected

I think this is a bug in LUM, triggered by the combination of things you did (but not your fault). The problem is that on encrypted live-usbs the actual kernel and initrd files are on a different partition. Apparently live-kernel-updater handles this correctly but clone mode in LUM does not.

If you are willing, you could try to fix this manually, assuming it is easy for you to replicate the original problem. Let’s say the encrypted live-usb you are starting from is sdb and the target live-usb is at sdc.

After running LUM in clone mode, mount /dev/sdb1 and /dev/sdc1. They should both have an /antiX/ directory that contains vmlinux and initrd.gz files. Copy these two files from sdb1 to sdc1. I think this will fix the problem and it will verify I’m on the right track to fixing it in the code. If this is not convenient for you, that’s fine. I will go ahead and try to fix the code anyway.

Context is worth 80 IQ points -- Alan Kay

[Member olsztyn]

Helpful

Up

0

::

BitJam wrote:

After running LUM in clone mode, mount /dev/sdb1 and /dev/sdc1. They should both have an /antiX/ directory that contains vmlinux and initrd.gz files. Copy these two files from sdb1 to sdc1. I think this will fix the problem and it will verify I’m on the right track to fixing it in the code.

I was attempting to do it but for some reason mounting sdb1 as root was with error (exit status 127).
After booting still another partition did not help much to copy these two files from sdb1 to sdc1. Copy fails too.
I am trying to overcome this unexpected difficulty…

Update:
I was able to copy these two files from sdb1 to sdc1 after booting another antiX partition.
I looks like after copying the resulting target clone boots as expected, setting up encryption passphrase instead of Fatal Error and proceeds to desktop as expected.
So looks like your conjecture of the cause of this problem is correct.
Just to mention though: This was done on ‘runit’ verssion of antiX, just published by anti, but this should not make any difference as far as the issue is concerned…
Thanks BitJam again for such quick response to these bugs…

• This reply was modified 3 years, 5 months ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin BitJam]

Helpful

Up

0

::

Edit: oops! I didn’t see that you already resolved the problem. Kudos! Thanks again for you help. You can ignore what’s below.

olsztyn wrote:

I was attempting to do it but for some reason mounting sdb1 as root was with error (exit status 127).
After booting still another partition did not help much to copy these two files from sdb1 to sdc1. Copy fails too.
I am trying to overcome this unexpected difficulty…

Thanks for helping!

The 127 exist status is most likely from bash saying the (or a) command was not found.

Another approach would be to use the “–pause” option when running live-kernel-updater. Since this seems to work on your encrypted system, it must be updating the kernel and initrd on the boot partition. With the “–pause” option the LKU process waits until you press . In another terminal or terminal window copy vmlinuz and initrd.gz from the boot partition to the main partition:
sudo cp /run/live-kernel-updater/bios/antiX/{vmlinuz,initrd}* /live/boot-dev/antiX/
On an encrypted live-usb these files are not normally used on the main partition but they are what is copied when you make a clone. I might try this for the fix since it’s a little simpler (although a little Rube-Goldberg).

The basic problem is LUM is cloning those files from the main partition when it should be cloning them from the boot partition. Since they didn’t get updated on the main partition when you ran LKU, you get the missing module error for the new kernel.

Context is worth 80 IQ points -- Alan Kay

[Member olsztyn]

Helpful

Up

0

::

BitJam wrote:

Edit: oops! I didn’t see that you already resolved the problem. Kudos! Thanks again for you help. You can ignore what’s below.

BitJam:
I wish I have resolved the problem… I just followed your instructions in order to test if your solution would work.
This test just proved that. So thanks again. Looking forward to the ultimate fix…
Just to mention again though: This test I performed on the ‘Runit’ version of antiX just published by anti, as I had Live encrypted instances at hand at the moment being in the course of testing ‘runit’ version. But this should not make any difference for Live cloning though and the same issue exists for ‘Runit’ version…

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member olsztyn]

Helpful

Up

0

::

BitJam wrote:

On an encrypted live-usb these files are not normally used on the main partition but they are what is copied when you make a clone. I might try this for the fix since it’s a little simpler (although a little Rube-Goldberg).

The basic problem is LUM is cloning those files from the main partition when it should be cloning them from the boot partition. Since they didn’t get updated on the main partition when you ran LKU, you get the missing module error for the new kernel.

Regarding the above, The cloning process is actually run after rebooting Live instance after kernel upgrade, so should it not be updated on the main partition?

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Forum Admin BitJam]

Helpful

Up

0

::

olsztyn wrote:

Regarding the above, The cloning process is actually run after rebooting Live instance after kernel upgrade, so should it not be updated on the main partition?

Sorry, the pronouns trip me up. An encrypted live-usb (elive-usb) needs the kernel (vmlinuz) and the initrd.gz to be on an unencrypted partition (at least for now). I call this the boot partition. Live-kernel-updater correctly updates the kernel and the initrd on the boot partition and does not touch vmlinuz or initrd.gz on the main partition (IIRC unused copies exist there as well). When you then clone the elive-usb, LUM incorrectly copies over vlminuz and initrd.gz from the main partition.

If you set an early breakpoint (“bp=3”) on the broken clone and look under /lib/modules/, you will only see a directory for the original kernel, not the new one. Also the dm-crypt.ko module won’t be there. In fact, if you you run “uname -r”you will see that the old kernel is being used on the broken clone. I now see that having these “unused” copies of vmlinuz and initrd.gz on the main partition of an elive-usb was a mistake. I don’t think you can clone an elive-usb to an elive-usb even without changing the kernel. I think I may have left those copies so you could make an unencrypted clone but this was false laziness.

Context is worth 80 IQ points -- Alan Kay

[Member olsztyn]

Helpful

Up

0

::

Thanks BitJam for such extensive explanation of this cloning mechanism…

BitJam wrote:

if you you run “uname -r”you will see that the old kernel is being used on the broken clone.

Well, this I can only do on un-encrypted clone since encrypted does not boot to be able to execute ‘uname -r’.

BitJam wrote:

I now see that having these “unused” copies of vmlinuz and initrd.gz on the main partition of an elive-usb was a mistake. I don’t think you can clone an elive-usb to an elive-usb even without changing the kernel.

I may be wrong in understanding the above but are you saying that the reason this cloning process worked (works well with the original 4.9 kernel) was thanks to copies of vmlinuz and initrd.gz saved by you? If so then (even if you consider this methodology ‘false laziness’) I think it is a good methodology under circumstances as this allows this cloning process of Live run to work, at least before you upgrade kernel, which finally breaks it. So with the lack of cleaner approach this seems to work as it is. Please correct me if I misunderstood.

Since encrypted Live USB is a necessity and the capability of cloning Live instance is extremely important, what do you suggest:
– Will you attempt to update LUM to be able to handle the existing cloning deficiency?
– We cannot expect a solution in LUM any time soon and the resort will be to manually copy vmlinuz and initrd.gz from source boot partition to target after cloning. This is kind of pain as seems to require a separate instance of antiX to mount these…
– The workaround I was using, namely cloning under the original antiX (kernel 4.9), which works and upgrade kernel after booting target clone.

In any case I want to thank you for your care to answer and the explanation of this mechanism.
Regards.
–

• This reply was modified 3 years, 5 months ago by olsztyn.

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Member olsztyn]

Helpful

Up

0

::

Somehow my subsequent post disappeared, so trying to re-construct…

BitJam wrote:

In fact, if you you run “uname -r”you will see that the old kernel is being used on the broken clone.

Well, I will see if I can test it on un-encrypted clone as encrypted one does not boot to execute ‘uname’.

BitJam wrote:

I now see that having these “unused” copies of vmlinuz and initrd.gz on the main partition of an elive-usb was a mistake. I don’t think you can clone an elive-usb to an elive-usb even without changing the kernel.

If I understand the mechanism I think this methodology of leaving copies is good under circumstances as it makes this cloning process work (at least under the original antiX 4.9 kernel. So even if you consider this approach a ‘false laziness’ this allows cloning functionality to work.

Considering that encryption is a necessity for Live USB and cloning of running system is extremely important would you suggest the course oaction:
– A update to LUM will be possible
– We cannot expect a solution through LUM and the workaround is what you instructed me to test, namely manually copying vmlinuz and initrd.gz from source boot partition to target boot partition after cloning. This seems a pain since it requires booting a separate instance to be able to do this.
– The original workaround I was using, namely falling back to kernel 4.9, then cloning, then upgrading kernel after booting cloned target.

In any case I want to thank you for your care when you explained this mechanism in such detail…
Regards.
–

Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_Parameters

[Author]

Posts