Control: severity -1 wishlist Control: tag -1 moreinfo Hi Raphaël,
On Fri, 07 Sep 2018 at 15:41:26 +0200, Raphaël Hertzog wrote: > However that no longer works... when the live image is created, there's > no encrypted device detected and you see that in the build log: > > update-initramfs: Generating /boot/initrd.img-4.17.0-kali3-amd64 > cryptsetup: WARNING: Couldn't determine root device > cryptsetup: ERROR: Couldn't resolve device /dev/sdb4 > cryptsetup: WARNING: The initramfs image may not contain cryptsetup > binaries > nor crypto modules. If that's on purpose, you may want to uninstall the > 'cryptsetup-initramfs' package in order to disable the cryptsetup > initramfs > integration and avoid this warning. Do you have the proc(5) and sysfs(5) pseudo-filesystems respectively mounted to /proc and /sys? The “WARNING: Couldn't determine root device” suggests it's either not the case, or that the file system holding / is not backed up by a block device (eg, ZFS). Can you share what /proc/mounts contains before you type `update-initramfs -u`? > The only way that I found to force the inclusion of cryptsetup is by > setting CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook. But when you do > that > you get another worrying warning: > > cryptsetup: WARNING: Honoring CRYPTSETUP=[y|n] will deprecated in the > future. > Please uninstall the 'cryptsetup-initramfs' package if you don't want > the > cryptsetup initramfs integration. > > So what's the proper way to tell cryptsetup to put its files in the > initramfs, no matter what it detects, without generating a warning? How do you unlock that disk at initramfs stage? Using a custom boot script, or by typing a `cryptsetup open --type=luks` command manually? Or do you rely on our own (‘cryptroot’) initramfs boot script? Adding the cryptsetup binaries to the initramfs image might not be sufficient, especially if the initramfs image isn't compiled with MODULES="most". That's why we warn the user that modules might me missing if auto detection fails to determine which device(s) need to be unlocked at initramfs stage and/or which modules are required to map the crypt devices. Failure to unlock the root device is arguably worse than false positives. > Users very much dislike all those warnings and they report them to us > in Kali... so there must be a way to not get a warning. I would be > more than happy if installing cryptsetup-initramfs was sufficient. If > the user doesn't want it in the initramfs, he just removes the > package. Before the package split (cf. #783297 and #813220) users could add CRYPTSETUP=n to disable initramfs integration. As the warning suggests we're deprecating this; we'll remove the warning once buster is released, instead installing cryptsetup-initramfs will silently trigger execution of our initramfs hook scripts. But for said hook scripts to work reliably, the device needs to present and mapped (unlocked) when the initramfs image is built. Otherwise, as I wrote above, the hook doesn't know which crypto modules need to be present in the image. Moreover, the device needs to have an entry in the crypttab(5) to pass suitable options (--type, --header, etc.) to `cryptsetup open`. In order to force a device to be considered at initramfs stage, you can add the ‘initramfs’ to its crypttab(5) entry. Cheers, -- Guilhem.
signature.asc
Description: PGP signature