the case of the failing boot after upgrade fedora 32 post

After upgrading one of my machines to Fedora 32 the initramfs image did fail with:

device-mapper: table: 253:0: crypt: Error allocating crypto tfm

Searching for the string "Error allocating crypto tfm" in the linux kernel source code reveals that the message is created at those places:

(using cscope):

Text string: Error allocating crypto tfm

  File       Line
0 dm-crypt.c 2747 ti->error = "Error allocating crypto tfm";
1 dm-crypt.c 2832 ti->error = "Error allocating crypto tfm";

both errors occurs after calling "crypt_alloc_tfms" which calls either "crypt_alloc_tfms_aead" or "crypt_alloc_tfms_skcipher".

Let's follow skcipher as this handles the block chiphers: This function calls "crypto_alloc_skcipher" which calls "crypto_alloc_tfm" which calls "crypto_alloc_tfm_node" which calls "crypto_find_alg" which calls "crypto_alg_mod_lookup" which calls "crypto_larval_lookup" which ends up calling "__request_module".

Here it's get interessting, because we have a trace point:

    trace_module_request(module_name, wait, _RET_IP_);

the trace point is available under debugfs: # cat /sys/kernel/debug/tracing/available_events | grep module_request module:module_request

So all we need to do to find out what kernel module for crypto is missing in the initramfs is: - mount the debugs - enable the module_request trace point - retry to setup luks to trigger the error path - check which module was request and did fail in the trace log

here is how to do it: 1.) mount debugfs # mount -t debugs none /sys/kernel/debug

2.) enable module_request trace point # echo 1 > /sys/kernel/debug/tracing/events/module/module_request/enable

3.) retrigger error # lukssetup ??

4.) check trace log # cat /sys/kernel/debug/tracing/trace

now add the missing module to your initramfs!