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.

Hi,

Pali Rohár <pali.rohar@gmail.com> (2016-12-26):
check.d/crypto_check_mountpoints

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.


KiBi.

If such logic is complicated to implement, then for *expert* users
should be such installation allowed. Expert users could re-configure
grub2 as needed if they know what they are doing.

But currently I'm not able to skip that error message in any way.

Any progress for skipping this red fatal error message?

I am affected by this as well.

Googling shows shows people experimenting with workarounds - creating an
additional unencrypted /boot partition independent of the unencrypted EFI
partition.

This is overly complicated when the subsequent install workflow already
does the correct thing - in creating a /boot partition and
kernel/initrd/grub on the EFI parition.

One just needs to be able to hint that the EFI/fat32 parition will be used
for /boot, or else simply let the user 'continue' the installation, rather
than have both 'go-back' and 'continue' return to the same menu.
partition. This
initrd can be stored.
partition. This is
and initrd.
file system.

[...]

DO NOT use a fat32 partition for /boot!

It will appear to work, but the first upgrade of a package that
installs into /boot will fail because dpkg cannot create a hard link
there.

Ben.

Thanks Ben, that's reasonable justification.

Maybe /boot/efi was what was meant.

This problem still persists, on DI Buster Alpha 2 and Alpha 3. Working
around this even as an expert is rather cumbersome; one has to play
with the various menu options, partially configuring disks/partitions
etc., to load the necessary cryptsetup components (and dependencies,
like awk for decrypt_derived script), and it cannot be completed via
the installer.

As the submitter notes, having /boot on an encrypted (LUKS) partition
_is_ supported by GRUB and the other softwares.  Simply making
"continue" not do the same as "go back," as was originally suggested,
would be a big improvement.  Without this, one has to setup with an
unencrypted /boot, and then use rescue mode or other knowledge to
encrypt /boot and finalize the setup.  I found no way to proceed to
install with /boot being encrypted.

this affects me, too, and is rather frustrating. i welcome warnings and
suggestions from software, but this is just plain annoying without a way
to override it.

i flashed libreboot into my laptop (it's an opensource bios where grub
is the payload in the bios flash chip itself). i want to have a full
disk encryption that libreboot's grub opens and then restarts the grub
configured in /boot/ within the encrypted root.

this all works, except that the debian installer doesn't allow me to
setup the disk they way i want (it insists on an unencrypted /boot).

a workaround is to navigate the installer to setting up encrypted disks,
so that it loads the necessary packages that include e.g. cryptsetup,
and then on a different terminal cryptsetup the disk as you wish. then
the gui installer can be convinced to continue (it also insists on
installing grub somewhere, but that is the last step and can be skipped).

This affects me, too.

And it's really weird that it doesn't work, because the live installer
(calamares) manages this setup just fine. It's the recommended setup
there, actually.

Hi

I too encountered difficulty with trying to install the entire system (including /boot) on
one encrypted partition.

The issue is this block of code: https://salsa.debian.org/installer-team/partman-crypto/-/blob/master/check.d/crypto_check_mountpoints#L94-102

This 17 year old "Check - Is there a /boot partition for encrypted root?" is no longer valid.

Grub2 added support for accessing LUKS1 partitions in 2011 - https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a251b71915e40194d12995dbac9efd787687f988

Grub2 support for LUK2 is also present but only for PBKDF2 keys - https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755

For people who use LUKS1 to do full disk encryption, this "Check - Is there a /boot partition for encrypted root?" is a blocker in the Debian installer.

Dear maintainer(s), please review this bug report and remove this check.

regards,
Jinesh

Hi,

Jinesh Choksi <jinesh@onelittlehope.com> (2023-07-02):

It is.

Sure, that's known, and there were two talks during Mini-DebConfs in
2019 about this and LUKS2 (Marseille, Hamburg).

And since default LUKS2 settings are argon2id (argon2i previously), that
means that cannot work.

People finding their way to use LUKS1 instead of the default LUKS2 can
remove this check on their own.

Not until GRUB gets support for argon2i{d,}. And that's where my focus
is right now when it comes to d-i vs. LUKS.

PoC at https://salsa.debian.org/kibi/grub/-/commits/luks2-argon2-v0
but I have better plans to investigate.


Cheers,

Unhelpful and disappointing that users who need to setup FDE in Bookworm have to jump through hoops.

To the future reader(s), setting up FDE in Bookworm as it is now, with luks1 can be achieved via the following (assuming disk = /dev/sda):

