[Kernel-packages] [Bug 1986623] Re: cryptsetup fails to decrypt root partion during boot

2022-08-17 Thread lorenzhuet...@hotmail.de
apport information

** Tags added: apport-collected jammy

** Description changed:

  During boot, cryptsetup fails to decrypt the root partition in a,
  seemingly, non-deterministic fashion. I know that the password is
  correct and that the keymap is not a fault either, because I have
  specifically chosen the very weak password "123456" for testing
  purposes. A hardware defect seems also rather unlikely as this behavior
  does not affect other Linux distributions or FreeBSD. Earlier Ubuntu
  versions do not seem to be affected either, as this bug appears to have
  been introduced during a kernel update in 20.04 and persists throughout
  20.04-22.04. Unfortunately I cannot pinpoint the exact kernel update
  that introduced this bug. I have appended the output of cryptsetup when
  manually called from the initramfs shell. Here the second attempt
  succeeded in decrypting the root partition, however, it usually takes a
  lot more attempts to do so.
  
  As for some additional information, I can decrypt the same luks
  partition from a live USB without any problems whatsoever.
  
  echo 123456 | cryptsetup open --type luks --debug /dev/nvme0n1p3 
nvme0n1p3_crypt
  # cryptsetup 2.4.3 processing "cryptsetup open --type luks --debug 
/dev/nvme0n1p3 nvme0n1p3_crypt"
  # Running command open.
  # Locking memory.
  # Installing SIGINT/SIGTERM handler.
  # Unblocking interruption on signal.
  # Allocating context for crypt device /dev/nvme0n1p3.
  # Trying to open and read device /dev/nvme0n1p3 with direct-io.
  # Initialising device-mapper backend library.
  # Trying to load any crypt type from device /dev/nvme0n1p3.
  # Crypto backend (OpenSSL 3.0.2 15 Mar 2022 [default]) initialized in 
cryptsetup library version 2.4.3.
  # Detected kernel Linux 5.15.0-46-generic x86_64.
  # Loading LUKS2 header (repair disabled).
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Trying to read primary LUKS2 header at offset 0x0.
  # Opening locked device /dev/nvme0n1p3
  # Verifying locked device handle (bdev)
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(on-disk)
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(in-memory)
  # Trying to read secondary LUKS2 header at offset 0x4000.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(on-disk)
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(in-memory)
  # Device size 497776852992, offset 16777216.
  # Device /dev/nvme0n1p3 READ lock released.
  # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, 
parallel_threads 4.
  # Activating volume nvme0n1p3_crypt using token (any type) -1.
  # dm version   [ opencount flush ]   [16384] (*1)
  # dm versions   [ opencount flush ]   [16384] (*1)
  # Detected dm-ioctl version 4.45.0.
  # Detected dm-crypt version 1.23.0.
  # Device-mapper backend running with UDEV support enabled.
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  No usable token is available.
  # STDIN descriptor passphrase entry requested.
  # Activating volume nvme0n1p3_crypt [keyslot -1] using passphrase.
  # dm versions   [ opencount flush ]   [16384] (*1)
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  # Keyslot 0 priority 1 != 2 (required), skipped.
  # Keyslot 1 priority 1 != 2 (required), skipped.
  # Trying to open LUKS2 keyslot 0.
  # Running keyslot key derivation.
  # Reading keyslot area [0x8000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifying key from keyslot 0, digest 0.
  # Digest 0 (pbkdf2) verify failed with -1.
  # Trying to open LUKS2 keyslot 1.
  # Running keyslot key derivation.
  # Reading keyslot area [0x47000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifying key from keyslot 1, digest 0.
  # Digest 0 (pbkdf2) verify failed with -1.
  # Releasing crypt device /dev/nvme0n1p3 context.
  # Releasing device-mapper backend.
  # Closing read only fd for /dev/nvme0n1p3.
  # Unlocking memory.
  Command failed with code -2 (no permission or bad passphrase).
  
  echo 123456 | cryptsetup open --type luks --debug /dev/nvme0n1p3 
