Control: tag -1 - moreinfo On Fri, 07 Sep 2018 at 23:22:45 +0200, Raphael Hertzog wrote: > On Fri, 07 Sep 2018, Guilhem Moulin wrote: >>> 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`? > > I don't think this is relevant, at this point live-build is just > installing packages in a chroot. The end result is an ISO image... > there's no associated device. It can be copied on a DVD or burnt > on an USB key.
It might be related to #902123 though. Since 2:2.0.3-2 our initramfs hook needs proc(5) and sysfs(5) resp. mounted to /proc and /sys. I'm not sure about live-build, but d-i currently doesn't do that at finish-install stage. >> 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? > > live-boot rebuilds the initramfs image and hooks itself in the process, > it does manually open all luks containers: > > open_luks_container() is the way to open the luks partitition: > https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L830 > > find_persistence_media() is the place where all partititions > are scanned for luks: > https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-misc-helpers.sh#L1043 Hmm, so you don't really need the integration provided by cryptsetup-initramfs then; you want the cryptsetup binary and its shared library to be included to the initramfs image, but aren't using any of our boot scripts? If that's indeed the case then you could as well bypass our hooks and write your own to add said binaries and modules :-) >> 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. > > This is not so much a problem for us because the use case is always to add > an encrypted partition after the ISO image copied onto an USB key. We > don't need any special driver. I think you do, but probably rely on the initramfs image to contain all modules users might encounter in real life scenarios. At initramfs stage one doesn't have access to the modules of the main system; any module required for a device to be present at this stage (USB devices, SATA devices, crypt devices, whatever) *has to* be added to the image. MODULES="most" is often enough but not always, and sometimes extra modules need to be added, either manually or imported by another hook. >> 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. > > Can't you just trigger the warning only when CRYPTSETUP=n? If it's set to "y", > it doesn't match the old use case... it just means that we want to enable > it. It makes sense indeed, we can do that. > We just want that cryptsetup continues to use the sane defaults that > it has been using up to now and we want to be able to force its > installation into the initrd. That sounds like quite a brittle assumption IMHO. cryptsetup's default cipher/mode for LUKS changed over time, and they will keep doing so. For instance upstream changed from cbc-essiv:sha256 to aes-xts-plain64 with 1.6.0; these ciphers require different sets of modules, and on a CPU without AES-NI one can't unlock a volume formatted with 1.6.0's new default options from an initramfs lacking the ‘xts’ module. Similarly when luks2 and AEAD become the default, to unlock such volumes one will need libgcc and dm-integrity to be included in the initramfs image. The latter is currently not included by default, even when the image is generated with MODULES="most"… While our hook adds a basic subset of crypto modules to the initramfs, which are matching the *current* cryptsetup's default ciphers, there is no guaranty that an initramfs image built today contains all the ciphers to unlock a crypto volume formatted tomorrow (or yesterday). We never claimed this, and that's why our hook script relies on open mapped devices and the corresponding crypttab(5) entries to determine what's needed to unlock them. Maybe it's not relevant for a live ISO image, where 1/ the cryptsetup binary used to format the drive, 2/ the one from the initramfs, and 3/ the one from the main system, are all the same; but that “USB Persistence” feature seems to be a union a mount so I guess it's possible to upgrade, fall out of sync, and get an unbootable system if one is unlucky. -- Guilhem.
signature.asc
Description: PGP signature