| 2024-01-29 06:49:37 |
Nobuto Murata |
bug |
|
|
added bug |
| 2024-01-29 06:51:17 |
Nobuto Murata |
attachment added |
|
history.log https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/2051478/+attachment/5742977/+files/history.log |
|
| 2024-01-29 08:48:22 |
Nobuto Murata |
description |
The system suddenly stopped accepting the existing passphrase on boot. However, the passphrase is definitely correct since the same one can be used in the recovery mode and it unlocks the volume appropriately.
I'm not sure which recent update brought this behavior.
Last successful graphical boot: 2024-01-28 00:43:09 +0900
Fwiw, the existing passphrase was long enough and contains some special characters such as "!". The confusing part is shorter passphrase but with "!" seems to work.
WORKAROUND:
1. boot into the recovery mode
2. unlock the volume in the console
3. add a new key with `cryptsetup luksAddKey /dev/nvme0n1p3`
3. reboot
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: cryptsetup 2:2.6.1-6ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 29 15:41:03 2024
InstallationDate: Installed on 2024-01-08 (21 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-6.6.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
crypttab: dm_crypt-0 UUID=cfd8c295-9988-4934-a91a-460a9d16d80f none luks |
The system suddenly stopped accepting the existing passphrase on boot. However, the passphrase is definitely correct since the same one can be used in the recovery mode and it unlocks the volume appropriately.
I'm not sure which recent update brought this behavior.
Last successful graphical boot: 2024-01-28 00:43:09 +0900
Fwiw, the existing passphrase was long enough and contains some special characters such as "!". The confusing part is shorter passphrase but with "!" seems to work.
WORKAROUND:
1. boot into the recovery mode
2. unlock the volume in the console
3. add a new key with `cryptsetup luksAddKey /dev/nvme0n1p3`
or remove "splash" from /etc/default/grub and run `update-grub`
3. reboot
ProblemType: BugDistroRelease: Ubuntu 24.04
Package: cryptsetup 2:2.6.1-6ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 29 15:41:03 2024
InstallationDate: Installed on 2024-01-08 (21 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-6.6.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
crypttab: dm_crypt-0 UUID=cfd8c295-9988-4934-a91a-460a9d16d80f none luks |
|
| 2024-01-29 08:56:54 |
Nobuto Murata |
bug task added |
|
plymouth (Ubuntu) |
|
| 2024-01-29 08:59:30 |
Nobuto Murata |
cryptsetup (Ubuntu): status |
New |
Invalid |
|
| 2024-01-29 10:51:35 |
Nobuto Murata |
description |
The system suddenly stopped accepting the existing passphrase on boot. However, the passphrase is definitely correct since the same one can be used in the recovery mode and it unlocks the volume appropriately.
I'm not sure which recent update brought this behavior.
Last successful graphical boot: 2024-01-28 00:43:09 +0900
Fwiw, the existing passphrase was long enough and contains some special characters such as "!". The confusing part is shorter passphrase but with "!" seems to work.
WORKAROUND:
1. boot into the recovery mode
2. unlock the volume in the console
3. add a new key with `cryptsetup luksAddKey /dev/nvme0n1p3`
or remove "splash" from /etc/default/grub and run `update-grub`
3. reboot
ProblemType: BugDistroRelease: Ubuntu 24.04
Package: cryptsetup 2:2.6.1-6ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 29 15:41:03 2024
InstallationDate: Installed on 2024-01-08 (21 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-6.6.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
crypttab: dm_crypt-0 UUID=cfd8c295-9988-4934-a91a-460a9d16d80f none luks |
The system suddenly stopped accepting the existing passphrase on boot. However, the passphrase is definitely correct since the same one can be used in the recovery mode and it unlocks the volume appropriately.
More precisely, it looks like devices that inject characters pretty quickly (e.g. Yubikey to type pre-created random strings with length=32) are necessary to trigger the issue.
WORKAROUND:
1. boot into the recovery mode
2. unlock the volume in the console
3. remove "splash" from /etc/default/grub and run `update-grub`
3. reboot
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: cryptsetup 2:2.6.1-6ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 29 15:41:03 2024
InstallationDate: Installed on 2024-01-08 (21 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-6.6.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
crypttab: dm_crypt-0 UUID=cfd8c295-9988-4934-a91a-460a9d16d80f none luks |
|
| 2024-01-29 13:06:50 |
Nobuto Murata |
bug watch added |
|
https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/243 |
|
| 2024-01-31 07:35:20 |
Daniel van Vugt |
bug task added |
|
plymouth |
|
| 2024-01-31 12:05:24 |
Daniel van Vugt |
bug |
|
|
added subscriber Daniel van Vugt |
| 2024-01-31 14:08:01 |
Nobuto Murata |
summary |
unlock passphrase doesn't work in plymouth but works in recovery mode |
Typing passphrase pretty quickly using Yubikey fails to unlock a LUKS partition |
|
| 2024-01-31 14:09:03 |
Nobuto Murata |
description |
The system suddenly stopped accepting the existing passphrase on boot. However, the passphrase is definitely correct since the same one can be used in the recovery mode and it unlocks the volume appropriately.
More precisely, it looks like devices that inject characters pretty quickly (e.g. Yubikey to type pre-created random strings with length=32) are necessary to trigger the issue.
WORKAROUND:
1. boot into the recovery mode
2. unlock the volume in the console
3. remove "splash" from /etc/default/grub and run `update-grub`
3. reboot
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: cryptsetup 2:2.6.1-6ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 29 15:41:03 2024
InstallationDate: Installed on 2024-01-08 (21 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-6.6.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
crypttab: dm_crypt-0 UUID=cfd8c295-9988-4934-a91a-460a9d16d80f none luks |
It looks like there are some behavioral changes between 22.02.122 and 23.360.11. I didn't have any issue until recently but after upgrading to 23.360.11 on Ubuntu, the same unlocking method of LUKS partition stopped working.
How to reproduce:
1. format Yubikey with a static password
```
$ ykman otp static --generate 2
```
(it will emit 38 characters and the ENTER event within a moment when a button is long pressed)
2. add the new key to LUKS
```
$ sudo cryptsetup luksAddKey /dev/nvme0n1p3
```
3. reboot and use the Yubikey to input the passphrase
Actual:
it fails to unlock
When typing the same passphrase by-hand it works. Furthermore, when not using Plymouth, both by-hand typing and Yubikey work.
WORKAROUND:
1. boot into the recovery mode
2. unlock the volume in the console
3. remove "splash" from /etc/default/grub and run `update-grub`
3. reboot
ProblemType: Bug
DistroRelease: Ubuntu 24.04
Package: cryptsetup 2:2.6.1-6ubuntu1
ProcVersionSignature: Ubuntu 6.6.0-14.14-generic 6.6.3
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelModules: zfs
ApportVersion: 2.27.0-0ubuntu6
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 29 15:41:03 2024
InstallationDate: Installed on 2024-01-08 (21 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: BOOT_IMAGE=/vmlinuz-6.6.0-14-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash
crypttab: dm_crypt-0 UUID=cfd8c295-9988-4934-a91a-460a9d16d80f none luks |
|
| 2024-01-31 18:11:17 |
Bug Watch Updater |
plymouth: status |
Unknown |
New |
|
| 2024-02-08 03:47:05 |
Bug Watch Updater |
plymouth: status |
New |
Fix Released |
|
| 2024-02-11 06:57:23 |
Nobuto Murata |
plymouth (Ubuntu): status |
New |
Fix Released |
|
