1

I have LVM on the top cryptsetup on my Debian unstable amd64. A week ago after upgrade my initramfs changed and now I have to wait few minutes at the beginning of the boot before cryptsetup asked for password to unlock partition. There might be some problem with generated images as at the beginning there were just some kernels affected. After proper run of update-initramfs -u -k all installed kernels are affected.

Wiki instructions don't help much, as debug kernel option takes too long and nothing happen (booting just stops). I tried to debug it with single break=mount kernel options, but nothing found.

I see that in initramfs there is running script /scripts/init-premount, which starts dropbear (nothing unusual).

I have no idea what changed. Any idea, how I can debug problem? Any module missing?

My config:

-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.3.0-rc5-amd64 root=/dev/mapper/t61-root ro

-- /etc/crypttab
sda2_crypt UUID=c524108a-b40f-49b4-8223-23e3441a7409 none luks

-- /etc/crypttab
sda2_crypt UUID=c524108a-b40f-49b4-8223-23e3441a7409 none luks

-- /etc/fstab
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/t61-root /          ext4    relatime,errors=remount-ro 0       1    
UUID=411fe373-ec79-45f7-90f2-e50be400c71d /boot   ext4    defaults  0     2    
tmpfs     /tmp tmpfs     nodev,nosuid,size=512M,mode=1777    0    0    
/dev/mapper/t61-home /home      ext4    defaults,relatime        0       2    
/dev/mapper/t61-swap none       swap    sw              0       0

-- /etc/initramfs-tools/modules
dm-crypt
aes-x86_64
xts
sha256_generic
sha512_generic
  • 1
    I've had a similar problem under Ubuntu after moving partitions around, where the initramfs contained two ways to run cryptsetup and only one of them worked (the other had input redirected to /dev/null IIRC). Normally the working one ran but in my case it was disabled. The solution was to fix some configuration file (/etc/crypttab?) and regenerate the initramfs. Unfortunately I don't remember the details. I suggest tracing through what the scripts in the initramfs are doing (add set -x to some files under /usr/share/initramfs-tools. If you figure it out, please let us know! – Gilles Oct 26 '15 at 21:36
  • @Gilles: good point for set -x. I've tried to localize problem with regenerated initramfs with inserted debugging messages, but this is going to be much more effective, thanks :-). – pevik Oct 27 '15 at 8:45
0

My problem was in unconfigured network, which was required by dropbear.

The actual problem with network was my ISP's dhcp server, which is alive, but not providing network setting for me, so I have to set network manually. In initramfs I had to wait for all tries of dhcp. It was in function configure_networking() in /scripts/functions (source file for mkinitramfs in running system is /usr/share/initramfs-tools/scripts/functions).

Although dropbear is a great solution for servers as my system is laptop, I don't need it. I didn't even bother with configuring it or disabling it (in /etc/initramfs-tools/conf-hooks.d/dropbear), I just simply removed dropbear for initramfs-tools:

apt-get remove dropbear-initramfs

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.