Bug#389835: [Pkg-cryptsetup-devel] Bug#389835: better out of the box luks root migration support

David Härdeman david at hardeman.nu
Thu Sep 28 08:51:56 UTC 2006


On Thu, September 28, 2006 3:25, maximilian attems said:
> now having my newly encrypted root i thought to be easily boot of it,
> the encountered troubles where:
> 1) initramfs had no cryptsetup bin
> 2) initramfs had no dm_crypt, sha256 and aes modules
> 3) README.initramfs did not document bootarg
>
> to resolve 1) and 2) please do put those binaries unconditionaly,
> on the initramfs unless the cryptoroot hook is invoked with an dep arg
> for MODULES=dep usage. any other initramfs-tools hook support lands
> there so this was really counter-inituitive.

Ah, I see...I'll change the hook to always add the binary and a reasonable
subset of modules (unless running with MODULES=dep as you said)

> also luks doesn't need an /etc/cryptoroot entry afaik?

It does require one. And if one had been found, the binaries and modules
would have been copied to the initramfs. You would also not have had to
add any cryptopts to the kernel command line.

In your case, I guess you'd want a line like this:
croot /dev/sda2 none luks

> the following bootarg worked fine, please add it to the doc
> root=/dev/sda2 ro cryptopts=target=sda2

Actually, I'm considering removing support for the "cryptopts" option
rather than documenting it. The settings should be automatic so the
cryptopts is just for fixing a messed up installation. However, if the
crypto is fscked, the user can manually set it up in the initramfs shell
with about as much effort as writing the proper cryptopts on the command
line.

Additionally, I'm going to have to add support for encrypted swap setup
during boot as well since swsusp won't work otherwise. That would add yet
another kernel option if "cryptopts" was kept...

-- 
David Härdeman





More information about the Pkg-cryptsetup-devel mailing list