- Perform an Expert Install

- Choose manual disk partitioning

- Setup a GPT partition table

- Setup an EFI partition (min 100MB), mounted as /boot/efi

- Setup a DMCRYPT partition using remaining free space. (i.e. Physical volume for encryption)

- Choose to "Configure encrypted volumes"

- Set a password for the encrypted volume

- Switch to TTY2, activate console and type in: (you need to do the following as cryptsetup defaults to luks2 (since 2019) and the installer doesn't provide options to select which luks format to use)

  - cryptsetup luksClose sda2_crypt

  - cryptsetup luksFormat --type luks1 /dev/sda2

  - cryptsetup luksOpen /dev/sda2 sda2_crypt

- Select "Go back", and select "Detect Disks" (needed to refresh partman's state)

- Select "Partition Disks" again

- Set the file system for the encrypted volume to "physical volume for LVM". You need to do this because of the issue mentioned in this bug. By using LVM, it bypasses the issue in this bug. Even though you don't actually need LVM. The alternative suggested by the D-I release manager is to remove the following block of code in the /lib/partman/check.d/07crypto_check_mountpoints file before you finalise your partitioning:

Jinesh Choksi <jinesh@onelittlehope.com> (2023-07-03):

You want “unhelpful”? You got it! The answer is: “yes”.

Also, plonk.

Hi Jinesh,

Can you provide a series of steps to replicate the failure case reported in
this bug?

I'll try to find time within the next two weeks to confirm the results that you
and others have seen here, and to check what we can do from the points of the
code that you linked to.

Thank you,
James

Reproduction Steps

- Boot using debian-12.1.0-amd64-netinst.iso in a VM

- At the Grub boot menu, select Advanced options > Expert Install

- Go through the following install steps using defaults or as desired:

  - Choose language
  - Configure the keyboard
  - Detect and mount installation media
  - Load installer components from installation media
  - Detect network hardware
  - Configure the network
  - Set up users and password
  - Configure the clocks
  - Detect disks

- When you reach the "Partition disks" step, choose "Manual" disk partitioning method

- Setup a GPT partition table

- Setup an EFI partition (min 100MB), mounted as /boot/efi

- Setup a DMCRYPT partition using remaining free space. (i.e. use as "Physical volume for encryption")

- Choose to "Configure encrypted volumes"

- Set a password for the encrypted volume (also to speed up the process, set Erase data to: No)

- At this point, switch to TTY2, activate console and type in (the following is needed as it is not possible to select luks version):

  - cryptsetup luksClose sda2_crypt

  - cryptsetup luksFormat --type luks1 /dev/sda2

  - cryptsetup luksOpen /dev/sda2 sda2_crypt

- Switch back to TTY1 and select "Go back", and select "Detect Disks" (needed to refresh partman's state)

- Select "Partition Disks" again

- Set the file system for the encrypted volume to "XFS" (i.e. use as XFS journaling file system) and set the mount point to /.

- To reduces reproduction steps, we won't set up a swap partition.

- Finally, select "Finish partitioning and write changes to disk"

- You will see a dialog saying:

  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.

  <Go Back>                   <Continue>

- It is not possible to get past this dialog.

- Note: If it was possible to get past this dialog, then you can proceed with installation as per normal until you get to the "Install Grub Boot Loader" stage. You will find that this stage errors at the "grub-install (dummy)" step.

- If you look at msgs on TTY4, you will note it says to add the line "GRUB_ENABLE_CRYPTODISK=y" to the /etc/default/grun file. So, switch console on TTY2 and edit /target/etc/default/grub file and add this line.

- Run the "Install Grub Boot Loader" stage again and it will work and rest of the install will progress normally.

- The missing "GRUB_ENABLE_CRYPTODISK=y" line is a seperate bug #925134.

Thanks Jinesh - one question in particular inline below:

Does replicating this issue require steps where the user switches to a
virtual terminal / other TTY?

I don't see that mentioned in other previous thread comments.  The
debian-installer team shouldn't support workflows that require use of
custom commandline steps.

Jinesh Choksi <jinesh@onelittlehope.com> (2023-07-29):

As mentioned in various other places, first we need to teach GRUB about
argon2i(d), then we can think about enabling cryptodisk support. Also,
we need a plan for the GRUB-to-Linux handover.

Ugly PoC for the first part in the following branch, but the plan is to
try and update libgcrypt instead.

https://salsa.debian.org/kibi/grub/-/commits/luks2-argon2-v0


Cheers,