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

[Raphael Hertzog]

Hi,

On Sat, 08 Sep 2018, Guilhem Moulin wrote:
> > 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.

I just checked, /proc and /sys are mounted in the chroot when live-build
installs the packages.

> 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 :-)

Hum, there's also this line which calls your hook script:
https://salsa.debian.org/live-team/live-boot/blob/master/components/9990-main.sh#L7

It's possibly to support the cryptopts= kernel command line?
Or maybe for dealing with a crypttab that the user embedded in the live
image? (one of the selling features of live-build is the possibility to
customize almost everything)

> I think you do, but probably rely on the initramfs image to contain all
> modules users might encounter in real life scenarios.

Definitely.

> > 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.

Great, thank you!

> 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

Indeed.

> 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.

The persistence feature does not allow to update the kernel/initrd. It can
be updated in the overlay file system but the kernel/initrd are booted
before the persistence partition is mounted so you always end up using
the kernel/initrd embedded in the ISO.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 523 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180908/6c733856/attachment.sig>