Encrypted installs cannot unlock root in the initramfs

Breadway commented

2026-09-26 07:27:05 +08:00

Owner

Problem

GRUB is wired to unlock LUKS (GRUB_ENABLE_CRYPTODISK=y, cryptodisk modules in grub-install), and the encrypt/sd-encrypt hook is added to mkinitcpio. But nothing tells the initramfs which device to open:

no cryptdevice= (udev encrypt hook) or rd.luks.uuid= (systemd sd-encrypt) is ever written to GRUB_CMDLINE_LINUX
no /etc/crypttab.initramfs is written
Calamares' grubcfg module, which normally adds these, is deliberately not in settings.conf's exec sequence, and luksbootkeyfile is missing too

grep -rn 'cryptdevice\|rd.luks\|crypttab\|keyfile' iso scripts returns nothing. The site claims the encryption wiring means "it actually boots".

Where

iso/airootfs/etc/calamares/post-install.sh lines 11-22 (detection), 139-148 (hook), 166-175 (GRUB), 197-220 (grub-install / mkconfig)
iso/airootfs/etc/calamares/settings.conf exec sequence

Fix

Resolve the LUKS container UUID: take the parent of the mapper device from lsblk -no PKNAME "$ROOT_SRC", then run cryptsetup luksUUID on it.
Depending on ENCRYPT_HOOK:
- encrypt: add cryptdevice=UUID=<luks-uuid>:<mapper-name> to GRUB_CMDLINE_LINUX
- sd-encrypt: add rd.luks.name=<luks-uuid>=<mapper-name> (or write /etc/crypttab.initramfs)
Make sure root= points at the unlocked mapper (/dev/mapper/<name>), or that grub-mkconfig's UUID resolves after unlocking.
Avoid the double passphrase: generate a keyfile (dd bs=512 count=4 if=/dev/random), add it with cryptsetup luksAddKey, put it in FILES= in mkinitcpio.conf with mode 0600, and pass cryptkey=rootfs:/crypto_keyfile.bin (udev), or reference it in crypttab.initramfs (systemd). Alternatively add Calamares' luksbootkeyfile module to the exec sequence and check what it writes.
Run all of this before mkinitcpio -P (line 179) and grub-mkconfig.

Acceptance

An encrypted "Erase disk" install in a UEFI VM asks for the passphrase once (GRUB), then boots to breadgreet.
The same works on BIOS.
scripts/smoke-test.sh checks, when root is crypt, that /proc/cmdline contains cryptdevice= or rd.luks.

Source: BOS v0.6.2 source review (tag dated 2026-09-19); paths and line numbers refer to that tree. Read AGENTS.md first. One issue per branch/PR, match existing style (commented shell, per-step WARN:, idempotent steps). Verify with FAST_BUILD=1 sudo ./build-local.sh plus QEMU/OVMF (UEFI) and SeaBIOS (BIOS) VM installs where relevant; encryption needs an OVMF VM. Add a CHANGELOG [Unreleased] entry.

## Problem GRUB is wired to unlock LUKS (`GRUB_ENABLE_CRYPTODISK=y`, cryptodisk modules in `grub-install`), and the `encrypt`/`sd-encrypt` hook is added to mkinitcpio. But nothing tells the initramfs *which* device to open: - no `cryptdevice=` (udev `encrypt` hook) or `rd.luks.uuid=` (systemd `sd-encrypt`) is ever written to `GRUB_CMDLINE_LINUX` - no `/etc/crypttab.initramfs` is written - Calamares' `grubcfg` module, which normally adds these, is deliberately not in `settings.conf`'s exec sequence, and `luksbootkeyfile` is missing too `grep -rn 'cryptdevice\|rd.luks\|crypttab\|keyfile' iso scripts` returns nothing. The site claims the encryption wiring means "it actually boots". ## Where - `iso/airootfs/etc/calamares/post-install.sh` lines 11-22 (detection), 139-148 (hook), 166-175 (GRUB), 197-220 (grub-install / mkconfig) - `iso/airootfs/etc/calamares/settings.conf` exec sequence ## Fix 1. Resolve the LUKS *container* UUID: take the parent of the mapper device from `lsblk -no PKNAME "$ROOT_SRC"`, then run `cryptsetup luksUUID` on it. 2. Depending on `ENCRYPT_HOOK`: - `encrypt`: add `cryptdevice=UUID=<luks-uuid>:<mapper-name>` to `GRUB_CMDLINE_LINUX` - `sd-encrypt`: add `rd.luks.name=<luks-uuid>=<mapper-name>` (or write `/etc/crypttab.initramfs`) 3. Make sure `root=` points at the unlocked mapper (`/dev/mapper/<name>`), or that grub-mkconfig's UUID resolves after unlocking. 4. Avoid the double passphrase: generate a keyfile (`dd bs=512 count=4 if=/dev/random`), add it with `cryptsetup luksAddKey`, put it in `FILES=` in mkinitcpio.conf with mode 0600, and pass `cryptkey=rootfs:/crypto_keyfile.bin` (udev), or reference it in crypttab.initramfs (systemd). Alternatively add Calamares' `luksbootkeyfile` module to the exec sequence and check what it writes. 5. Run all of this **before** `mkinitcpio -P` (line 179) and `grub-mkconfig`. ## Acceptance - An encrypted "Erase disk" install in a UEFI VM asks for the passphrase once (GRUB), then boots to breadgreet. - The same works on BIOS. - `scripts/smoke-test.sh` checks, when root is `crypt`, that `/proc/cmdline` contains `cryptdevice=` or `rd.luks`. --- Source: BOS v0.6.2 source review (tag dated 2026-09-19); paths and line numbers refer to that tree. Read AGENTS.md first. One issue per branch/PR, match existing style (commented shell, per-step `WARN:`, idempotent steps). Verify with `FAST_BUILD=1 sudo ./build-local.sh` plus QEMU/OVMF (UEFI) and SeaBIOS (BIOS) VM installs where relevant; encryption needs an OVMF VM. Add a CHANGELOG `[Unreleased]` entry.

