Public bug reported:
# Description
On Ubuntu 26.04.1 LTS (Resolute), automatic unlocking of a
LUKS2-encrypted root partition using Clevis and a Tang server over HTTPS
fails during early boot when YubiKey-LUKS integration is not configured.
The system does not automatically unlock the encrypted root partition,
does not display a fallback LUKS passphrase prompt, and eventually drops
into the `(initramfs)` shell.
The same Clevis/Tang setup worked successfully on Ubuntu 24.04 without
requiring YubiKey-LUKS integration.
**Important observation:**
When YubiKey-LUKS integration is configured alongside Clevis/Tang on
Ubuntu 26.04.1 LTS, the system boots successfully and the root partition
is unlocked through Tang, even though **no physical YubiKey is connected
to the computer**.
This behavior has been confirmed during testing.
Therefore, the physical YubiKey device is not required for successful
Tang unlocking, but installing or configuring YubiKey-LUKS changes the
system's early-boot behavior in a way that allows Clevis/Tang to work.
The exact root cause has not yet been identified.
## System Information
**Operating System**
- Distribution: Ubuntu 26.04.1 LTS (Resolute)
- Release: 26.04
- Kernel: 7.0.0-38-generic
- Architecture: amd64
**Installed Packages**
- clevis: 20-1ubuntu2
- clevis-initramfs: 20-1ubuntu2
- clevis-luks: 20-1ubuntu2
- cryptsetup: 2:2.8.4-1ubuntu4
- cryptsetup-initramfs: 2:2.8.4-1ubuntu4
- initramfs-tools: 0.151ubuntu1
**Package Repository Information**
The following installed versions are also the current candidate versions
in the configured Ubuntu repositories:
- clevis: 20-1ubuntu2 — Ubuntu Resolute (universe)
- clevis-initramfs: 20-1ubuntu2 — Ubuntu Resolute (universe)
- cryptsetup-initramfs: 2:2.8.4-1ubuntu4 — Ubuntu Resolute (main)
**Encryption and Boot Configuration**
- Encryption: LUKS2
- Root filesystem: ext4 on LVM inside a LUKS2-encrypted partition
- Initramfs integration: clevis-initramfs / initramfs-tools
- Tang transport: HTTPS
- Additional integration: YubiKey-LUKS
The `dracut` package is removed, although `dracut-core` remains
installed. The system has `initramfs-tools` and `clevis-initramfs`
installed.
## Installation and Disk Configuration
Ubuntu was initially installed using the Ubuntu installer with the **LVM
and Encrypted** disk configuration option.
A LUKS passphrase was configured during installation.
After installation, the disk layout was modified using an Ubuntu Live
environment and GParted.
The resulting partition layout contains:
- An unencrypted EFI System Partition.
- An unencrypted `/boot` partition.
- A LUKS2-encrypted root partition containing LVM.
- A separate LUKS2-encrypted `/home` partition.
- A swap partition.
**Root partition:**
`/dev/nvme0n1p3`
**Home partition:**
`/dev/nvme0n1p4`
The root filesystem is located on an LVM logical volume inside the
encrypted root partition.
The separate `/home` partition is encrypted with LUKS2 and configured to
unlock using a local key file:
`/root/.keys/home.key`
The additional `/home` partition and swap configuration describe the
affected system and are not known to be required to reproduce the
problem.
## Clevis and Tang Configuration
The following packages were installed:
```bash
sudo apt install clevis clevis-luks clevis-initramfs -y
```
The root LUKS2 partition was bound to an HTTPS Tang server using:
```bash
sudo clevis luks bind \
-d /dev/nvme0n1p3 \
tang '{"url":"https://tang.example.com"}'
```
The initramfs was regenerated:
```bash
sudo update-initramfs -u -k all
```
Because the Tang server uses HTTPS, a custom initramfs hook was created
to include DNS resolver configuration and CA certificates.
**Custom hook location:**
`/usr/share/initramfs-tools/hooks/curl`
**Hook contents (with the DNS server address anonymized):**
```bash
#!/bin/sh -e
PREREQS=""
case $1 in
prereqs)
echo "${PREREQS}"
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
echo "nameserver 192.0.2.53\n" > "${DESTDIR}/etc/resolv.conf"
mkdir -p "${DESTDIR}/usr/share"
cp -ar /usr/share/ca-certificates "${DESTDIR}/usr/share/"
cp -ar /etc/ssl "${DESTDIR}/etc/"
```
The Tang hostname `tang.example.com` and DNS address `192.0.2.53` are
documentation placeholders, not the actual production values.
The Clevis binding was verified using:
```bash
sudo clevis luks list -d /dev/nvme0n1p3
```
Output (hostname anonymized):
```text
1: tang '{"url":"https://tang.example.com"}'
```
## LUKS and Crypttab Configuration
The root LUKS2 partition is configured through `/etc/crypttab`.
**Working configuration with YubiKey-LUKS integration:**
```text
dm_crypt-0 UUID=b0eabcdf-9e39-4a84-98ea-b61d3d887bbd none
luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
```
The `/home` partition is configured as:
```text
home_crypt UUID=3855915a-b51e-4cb7-add3-2b6b60e0eddf /root/.keys/home.key luks
```
**Configuration without YubiKey-LUKS integration:**
The root partition is configured without the YubiKey keyscript:
```text
dm_crypt-0 UUID=b0eabcdf-9e39-4a84-98ea-b61d3d887bbd none luks,discard
```
With this configuration, automatic Clevis/Tang unlocking fails during
boot and the system drops into the initramfs shell without displaying a
fallback LUKS passphrase prompt.
With YubiKey-LUKS configured, Tang unlocking succeeds even though no
physical YubiKey is connected.
## Steps to Reproduce
1. Install Ubuntu 26.04.1 LTS using the LVM and Encrypted disk
installation option.
2. Configure a LUKS2-encrypted root partition and retain a valid
recovery passphrase.
3. Install the required Clevis packages:
```bash
sudo apt install clevis clevis-luks clevis-initramfs -y
```
4. Configure the required DNS resolver and CA certificates in initramfs
so that an HTTPS Tang server can be accessed during early boot.
5. Bind the root LUKS2 partition to the Tang server:
```bash
sudo clevis luks bind \
-d /dev/nvme0n1p3 \
tang '{"url":"https://tang.example.com"}'
```
6. Regenerate the initramfs:
```bash
sudo update-initramfs -u -k all
```
7. Reboot without configuring YubiKey-LUKS integration.
8. Observe that automatic LUKS2 unlocking through Tang fails, no
fallback passphrase prompt appears, and the system drops into the
`(initramfs)` shell.
9. Configure YubiKey-LUKS integration using:
https://github.com/espegro/yubikey-luks
10. Regenerate the initramfs after configuring YubiKey-LUKS.
11. Reboot **without physically connecting a YubiKey device**.
12. Observe that the encrypted root partition now unlocks successfully
through Tang and Ubuntu boots normally.
The exact configuration change responsible for this difference has not
yet been isolated.
## Actual Behavior
**Scenario 1: Clevis + Tang without YubiKey-LUKS integration**
- Clevis does not successfully unlock the root LUKS2 partition during early
boot.
- Automatic Tang unlocking fails.
- No fallback LUKS passphrase prompt is displayed.
- The operating system drops into the `(initramfs)` shell.
- The system does not complete the boot process.
**Scenario 2: Clevis + Tang with YubiKey-LUKS integration**
- YubiKey-LUKS integration is installed and configured.
- No physical YubiKey device is connected.
- The encrypted root partition is successfully unlocked using Tang.
- Ubuntu completes the boot process normally.
The successful Tang unlock without a connected YubiKey has been
confirmed.
This suggests that the configuration or additional initramfs components
installed by YubiKey-LUKS influence the behavior of the Clevis/Tang
unlocking process.
## Expected Behavior
1. Clevis should automatically unlock the LUKS2 root partition using the
Tang server when it is reachable.
2. Tang-based unlocking should work independently of YubiKey-LUKS
integration.
3. If automatic Tang unlocking fails, the system should provide a usable
fallback LUKS passphrase prompt when a valid passphrase keyslot exists.
4. The system should not drop into the initramfs shell without offering
the configured recovery mechanism.
5. Plymouth and GRUB splash-screen settings should not prevent normal
disk unlocking or recovery.
## Troubleshooting Already Performed
The generated initramfs was inspected using:
```bash
sudo lsinitramfs /boot/initrd.img-$(uname -r) |
grep -E 'clevis|tang|jose|cryptroot|ykluks'
```
The following Clevis and cryptsetup components were confirmed to be
present:
```text
cryptroot
cryptroot/crypttab
scripts/local-block/cryptroot
scripts/local-bottom/clevis
scripts/local-bottom/cryptroot
scripts/local-top/clevis
scripts/local-top/cryptroot
usr/bin/clevis
usr/bin/clevis-decrypt
usr/bin/clevis-decrypt-null
usr/bin/clevis-decrypt-sss
usr/bin/clevis-decrypt-tang
usr/bin/clevis-luks-common-functions
usr/bin/clevis-luks-list
usr/bin/clevis-luks-unlock
usr/bin/cryptroot-unlock
usr/bin/jose
```
The generated initramfs also contains the YubiKey-LUKS components when
that integration is configured:
```text
etc/ykluks.cfg
usr/sbin/ykluks-keyscript
usr/share/yubikey-luks/ykluks-keyscript
```
**Inspection of the Clevis initramfs integration:**
I inspected the installed Clevis script:
```text
/usr/share/initramfs-tools/scripts/local-top/clevis
```
The script determines which password prompt mechanism is active:
```bash
if [ -x /bin/plymouth ] && plymouth --ping; then
cryptkeyscript='plymouth ask-for-password'
else
cryptkeyscript='\/lib\/cryptsetup\/askpass'
fi
```
It then attempts to locate the running password prompt process and its
associated cryptsetup password FIFO.
The Clevis script waits for a password prompt and FIFO before attempting
LUKS token decryption.
The script also contains the following logic:
```bash
if [ $netcfg_attempted -eq 0 ] && has_tang_pin ${CRYPTTAB_SOURCE}; then
netcfg_attempted=1
do_configure_networking
fi
```
This indicates that the Clevis script attempts network initialization
after detecting the password prompt process and identifying a Tang-bound
encrypted device.
If the expected password prompt process or FIFO is not found, Clevis may
not reach the Tang decryption stage.
However, it has not yet been confirmed that this is the cause of the
failure.
**Network configuration:**
The `/etc/initramfs-tools/initramfs.conf` file contains:
```text
DEVICE=
```
The observed kernel command line was:
```text
BOOT_IMAGE=/vmlinuz-7.0.0-38-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro
quiet
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
```
There is no explicit `ip=` parameter in the observed kernel command
line.
This does not necessarily indicate a configuration problem because
Clevis attempts to initialize networking itself.
The successful boot with YubiKey-LUKS integration demonstrates that the
Tang unlocking mechanism can function on this system.
## Possible Causes
The following are hypotheses and have not been confirmed as the root
cause:
1. An incompatibility between Clevis and cryptsetup password prompt or
FIFO handling in Ubuntu 26.04.1 LTS.
2. A change in Plymouth password prompt behavior that affects Clevis
detection of the active password prompt process.
3. A change in the initramfs environment or cryptsetup execution path
when YubiKey-LUKS integration is installed.
4. An initialization-order issue involving Clevis, cryptsetup, and
early-boot networking.
5. A regression affecting the interaction between `clevis-initramfs`,
`cryptsetup-initramfs`, and `initramfs-tools`.
6. A difference in how the YubiKey-LUKS keyscript initializes or invokes
the password prompt compared with the standard cryptsetup unlocking
procedure.
## Related Projects
**Clevis upstream project:**
https://github.com/latchset/clevis
**YubiKey-LUKS integration:**
https://github.com/espegro/yubikey-luks
**Potentially related upstream issues:**
- https://github.com/latchset/clevis/issues/248
- https://github.com/latchset/clevis/issues/168
These issues relate to Clevis, password prompts, Plymouth, or YubiKey-
LUKS integration but have not been confirmed as the same defect.
## Request
Could the Ubuntu maintainers please investigate whether this is a
regression affecting Clevis and cryptsetup-initramfs integration in
Ubuntu 26.04.1 LTS?
I would particularly appreciate help understanding the following:
1. Why does Clevis/Tang unlocking fail when YubiKey-LUKS integration is
not installed or configured?
2. Why does configuring YubiKey-LUKS allow Tang unlocking to succeed
even when no physical YubiKey is connected?
3. Why is the normal LUKS passphrase prompt not displayed when automatic
unlocking fails?
4. Have changes to cryptsetup, Plymouth, or initramfs-tools affected the
password prompt or FIFO mechanism used by Clevis?
5. Is there a recommended way to configure Clevis/Tang for automatic
LUKS2 root unlocking on Ubuntu 26.04.1 LTS without depending on YubiKey-
LUKS integration?
I can provide additional debugging information, initramfs contents,
package details, and boot logs if needed.
** Affects: clevis (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
+ # Description
+
+ On Ubuntu 26.04.1 LTS (Resolute), automatic unlocking of a
+ LUKS2-encrypted root partition using Clevis and a Tang server over HTTPS
+ fails during early boot when YubiKey-LUKS integration is not configured.
+
+ The system does not automatically unlock the encrypted root partition,
+ does not display a fallback LUKS passphrase prompt, and eventually drops
+ into the `(initramfs)` shell.
+
+ The same Clevis/Tang setup worked successfully on Ubuntu 24.04 without
+ requiring YubiKey-LUKS integration.
+
+ **Important observation:**
+
+ When YubiKey-LUKS integration is configured alongside Clevis/Tang on
+ Ubuntu 26.04.1 LTS, the system boots successfully and the root partition
+ is unlocked through Tang, even though **no physical YubiKey is connected
+ to the computer**.
+
+ This behavior has been confirmed during testing.
+
+ Therefore, the physical YubiKey device is not required for successful
+ Tang unlocking, but installing or configuring YubiKey-LUKS changes the
+ system's early-boot behavior in a way that allows Clevis/Tang to work.
+
+ The exact root cause has not yet been identified.
+
## System Information
**Operating System**
+
- Distribution: Ubuntu 26.04.1 LTS (Resolute)
- Release: 26.04
- Kernel: 7.0.0-38-generic
- Architecture: amd64
**Installed Packages**
+
- clevis: 20-1ubuntu2
- clevis-initramfs: 20-1ubuntu2
- clevis-luks: 20-1ubuntu2
- cryptsetup: 2:2.8.4-1ubuntu4
- cryptsetup-initramfs: 2:2.8.4-1ubuntu4
- initramfs-tools: 0.151ubuntu1
**Package Repository Information**
- All checked packages are installed at their current candidate versions:
+ The following installed versions are also the current candidate versions
+ in the configured Ubuntu repositories:
- clevis: 20-1ubuntu2 — Ubuntu Resolute (universe)
- clevis-initramfs: 20-1ubuntu2 — Ubuntu Resolute (universe)
- cryptsetup-initramfs: 2:2.8.4-1ubuntu4 — Ubuntu Resolute (main)
**Encryption and Boot Configuration**
+
- Encryption: LUKS2
- - Root filesystem: ext4 on LVM within LUKS2
- - Initramfs generator: initramfs-tools
+ - Root filesystem: ext4 on LVM inside a LUKS2-encrypted partition
+ - Initramfs integration: clevis-initramfs / initramfs-tools
- Tang transport: HTTPS
- Additional integration: YubiKey-LUKS
- The `dracut` package has been removed, although `dracut-core` remains
- installed. The system uses `initramfs-tools` and `clevis-initramfs` for
- early-boot disk unlocking.
+ The `dracut` package is removed, although `dracut-core` remains
+ installed. The system has `initramfs-tools` and `clevis-initramfs`
+ installed.
+
+ ## Installation and Disk Configuration
+
+ Ubuntu was initially installed using the Ubuntu installer with the **LVM
+ and Encrypted** disk configuration option.
+
+ A LUKS passphrase was configured during installation.
+
+ After installation, the disk layout was modified using an Ubuntu Live
+ environment and GParted.
+
+ The resulting partition layout contains:
+
+ - An unencrypted EFI System Partition.
+ - An unencrypted `/boot` partition.
+ - A LUKS2-encrypted root partition containing LVM.
+ - A separate LUKS2-encrypted `/home` partition.
+ - A swap partition.
+
+ **Root partition:**
+
+ `/dev/nvme0n1p3`
+
+ **Home partition:**
+
+ `/dev/nvme0n1p4`
+
+ The root filesystem is located on an LVM logical volume inside the
+ encrypted root partition.
+
+ The separate `/home` partition is encrypted with LUKS2 and configured to
+ unlock using a local key file:
+
+ `/root/.keys/home.key`
+
+ The additional `/home` partition and swap configuration describe the
+ affected system and are not known to be required to reproduce the
+ problem.
+
+ ## Clevis and Tang Configuration
+
+ The following packages were installed:
+
+ ```bash
+ sudo apt install clevis clevis-luks clevis-initramfs -y
+ ```
+
+ The root LUKS2 partition was bound to an HTTPS Tang server using:
+
+ ```bash
+ sudo clevis luks bind \
+ -d /dev/nvme0n1p3 \
+ tang '{"url":"https://tang.example.com"}'
+ ```
+
+ The initramfs was regenerated:
+
+ ```bash
+ sudo update-initramfs -u -k all
+ ```
+
+ Because the Tang server uses HTTPS, a custom initramfs hook was created
+ to include DNS resolver configuration and CA certificates.
+
+ **Custom hook location:**
+
+ `/usr/share/initramfs-tools/hooks/curl`
+
+ **Hook contents (with the DNS server address anonymized):**
+
+ ```bash
+ #!/bin/sh -e
+
+ PREREQS=""
+
+ case $1 in
+ prereqs)
+ echo "${PREREQS}"
+ exit 0
+ ;;
+ esac
+
+ . /usr/share/initramfs-tools/hook-functions
+
+ echo "nameserver 192.0.2.53\n" > "${DESTDIR}/etc/resolv.conf"
+
+ mkdir -p "${DESTDIR}/usr/share"
+ cp -ar /usr/share/ca-certificates "${DESTDIR}/usr/share/"
+ cp -ar /etc/ssl "${DESTDIR}/etc/"
+ ```
+
+ The Tang hostname `tang.example.com` and DNS address `192.0.2.53` are
+ documentation placeholders, not the actual production values.
+
+ The Clevis binding was verified using:
+
+ ```bash
+ sudo clevis luks list -d /dev/nvme0n1p3
+ ```
+
+ Output (hostname anonymized):
+
+ ```text
+ 1: tang '{"url":"https://tang.example.com"}'
+ ```
+
+ ## LUKS and Crypttab Configuration
+
+ The root LUKS2 partition is configured through `/etc/crypttab`.
+
+ **Working configuration with YubiKey-LUKS integration:**
+
+ ```text
+ dm_crypt-0 UUID=b0eabcdf-9e39-4a84-98ea-b61d3d887bbd none
luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
+ ```
+
+ The `/home` partition is configured as:
+
+ ```text
+ home_crypt UUID=3855915a-b51e-4cb7-add3-2b6b60e0eddf /root/.keys/home.key luks
+ ```
+
+ **Configuration without YubiKey-LUKS integration:**
+
+ The root partition is configured without the YubiKey keyscript:
+
+ ```text
+ dm_crypt-0 UUID=b0eabcdf-9e39-4a84-98ea-b61d3d887bbd none luks,discard
+ ```
+
+ With this configuration, automatic Clevis/Tang unlocking fails during
+ boot and the system drops into the initramfs shell without displaying a
+ fallback LUKS passphrase prompt.
+
+ With YubiKey-LUKS configured, Tang unlocking succeeds even though no
+ physical YubiKey is connected.
+
+ ## Steps to Reproduce
+
+ 1. Install Ubuntu 26.04.1 LTS using the LVM and Encrypted disk
+ installation option.
+
+ 2. Configure a LUKS2-encrypted root partition and retain a valid
+ recovery passphrase.
+
+ 3. Install the required Clevis packages:
+
+ ```bash
+ sudo apt install clevis clevis-luks clevis-initramfs -y
+ ```
+
+ 4. Configure the required DNS resolver and CA certificates in initramfs
+ so that an HTTPS Tang server can be accessed during early boot.
+
+ 5. Bind the root LUKS2 partition to the Tang server:
+
+ ```bash
+ sudo clevis luks bind \
+ -d /dev/nvme0n1p3 \
+ tang '{"url":"https://tang.example.com"}'
+ ```
+
+ 6. Regenerate the initramfs:
+
+ ```bash
+ sudo update-initramfs -u -k all
+ ```
+
+ 7. Reboot without configuring YubiKey-LUKS integration.
+
+ 8. Observe that automatic LUKS2 unlocking through Tang fails, no
+ fallback passphrase prompt appears, and the system drops into the
+ `(initramfs)` shell.
+
+ 9. Configure YubiKey-LUKS integration using:
+
+ https://github.com/espegro/yubikey-luks
+
+ 10. Regenerate the initramfs after configuring YubiKey-LUKS.
+
+ 11. Reboot **without physically connecting a YubiKey device**.
+
+ 12. Observe that the encrypted root partition now unlocks successfully
+ through Tang and Ubuntu boots normally.
+
+ The exact configuration change responsible for this difference has not
+ yet been isolated.
+
+ ## Actual Behavior
+
+ **Scenario 1: Clevis + Tang without YubiKey-LUKS integration**
+
+ - Clevis does not successfully unlock the root LUKS2 partition during early
boot.
+ - Automatic Tang unlocking fails.
+ - No fallback LUKS passphrase prompt is displayed.
+ - The operating system drops into the `(initramfs)` shell.
+ - The system does not complete the boot process.
+
+ **Scenario 2: Clevis + Tang with YubiKey-LUKS integration**
+
+ - YubiKey-LUKS integration is installed and configured.
+ - No physical YubiKey device is connected.
+ - The encrypted root partition is successfully unlocked using Tang.
+ - Ubuntu completes the boot process normally.
+
+ The successful Tang unlock without a connected YubiKey has been
+ confirmed.
+
+ This suggests that the configuration or additional initramfs components
+ installed by YubiKey-LUKS influence the behavior of the Clevis/Tang
+ unlocking process.
+
+ ## Expected Behavior
+
+ 1. Clevis should automatically unlock the LUKS2 root partition using the
+ Tang server when it is reachable.
+
+ 2. Tang-based unlocking should work independently of YubiKey-LUKS
+ integration.
+
+ 3. If automatic Tang unlocking fails, the system should provide a usable
+ fallback LUKS passphrase prompt when a valid passphrase keyslot exists.
+
+ 4. The system should not drop into the initramfs shell without offering
+ the configured recovery mechanism.
+
+ 5. Plymouth and GRUB splash-screen settings should not prevent normal
+ disk unlocking or recovery.
+
+ ## Troubleshooting Already Performed
+
+ The generated initramfs was inspected using:
+
+ ```bash
+ sudo lsinitramfs /boot/initrd.img-$(uname -r) |
+ grep -E 'clevis|tang|jose|cryptroot|ykluks'
+ ```
+
+ The following Clevis and cryptsetup components were confirmed to be
+ present:
+
+ ```text
+ cryptroot
+ cryptroot/crypttab
+ scripts/local-block/cryptroot
+ scripts/local-bottom/clevis
+ scripts/local-bottom/cryptroot
+ scripts/local-top/clevis
+ scripts/local-top/cryptroot
+ usr/bin/clevis
+ usr/bin/clevis-decrypt
+ usr/bin/clevis-decrypt-null
+ usr/bin/clevis-decrypt-sss
+ usr/bin/clevis-decrypt-tang
+ usr/bin/clevis-luks-common-functions
+ usr/bin/clevis-luks-list
+ usr/bin/clevis-luks-unlock
+ usr/bin/cryptroot-unlock
+ usr/bin/jose
+ ```
+
+ The generated initramfs also contains the YubiKey-LUKS components when
+ that integration is configured:
+
+ ```text
+ etc/ykluks.cfg
+ usr/sbin/ykluks-keyscript
+ usr/share/yubikey-luks/ykluks-keyscript
+ ```
+
+ **Inspection of the Clevis initramfs integration:**
+
+ I inspected the installed Clevis script:
+
+ ```text
+ /usr/share/initramfs-tools/scripts/local-top/clevis
+ ```
+
+ The script determines which password prompt mechanism is active:
+
+ ```bash
+ if [ -x /bin/plymouth ] && plymouth --ping; then
+ cryptkeyscript='plymouth ask-for-password'
+ else
+ cryptkeyscript='\/lib\/cryptsetup\/askpass'
+ fi
+ ```
+
+ It then attempts to locate the running password prompt process and its
+ associated cryptsetup password FIFO.
+
+ The Clevis script waits for a password prompt and FIFO before attempting
+ LUKS token decryption.
+
+ The script also contains the following logic:
+
+ ```bash
+ if [ $netcfg_attempted -eq 0 ] && has_tang_pin ${CRYPTTAB_SOURCE}; then
+ netcfg_attempted=1
+ do_configure_networking
+ fi
+ ```
+
+ This indicates that the Clevis script attempts network initialization
+ after detecting the password prompt process and identifying a Tang-bound
+ encrypted device.
+
+ If the expected password prompt process or FIFO is not found, Clevis may
+ not reach the Tang decryption stage.
+
+ However, it has not yet been confirmed that this is the cause of the
+ failure.
+
+ **Network configuration:**
+
+ The `/etc/initramfs-tools/initramfs.conf` file contains:
+
+ ```text
+ DEVICE=
+ ```
+
+ The observed kernel command line was:
+
+ ```text
+ BOOT_IMAGE=/vmlinuz-7.0.0-38-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv
ro quiet
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
+ ```
+
+ There is no explicit `ip=` parameter in the observed kernel command
+ line.
+
+ This does not necessarily indicate a configuration problem because
+ Clevis attempts to initialize networking itself.
+
+ The successful boot with YubiKey-LUKS integration demonstrates that the
+ Tang unlocking mechanism can function on this system.
+
+ ## Possible Causes
+
+ The following are hypotheses and have not been confirmed as the root
+ cause:
+
+ 1. An incompatibility between Clevis and cryptsetup password prompt or
+ FIFO handling in Ubuntu 26.04.1 LTS.
+
+ 2. A change in Plymouth password prompt behavior that affects Clevis
+ detection of the active password prompt process.
+
+ 3. A change in the initramfs environment or cryptsetup execution path
+ when YubiKey-LUKS integration is installed.
+
+ 4. An initialization-order issue involving Clevis, cryptsetup, and
+ early-boot networking.
+
+ 5. A regression affecting the interaction between `clevis-initramfs`,
+ `cryptsetup-initramfs`, and `initramfs-tools`.
+
+ 6. A difference in how the YubiKey-LUKS keyscript initializes or invokes
+ the password prompt compared with the standard cryptsetup unlocking
+ procedure.
+
+ ## Related Projects
+
+ **Clevis upstream project:**
+
+ https://github.com/latchset/clevis
+
+ **YubiKey-LUKS integration:**
+
+ https://github.com/espegro/yubikey-luks
+
+ **Potentially related upstream issues:**
+
+ - https://github.com/latchset/clevis/issues/248
+ - https://github.com/latchset/clevis/issues/168
+
+ These issues relate to Clevis, password prompts, Plymouth, or YubiKey-
+ LUKS integration but have not been confirmed as the same defect.
+
+ ## Request
+
+ Could the Ubuntu maintainers please investigate whether this is a
+ regression affecting Clevis and cryptsetup-initramfs integration in
+ Ubuntu 26.04.1 LTS?
+
+ I would particularly appreciate help understanding the following:
+
+ 1. Why does Clevis/Tang unlocking fail when YubiKey-LUKS integration is
+ not installed or configured?
+
+ 2. Why does configuring YubiKey-LUKS allow Tang unlocking to succeed
+ even when no physical YubiKey is connected?
+
+ 3. Why is the normal LUKS passphrase prompt not displayed when automatic
+ unlocking fails?
+
+ 4. Have changes to cryptsetup, Plymouth, or initramfs-tools affected the
+ password prompt or FIFO mechanism used by Clevis?
+
+ 5. Is there a recommended way to configure Clevis/Tang for automatic
+ LUKS2 root unlocking on Ubuntu 26.04.1 LTS without depending on YubiKey-
+ LUKS integration?
+
+ I can provide additional debugging information, initramfs contents,
+ package details, and boot logs if needed.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2170312
Title:
Ubuntu 26.04: Clevis/Tang fails to unlock LUKS2 root at boot and drops
to initramfs without a passphrase prompt
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/clevis/+bug/2170312/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
