[pkg-cryptsetup-devel] Bug#908220: Bug#908220: cryptsetup-initramfs: Need a clean way to force cryptsetup in initramfs

[Guilhem Moulin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180907/d6ffe437/attachment.sig>