nvme0n1p3_crypt
  # cryptsetup

[Kernel-packages] [Bug 1986623] ProcCpuinfoMinimal.txt

2022-08-17 Thread lorenzhuet...@hotmail.de
apport information

** Attachment added: "ProcCpuinfoMinimal.txt"
   
https://bugs.launchpad.net/bugs/1986623/+attachment/5609248/+files/ProcCpuinfoMinimal.txt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1986623

Title:
  cryptsetup fails to decrypt root partion during boot

Status in cryptsetup package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  During boot, cryptsetup fails to decrypt the root partition in a,
  seemingly, non-deterministic fashion. I know that the password is
  correct and that the keymap is not a fault either, because I have
  specifically chosen the very weak password "123456" for testing
  purposes. A hardware defect seems also rather unlikely as this
  behavior does not affect other Linux distributions or FreeBSD. Earlier
  Ubuntu versions do not seem to be affected either, as this bug appears
  to have been introduced during a kernel update in 20.04 and persists
  throughout 20.04-22.04. Unfortunately I cannot pinpoint the exact
  kernel update that introduced this bug. I have appended the output of
  cryptsetup when manually called from the initramfs shell. Here the
  second attempt succeeded in decrypting the root partition, however, it
  usually takes a lot more attempts to do so.

  As for some additional information, I can decrypt the same luks
  partition from a live USB without any problems whatsoever.

  echo 123456 | cryptsetup open --type luks --debug /dev/nvme0n1p3 
nvme0n1p3_crypt
  # cryptsetup 2.4.3 processing "cryptsetup open --type luks --debug 
/dev/nvme0n1p3 nvme0n1p3_crypt"
  # Running command open.
  # Locking memory.
  # Installing SIGINT/SIGTERM handler.
  # Unblocking interruption on signal.
  # Allocating context for crypt device /dev/nvme0n1p3.
  # Trying to open and read device /dev/nvme0n1p3 with direct-io.
  # Initialising device-mapper backend library.
  # Trying to load any crypt type from device /dev/nvme0n1p3.
  # Crypto backend (OpenSSL 3.0.2 15 Mar 2022 [default]) initialized in 
cryptsetup library version 2.4.3.
  # Detected kernel Linux 5.15.0-46-generic x86_64.
  # Loading LUKS2 header (repair disabled).
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Trying to read primary LUKS2 header at offset 0x0.
  # Opening locked device /dev/nvme0n1p3
  # Verifying locked device handle (bdev)
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(on-disk)
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(in-memory)
  # Trying to read secondary LUKS2 header at offset 0x4000.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(on-disk)
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(in-memory)
  # Device size 497776852992, offset 16777216.
  # Device /dev/nvme0n1p3 READ lock released.
  # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, 
parallel_threads 4.
  # Activating volume nvme0n1p3_crypt using token (any type) -1.
  # dm version   [ opencount flush ]   [16384] (*1)
  # dm versions   [ opencount flush ]   [16384] (*1)
  # Detected dm-ioctl version 4.45.0.
  # Detected dm-crypt version 1.23.0.
  # Device-mapper backend running with UDEV support enabled.
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  No usable token is available.
  # STDIN descriptor passphrase entry requested.
  # Activating volume nvme0n1p3_crypt [keyslot -1] using passphrase.
  # dm versions   [ opencount flush ]   [16384] (*1)
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  # Keyslot 0 priority 1 != 2 (required), skipped.
  # Keyslot 1 priority 1 != 2 (required), skipped.
  # Trying to open LUKS2 keyslot 0.
  # Running keyslot key derivation.
  # Reading keyslot area [0x8000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifying key from keyslot 0, digest 0.
  # Digest 0 (pbkdf2) verify failed with -1.
  # Trying to open LUKS2 keyslot 1.
  # Running keyslot key derivation.
  # Reading keyslot area [0x47000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock release

[Kernel-packages] [Bug 1986623] ProcEnviron.txt

2022-08-17 Thread lorenzhuet...@hotmail.de
apport information

** Attachment added: "ProcEnviron.txt"
   
