Unable to boot "Gave up waiting for root device" for kernel version 5.3.0-19 & 5.3.0-22

Bug #1852521 reported by Shaform
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned
Eoan
Invalid
High
Unassigned

Bug Description

Ubuntu cannot boot if using kernel version 5.3.0-19 & 5.3.0-22.

However, kernel version 5.3.0-18 works fine.

The root disk is encrypted. When booting with 5.3.0-18, a passsphrase input field is displayed during boot. However, such an input field does not appear in 5.3.0-19 & 5.3.0-22, which eventually leads to time out and the boot failed.

Additional information: When I execute `sudo update-initramfs -c -k 5.3.0-22-generic`

It shows the following:

> update-initramfs: Generating /boot/initrd.img-5.3.0-22-generic
> cryptsetup: WARNING: Skipping root target nvme0n1p5_crypt: uses a key file

I feel that the message about the root partition (nvme0n1p5_crypt) using a key file might suggest something wrong? Because actually I didn't use a key file for the root partition, instead only a passphrase is used.

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: linux-image-5.3.0-18-generic 5.3.0-18.19+1
ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
Uname: Linux 5.3.0-18-generic x86_64
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: shaform 2068 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 13 21:41:07 2019
InstallationDate: Installed on 2019-11-09 (5 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
MachineType: LENOVO 20LD0017US
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.3.0-18-generic root=UUID=6709141d-5e30-44ef-a676-c3bb559cd47c ro quiet splash
RelatedPackageVersions:
 linux-restricted-modules-5.3.0-18-generic N/A
 linux-backports-modules-5.3.0-18-generic N/A
 linux-firmware 1.183.1
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/29/2019
dmi.bios.vendor: LENOVO
dmi.bios.version: N25ET50W (1.36 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20LD0017US
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 31
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN25ET50W(1.36):bd07/29/2019:svnLENOVO:pn20LD0017US:pvrThinkPadX1Yoga3rd:rvnLENOVO:rn20LD0017US:rvrSDK0J40697WIN:cvnLENOVO:ct31:cvrNone:
dmi.product.family: ThinkPad X1 Yoga 3rd
dmi.product.name: 20LD0017US
dmi.product.sku: LENOVO_MT_20LD_BU_Think_FM_ThinkPad X1 Yoga 3rd
dmi.product.version: ThinkPad X1 Yoga 3rd
dmi.sys.vendor: LENOVO

Revision history for this message
Shaform (shaform) wrote :
Shaform (shaform)
description: updated
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Tyler Hicks (tyhicks) wrote :

Thanks for the report, Shaform. There are a few other bug reports against 5.3.0-22 and we're trying to understand if there's a common link. It looks like you're using LUKS/dm-crypt to do full disk encryption of your root partition so we're waiting to hear if that's common throughout the other reports. Thanks again!

Revision history for this message
Shaform (shaform) wrote :

It seems that after I performed certain updates, I could not even boot the system with 5.3.0-18 kernel now, which seems to suggest the problem might not originate from the kernel itself.

Revision history for this message
Shaform (shaform) wrote :

I did some investigation. It seems that in /etc/crypttab, the third column of the encrypted disk does points to a key file, and the content of the key file is the passphrase.

Not sure why this is created, but I've previously used Ubuntu's disk utility to change the passphrase of my root disk, maybe this is related.

Anyway, I changed the third column to `none` and manually remove the key file. Finally, I execute update-initramfs again and now the system become bootable even with the latest kernel.

Stefan Bader (smb)
Changed in linux (Ubuntu Eoan):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Thadeu Lima de Souza Cascardo (cascardo) wrote :

Marking as invalid, as this was not related to the TPM or module signing issues we have seen, and the reporter found the problem on crypttab.

Thank you.
Cascardo.

Changed in linux (Ubuntu Eoan):
status: Confirmed → Invalid
Changed in linux (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.