On 05/07/2018 00:24, Alex Gould wrote:
Hi, I'm hoping for some advice for a problem with my system that is tracking
Debian Testing.
The system has two equally-sized internal hard drives. They are partitioned in
the following way:
Disk A has a smaller ext2 partition that serves as /boot, with the remainder
being a physical volume for LVM
Disk B has one partition, a physical volume for LVM.
The two physical volumes are combined via LVM into one logical volume.
This logical volume is encrypted with cryptsetup using a passphrase (to be
entered at boot).
The resulting encrypted volume is then used as a physical volume for LVM, which
is divided into two logical volumes: swap and / (root).
This setup was all created via the Debian installer.
Until now, everything seemed to work flawlessly -- Grub loaded the initramfs, I
was prompted for the password for the encrypted volume, and then booting
proceeded normally to a usable system.
After upgrading to the latest kernel 4.16.0-2-amd64, this no longer worked. Grub loaded,
and I got the error message "Cryptsetup: waiting for encrypted source device
UUID=365b88eb-195f-43a8-8776-8969ed47744c..." followed a few minutes later by
dropping into the initramfs shell.
Boot still works normally if I select the previous kernel, 4.16.0-1-amd64 from
the Grub menu.
I imagine I will need to fix some settings for initramfs, grub, crypttab,
fstab, or something, but I'm not sure how to proceed.
Any advice on this complicated question is greatly appreciated. Thank you!
Hi, I had the same problem on several systems running Sid (unstable), so
it may or may not apply to your case. In my cases I had problems with
systems using a root partition on Luks and also on luks+lvm. When
rebuilding the initramfs I was getting errors (from "update-initramfs")
about the creation of a temporary file. Removing the "cryptroot" and
also on lvm systems the "lvm2" scripts from /etc/initramfs-tools/hooks/
and rebuilding initramfs solved the problem.
Before that I tried various versions of UUID/addressing of partitions in
/etc/crypttab and fstab with no results, tried going through all the
scripts in /etc/initramfs-tools/scripts (and copy fresh ones from
/usr/share/initramfs-tools/), but all this in pure waste of time.
Removing the hook scripts did the trick.
Seems like initramfs luks support is going though a transition, I have
been getting messages about the option "cryptsetup=y" in
"initramfs-tools" being deprecated for a while now, so was expecting
something like this.
Hope it helps. Keep a recovery system from which to boot and chroot
close-by...