https://bugs.launchpad.net/bugs/1986623/+attachment/5609249/+files/ProcEnviron.txt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1986623

Title:
  cryptsetup fails to decrypt root partion during boot

Status in cryptsetup package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  During boot, cryptsetup fails to decrypt the root partition in a,
  seemingly, non-deterministic fashion. I know that the password is
  correct and that the keymap is not a fault either, because I have
  specifically chosen the very weak password "123456" for testing
  purposes. A hardware defect seems also rather unlikely as this
  behavior does not affect other Linux distributions or FreeBSD. Earlier
  Ubuntu versions do not seem to be affected either, as this bug appears
  to have been introduced during a kernel update in 20.04 and persists
  throughout 20.04-22.04. Unfortunately I cannot pinpoint the exact
  kernel update that introduced this bug. I have appended the output of
  cryptsetup when manually called from the initramfs shell. Here the
  second attempt succeeded in decrypting the root partition, however, it
  usually takes a lot more attempts to do so.

  As for some additional information, I can decrypt the same luks
  partition from a live USB without any problems whatsoever.

  echo 123456 | cryptsetup open --type luks --debug /dev/nvme0n1p3 
nvme0n1p3_crypt
  # cryptsetup 2.4.3 processing "cryptsetup open --type luks --debug 
/dev/nvme0n1p3 nvme0n1p3_crypt"
  # Running command open.
  # Locking memory.
  # Installing SIGINT/SIGTERM handler.
  # Unblocking interruption on signal.
  # Allocating context for crypt device /dev/nvme0n1p3.
  # Trying to open and read device /dev/nvme0n1p3 with direct-io.
  # Initialising device-mapper backend library.
  # Trying to load any crypt type from device /dev/nvme0n1p3.
  # Crypto backend (OpenSSL 3.0.2 15 Mar 2022 [default]) initialized in 
cryptsetup library version 2.4.3.
  # Detected kernel Linux 5.15.0-46-generic x86_64.
  # Loading LUKS2 header (repair disabled).
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Trying to read primary LUKS2 header at offset 0x0.
  # Opening locked device /dev/nvme0n1p3
  # Verifying locked device handle (bdev)
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(on-disk)
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(in-memory)
  # Trying to read secondary LUKS2 header at offset 0x4000.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(on-disk)
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(in-memory)
  # Device size 497776852992, offset 16777216.
  # Device /dev/nvme0n1p3 READ lock released.
  # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, 
parallel_threads 4.
  # Activating volume nvme0n1p3_crypt using token (any type) -1.
  # dm version   [ opencount flush ]   [16384] (*1)
  # dm versions   [ opencount flush ]   [16384] (*1)
  # Detected dm-ioctl version 4.45.0.
  # Detected dm-crypt version 1.23.0.
  # Device-mapper backend running with UDEV support enabled.
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  No usable token is available.
  # STDIN descriptor passphrase entry requested.
  # Activating volume nvme0n1p3_crypt [keyslot -1] using passphrase.
  # dm versions   [ opencount flush ]   [16384] (*1)
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  # Keyslot 0 priority 1 != 2 (required), skipped.
  # Keyslot 1 priority 1 != 2 (required), skipped.
  # Trying to open LUKS2 keyslot 0.
  # Running keyslot key derivation.
  # Reading keyslot area [0x8000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifying key from keyslot 0, digest 0.
  # Digest 0 (pbkdf2) verify failed with -1.
  # Trying to open LUKS2 keyslot 1.
  # Running keyslot key derivation.
  # Reading keyslot area [0x47000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifyi

[Kernel-packages] [Bug 1986623] fstab.txt

2022-08-17 Thread lorenzhuet...@hotmail.de
apport information

** Attachment added: "fstab.txt"
   https://bugs.launchpad.net/bugs/1986623/+attachment/5609250/+files/fstab.txt

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1986623

Title:
  cryptsetup fails to decrypt root partion during boot

