Subject:
Inconsistent crypttab semantics between cryptsetup-initramfs and systemd-cryptsetup
may silently break boot-critical LUKS setups

Description:

Systems using classic cryptsetup-initramfs/keyscript-based LUKS unlocking methods may
end up in an inconsistent and potentially unbootable state after upgrading packages
related to:

```
systemd
systemd-cryptsetup
initramfs-tools
cryptsetup-initramfs
```

during upgrades around 2026-05-16 on Debian 13.5 (Trixie).


Relevant upgraded package groups during the affected upgrade window included:

* systemd / systemd-cryptsetup related packages
* initramfs-tools related packages
* linux-image / kernel packages
* grub / bootloader related packages

The issue appeared after initramfs regeneration following upgrades around 2026-05-16.

This issue appears to involve interactions between:
- initramfs-tools
- cryptsetup-initramfs
- systemd-cryptsetup

The core issue is not that systemd-cryptsetup exists in parallel to cryptsetup-
initramfs, but that the active initramfs generation and early userspace unlock
implementation may silently change semantics while continuing to use the same
/etc/crypttab configuration file.

In particular:

* /etc/crypttab options are interpreted differently depending on the active early
userspace cryptsetup implementation
* unsupported boot-critical options are silently ignored instead of causing a hard
failure
* no consistency validation exists between:

  * initramfs generation path
  * active early userspace cryptsetup implementation
  * supported crypttab options
  * installed cryptsetup-related packages

Observed behavior:

Classic initramfs-tools/cryptroot setups support:

```
keyscript=
```

but ignore:

```
fido2-device=
tpm2-device=
```

systemd-cryptsetup supports:

```
fido2-device=
tpm2-device=
```

but does not support:

```
keyscript=
```

A particularly problematic aspect is that:

* cryptsetup/libfido2 support may exist in normal userspace
* systemd-cryptsetup may be installed and operational in userspace
* but the generated initramfs still uses classic cryptroot/cryptsetup-initramfs
* while silently ignoring systemd-specific crypttab options after upgrades performed
around 2026-05-16

This creates the misleading impression that FIDO2-based unlocking is supported during
early boot, while the actual initramfs implementation does not contain:

* systemd-cryptsetup
* libfido2
* related FIDO2 integration hooks


At the same time, existing keyscript-based setups may stop functioning correctly if
initramfs generation changes the active early boot unlock implementation while
continuing to use the same crypttab configuration.

Example warning during initramfs generation:

```
cryptsetup: WARNING: sda5_crypt: ignoring unknown option 'fido2-device'
```

This warning is easy to overlook and does not clearly communicate that the generated
initramfs does not support FIDO2 unlocking at boot.





This is especially problematic for:

* remote systems
* colocated servers
* encrypted root filesystems
* unattended upgrades
* power outage recovery scenarios

A failed unlock path in such scenarios can render systems remotely unbootable.

In my environment this issue resulted in multiple systems becoming temporarily non-
bootable after initramfs regeneration because the expected unlock path no longer
matched the actually generated early userspace implementation.

Recovery was only possible because external backup keys were available. However,
diagnosing the issue and manually unlocking and repairing affected systems required
significant time and effort.



Important technical observation:

The issue is not caused by systemd-cryptsetup itself.

The actual problem is that initramfs generation and early userspace integration may
change during upgrades without ensuring feature parity or configuration compatibility
between:

* cryptsetup-initramfs
* cryptroot
* systemd-cryptsetup
* crypttab semantics
* available initramfs hooks

Suggested improvements:

1. Add hard validation for incompatible crypttab options depending on the active
initramfs stack.

2. Refuse initramfs generation when unsupported boot-critical crypttab options are
present.

3. Explicitly document that:

   * fido2-device= requires a compatible systemd-based initramfs implementation
   * cryptsetup-initramfs/cryptroot currently ignore these options
   * installing systemd-cryptsetup alone does not provide FIDO2 support inside
initramfs
   * additional manual initramfs integration is currently required to provide:
        - systemd-cryptsetup
        - libfido2
        - related FIDO2 hooks


4. Emit clear warnings when:

   * systemd-cryptsetup is installed
   * but the generated initramfs still uses classic cryptroot
   * or required FIDO2/systemd hooks are missing

5. Avoid silent fallback behavior for boot-critical encryption options.

Environment:

Debian 13 (Trixie)
initramfs-tools
cryptsetup-initramfs
systemd-cryptsetup
LUKS2
FIDO2 tokens (YubiKey / Nitrokey)

Relevant observation:

The following packages may coexist without guaranteeing compatible initramfs
behavior:

```
cryptsetup-initramfs
systemd-cryptsetup
```

This can create misleading assumptions about supported crypttab features and actual
early boot capabilities.


Additional relevant package groups observed during the affected upgrade sequence:

systemd related:

* systemd
* systemd-cryptsetup
* systemd-sysv
* systemd-container
* systemd-timesyncd
* libsystemd0
* libsystemd-shared
* libpam-systemd
* libnss-systemd
* udev
* libudev1

initramfs related:

* initramfs-tools
* initramfs-tools-core
* initramfs-tools-bin
* busybox

kernel / boot related:

* linux-image-amd64
* linux-image-6.12.88+deb13-amd64
* grub-*

Relevant package history:

* cryptsetup-initramfs was already installed on 2026-03-27
* systemd-cryptsetup was installed shortly afterwards