Breadway added the

labels

2026-09-26 07:27:05 +08:00

Breadway referenced this issue from a pull request that will close it,

2026-09-30 01:03:47 +08:00

Encrypted installs can unlock root in the initramfs #53

Breadway commented

2026-09-30 01:03:52 +08:00

Author

Owner

PR opened: #53

Calamares now creates and registers the boot keyfile before fstab, and encrypted root is configured in mkinitcpio before initramfs generation. Bash syntax, Calamares YAML parsing, diff checks, and the FAST_BUILD ISO build passed. The build had an existing nbd-client initramfs hook warning but completed. UEFI and BIOS encrypted VM install/boot checks have not been run, so this issue remains in doing pending that validation.

PR opened: https://git.breadway.dev/Breadway/bos/pulls/53 Calamares now creates and registers the boot keyfile before fstab, and encrypted root is configured in mkinitcpio before initramfs generation. Bash syntax, Calamares YAML parsing, diff checks, and the FAST_BUILD ISO build passed. The build had an existing nbd-client initramfs hook warning but completed. UEFI and BIOS encrypted VM install/boot checks have not been run, so this issue remains in doing pending that validation.

Breadway commented

2026-09-30 03:57:24 +08:00

Author

Owner

Review outcome: acceptance is not yet verified, so PR #53 is blocked and BOS-23 should remain DOING while boot validation is active.

Acceptance interpretation:

An encrypted Erase disk install under UEFI asks for the passphrase once in GRUB, then reaches breadgreet.
The same encrypted install works under BIOS.
The smoke test checks that encrypted root has a cryptdevice= or rd.luks.name= parameter.

The diff maps the setup to settings.conf:34-47, prepare-encrypted-root.sh:31-64, and post-install.sh's encrypted GRUB parameter block. scripts/smoke-test.sh:116-122 checks the boot parameter. The reported FAST_BUILD ISO and this command-line check do not establish that either UEFI or BIOS unlocks root successfully, or that UEFI prompts only once. Please record successful encrypted Erase disk installs and boots to breadgreet on both firmware modes, including the GRUB prompt behavior, before moving this issue to review/done.

Current PR metadata also reports mergeable: false; the commit status endpoint has no recorded statuses.

Review outcome: acceptance is not yet verified, so PR #53 is blocked and BOS-23 should remain DOING while boot validation is active. Acceptance interpretation: 1. An encrypted Erase disk install under UEFI asks for the passphrase once in GRUB, then reaches breadgreet. 2. The same encrypted install works under BIOS. 3. The smoke test checks that encrypted root has a `cryptdevice=` or `rd.luks.name=` parameter. The diff maps the setup to `settings.conf:34-47`, `prepare-encrypted-root.sh:31-64`, and `post-install.sh`'s encrypted GRUB parameter block. `scripts/smoke-test.sh:116-122` checks the boot parameter. The reported FAST_BUILD ISO and this command-line check do not establish that either UEFI or BIOS unlocks root successfully, or that UEFI prompts only once. Please record successful encrypted Erase disk installs and boots to breadgreet on both firmware modes, including the GRUB prompt behavior, before moving this issue to review/done. Current PR metadata also reports `mergeable: false`; the commit status endpoint has no recorded statuses.

Breadway commented

2026-09-30 03:58:08 +08:00

Author

Owner

Independent review of PR #53 found the code path covers the planned GRUB unlock configuration, but acceptance is still unverified: fresh encrypted UEFI and BIOS installs must prompt once, unlock root, and reach breadgreet. The smoke test only checks the kernel command line. Forgejo also reports the PR is not mergeable. No test run is currently active, so returning BOS-23 to TODO until VM evidence and mergeability are addressed.

Breadway commented

2026-10-01 15:58:11 +08:00

Author

Owner

Updated existing PR #53 branch with current origin/main (5ae8040), producing head 49bb927f8aa80d4671aa7a7fd40af378e1a0e32d. Shell syntax, static encrypted-root wiring checks, and merge-diff whitespace checks pass. BOS has no ordinary-push CI configured. UEFI and BIOS encrypted Calamares installs and boot-to-breadgreet checks remain unrun. Root directed no further guest input and no additional VM, so this acceptance cannot be completed in the current run. Returning BOS-23 to TODO pending those exact checks.

Updated existing PR #53 branch with current `origin/main` (5ae8040), producing head `49bb927f8aa80d4671aa7a7fd40af378e1a0e32d`. Shell syntax, static encrypted-root wiring checks, and merge-diff whitespace checks pass. BOS has no ordinary-push CI configured. UEFI and BIOS encrypted Calamares installs and boot-to-breadgreet checks remain unrun. Root directed no further guest input and no additional VM, so this acceptance cannot be completed in the current run. Returning BOS-23 to TODO pending those exact checks.

Breadway commented

2026-10-01 16:26:05 +08:00

Author

Owner

PR #53 has the implementation and static wiring checks recorded on the rebased head. Fresh encrypted UEFI/BIOS Calamares installs and boot-to-breadgreet acceptance remain outstanding; BOS has no ordinary push CI. Moving the implementation to REVIEW for the requested handoff. Do not treat as verified or done until those acceptance checks are recorded.

Breadway closed this issue

2026-10-02 14:15:59 +08:00

Rows
Columns

Encrypted installs cannot unlock root in the initramfs #23

Problem

Where

Fix

Acceptance