Status in cryptsetup package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  During boot, cryptsetup fails to decrypt the root partition in a,
  seemingly, non-deterministic fashion. I know that the password is
  correct and that the keymap is not a fault either, because I have
  specifically chosen the very weak password "123456" for testing
  purposes. A hardware defect seems also rather unlikely as this
  behavior does not affect other Linux distributions or FreeBSD. Earlier
  Ubuntu versions do not seem to be affected either, as this bug appears
  to have been introduced during a kernel update in 20.04 and persists
  throughout 20.04-22.04. Unfortunately I cannot pinpoint the exact
  kernel update that introduced this bug. I have appended the output of
  cryptsetup when manually called from the initramfs shell. Here the
  second attempt succeeded in decrypting the root partition, however, it
  usually takes a lot more attempts to do so.

  As for some additional information, I can decrypt the same luks
  partition from a live USB without any problems whatsoever.

  echo 123456 | cryptsetup open --type luks --debug /dev/nvme0n1p3 
nvme0n1p3_crypt
  # cryptsetup 2.4.3 processing "cryptsetup open --type luks --debug 
/dev/nvme0n1p3 nvme0n1p3_crypt"
  # Running command open.
  # Locking memory.
  # Installing SIGINT/SIGTERM handler.
  # Unblocking interruption on signal.
  # Allocating context for crypt device /dev/nvme0n1p3.
  # Trying to open and read device /dev/nvme0n1p3 with direct-io.
  # Initialising device-mapper backend library.
  # Trying to load any crypt type from device /dev/nvme0n1p3.
  # Crypto backend (OpenSSL 3.0.2 15 Mar 2022 [default]) initialized in 
cryptsetup library version 2.4.3.
  # Detected kernel Linux 5.15.0-46-generic x86_64.
  # Loading LUKS2 header (repair disabled).
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Trying to read primary LUKS2 header at offset 0x0.
  # Opening locked device /dev/nvme0n1p3
  # Verifying locked device handle (bdev)
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(on-disk)
  # Checksum:99172356e66a2fec247b1e5c758af8bc1338a3fb8bd973aab5e1512a93b2dbdc 
(in-memory)
  # Trying to read secondary LUKS2 header at offset 0x4000.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # LUKS2 header version 2 of size 16384 bytes, checksum sha256.
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(on-disk)
  # Checksum:655a50aef64b6fd4e10b8863df72d7fc62a7020f74684cb3419d4e22adb6fd9c 
(in-memory)
  # Device size 497776852992, offset 16777216.
  # Device /dev/nvme0n1p3 READ lock released.
  # PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, 
parallel_threads 4.
  # Activating volume nvme0n1p3_crypt using token (any type) -1.
  # dm version   [ opencount flush ]   [16384] (*1)
  # dm versions   [ opencount flush ]   [16384] (*1)
  # Detected dm-ioctl version 4.45.0.
  # Detected dm-crypt version 1.23.0.
  # Device-mapper backend running with UDEV support enabled.
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  No usable token is available.
  # STDIN descriptor passphrase entry requested.
  # Activating volume nvme0n1p3_crypt [keyslot -1] using passphrase.
  # dm versions   [ opencount flush ]   [16384] (*1)
  # dm status nvme0n1p3_crypt  [ opencount noflush ]   [16384] (*1)
  # Keyslot 0 priority 1 != 2 (required), skipped.
  # Keyslot 1 priority 1 != 2 (required), skipped.
  # Trying to open LUKS2 keyslot 0.
  # Running keyslot key derivation.
  # Reading keyslot area [0x8000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifying key from keyslot 0, digest 0.
  # Digest 0 (pbkdf2) verify failed with -1.
  # Trying to open LUKS2 keyslot 1.
  # Running keyslot key derivation.
  # Reading keyslot area [0x47000].
  # Acquiring read lock for device /dev/nvme0n1p3.
  # Opening lock resource file /run/cryptsetup/L_259:3
  # Verifying lock handle for /dev/nvme0n1p3.
  # Device /dev/nvme0n1p3 READ lock taken.
  # Reusing open ro fd on device /dev/nvme0n1p3
  # Device /dev/nvme0n1p3 READ lock released.
  # Verifying key from k