Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Very rare update-initramfs / cryptsetup bug involving missing shell script functions!

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
egonline
Posts: 1
Joined: 2021-12-11 06:40

Very rare update-initramfs / cryptsetup bug involving missing shell script functions!

#1 Post by egonline »

My system failed to reboot the other day. I run the latest x86-64 Debian 10 and have a mdadm soft RAID and luks/dmcrypt for an encrypted root disk environment. After quite a long irritating while identifying that my initramfs did not contain 'cryptsetup', dm luks kernel modules nor a crypttab, and thus could not proceed past identifying mysoft-RAID mdadm and creation of /dev/md0, I launched into a live rescue Linux environment and mounted the encrypted root filesystem, chrooted to it and attempted to rebuild initramfs via 'update-initramfs'. The command failed providing shell script errors indicating that "resolve_device_spec" called from the script "/usr/share/initramfs-tools/hooks/cryptroot" was not found. I do not have the version of the initramfs-tools package installed at that time but whatever it was it would have been provided from Debian as I do not modify these important scripts on my computers. I also do not have the output because I was at a cold hard crash cart in the datacenter.. for hours debugging it.

Four other previous kernels in grub could did not boot for the same reason leading me to believe that this initramfs script 'corruption' happened at some point in the past and I didn't notice it because I did not reboot after the initramfs update. I run ZFS on Linux and other tools that use DKMS and my initramfs is being rebuilt quite often. I say corruption because the scripts are not correct but they're not 'corrupt' in the sense that something abruptly stopped and a script was truncated or byte corrupted; instead the scripts appeared to be fine. They just lacked the function.

A search of "resolve_device_spec" does not yield much but of the four results, a bug report at https://github.com/colis-anr/morbig/issues/57 contained a 'resolve_device_spec' function (contained in the file "/usr/lib/cryptsetup/functions" which is contained in both packages 'cryptsetup' and 'cryptsetup-run'). I typed this function manually into my local terminal with a much beat up crash cart keyboard and inserted it into /usr/share/initramfs-tools/hooks/cryptroot, along with a proper entry in /etc/crypttab that I guessed at using the encrypted volume name ("md0_raid UUID=...the-uuid... none luks,discard") allowed update-initramfs to successfully complete - albeit with another function not found:

/scripts/local-top/cryptroot: line 126: get_crypt_type: not found

However this was not critical for my system to successfully rebuild the initram so I did not worry about it. My system booted fine.

I do not know what would cause these files and functions to not be embedded into the initramfs during the rebuild process nor why the initram would be over-written with a version that failed to successfully build. I feel that I may have, at some point in the 200+ days of uptime prior to my failing reboots, maybe forced a dpkg-reconfigure or apt-get install and this led the borked situation described but I cannot be sure.

Any ideas? Anyone know more about this process? Regardless I wanted to document this here so that anyone else with this problem will hopefully find this solution.


Regards,

Brandon

Post Reply