[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#849400: debian-installer: LUKS on rootfs and boot


Pali Rohár <pali.rohar@gmail.com> (2016-12-26):
> Package: debian-installer
> Severity: normal
> Dear Maintainer,
> Debian installer refuse me to install entire system (including /boot) on
> one encrypted partition. It shows me this red fatal error message:
>   [!!] Partition disks
>   Encryption configuration failure
>   You have selected the root file system to be stored on an encrypted partition. This
>   feature requires a separate /boot partition on which the kernel and initrd can be stored.
>   You should go back and setup a /boot partition.
> There are two buttons <Go Back> and <Continue> but both buttons go
> back and refuse to continue...
> Then I tried to have separate /boot and separate / partitions, both
> LUKS encrypted. But Debian installer again refused to install such
> configuration. It show me another red fatal error message:
>   [!!] Partition disks
>   Encrypted configuration failure
>   You have selected the /boot file system to be stored on an encrypted partition. This is
>   not possible because the boot loader would be unable to load the kernel and initrd.
>   Continuing now would result in an installation that cannot be used.
>   You should go back and choose a non-encrypted partition for he /boot file system.
> Again there are two buttons: <Go Back> and <Continue> and again both go
> back and does not allow me to process changes and continue.
> And that error message is incorrect. Grub2 has already supports for
> accessing LUKS partitions. Just add GRUB_ENABLE_CRYPTODISK=y (or in
> older versions GRUB_CRYPTODISK_ENABLE=y) to /etc/default/grub.
> Debian installer should allow users to install system on fully
> encrypted disk (also with /boot) and should not force users to have
> always /boot unencrypted.
> At least expert users should be able to skip that error message and
> continue installation as error message is not truth anymore.

FWIW: This is implemented in the partman-crypto package, see

And yeah, given latest grub features, updating this logic/these checks
seems to make sense.

I'm not sure about possible side effects / requirements (like having to
preconfigure grub to have appropriate configuration bits); this would
likely lead to having to update some documentation; one might have to be
careful about archs where grub is available/can load stuff from an
encrypted device.


Attachment: signature.asc
Description: Digital signature

Reply to: