buster: cannot boot into kernel 4.19.0-17

Julian Schreck

unread,

Jul 14, 2021, 5:00:02 AM7/14/21

to

Dear Sir or Madam,
after an update of my packages (in debian stable for amd64 [1]), which included a newer kernel (from 4.19.0-16 to
4.19.0-17; [2]), I cannot boot with the newest kernel. After its selection and waiting for 35 seconds, a "rescue shell"
(?) comes up [3].
How can I change the UUID "the boot process" searches for? Do you know what went (or could have gone) wrong here?
Note: My disk is encrypted.

Kind regards,
Julian Schreck

PS: forums.debian.net can be pinged right now, but my browser can't load the site.
--
[1] : $ uname -a
Linux first 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux

[2] : $ LC_ALL=C apt list -i *4.19*
Listing... Done
linux-headers-4.19.0-14-amd64/stable,stable,now 4.19.171-2 amd64 [installed]
linux-headers-4.19.0-14-common/stable,stable,now 4.19.171-2 all [installed,automatic]
linux-headers-4.19.0-16-amd64/stable,now 4.19.181-1 amd64 [installed]
linux-headers-4.19.0-16-common/stable,now 4.19.181-1 all [installed]
linux-headers-4.19.0-17-amd64/proposed-updates,stable-updates,now 4.19.194-2 amd64 [installed,automatic]
linux-headers-4.19.0-17-common/proposed-updates,stable-updates,now 4.19.194-2 all [installed,automatic]
linux-image-4.19.0-14-amd64/stable,stable,now 4.19.171-2 amd64 [installed]
linux-image-4.19.0-16-amd64/stable,now 4.19.181-1 amd64 [installed,automatic]
linux-image-4.19.0-17-amd64/proposed-updates,stable-updates,now 4.19.194-2 amd64 [installed,automatic]
linux-kbuild-4.19/proposed-updates,stable-updates,now 4.19.194-2 amd64 [installed,automatic]

[3] : Gave up waiting for suspend/resume device
Gave up waiting for root file system device. Common problems:
– Boot args (cat /proc/cmdline)
– Check rootdelay= (did the system wait long enough?)
– Missing modules (cat /proc/modules; ls /dev)
ALERT! UUID=[an unknown UUID] does not exist. Dropping to a shell!

BusyBox v1.30.1 (Debian 1:1.30.1-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Ben Hutchings

unread,

Jul 19, 2021, 2:40:03 PM7/19/21

to

On Wed, 2021-07-14 at 10:38 +0200, Julian Schreck wrote:
> Dear Sir or Madam,
> after an update of my packages (in debian stable for amd64 [1]), which included a newer kernel (from 4.19.0-16 to
> 4.19.0-17; [2]), I cannot boot with the newest kernel. After its selection and waiting for 35 seconds, a "rescue shell"
> (?) comes up [3].
> How can I change the UUID "the boot process" searches for? Do you know what went (or could have gone) wrong here?

I think that GRUB reads the root device UUID or other identifier from
/etc/fstab, but I'm not sure.

> Note: My disk is encrypted.

[...]

Make sure you still have cryptsetup-initramfs installed.

Ben.

--
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

signature.asc

Ben Hutchings

unread,

Jul 19, 2021, 2:50:03 PM7/19/21

to

On Mon, 2021-07-19 at 20:37 +0200, Ben Hutchings wrote:
> On Wed, 2021-07-14 at 10:38 +0200, Julian Schreck wrote:
> > Dear Sir or Madam,
> > after an update of my packages (in debian stable for amd64 [1]), which included a newer kernel (from 4.19.0-16 to
> > 4.19.0-17; [2]), I cannot boot with the newest kernel. After its selection and waiting for 35 seconds, a "rescue shell"
> > (?) comes up [3].
> > How can I change the UUID "the boot process" searches for? Do you know what went (or could have gone) wrong here?
>
> I think that GRUB reads the root device UUID or other identifier from
> /etc/fstab, but I'm not sure.

To be more specific: I think update-grub does that. So if you change
to a different root device you would have to update /etc/fstab and then
run update-grub.

But, if you've changed to a different root device, all the older kernel
versions would also fail to boot if you didn't do that.

> > Note: My disk is encrypted.
> [...]
>
> Make sure you still have cryptsetup-initramfs installed.

It's more likely that this package (or something else involved in
initramfs building) has been uninstalled for some reason.

signature.asc

Julian Schreck

unread,

Jul 20, 2021, 5:20:03 AM7/20/21

to

> > Dear Sir or Madam,
> > after an update of my packages (in debian stable for amd64 [1]), which included a newer kernel (from 4.19.0-16 to
> > 4.19.0-17; [2]), I cannot boot with the newest kernel. After its selection and waiting for 35 seconds, a "rescue shell"
> > (?) comes up [3].
> > How can I change the UUID "the boot process" searches for? Do you know what went (or could have gone) wrong here?
>
> I think that GRUB reads the root device UUID or other identifier from
> /etc/fstab, but I'm not sure.
>
> > Note: My disk is encrypted.
> [...]
>
> Make sure you still have cryptsetup-initramfs installed.

That was it; cryptsetup-initramfs was ”[residual-config]“:

$ LC_ALL=C apt list cryptsetup-initramfs
Listing... Done
cryptsetup-initramfs/stable,now 2:2.1.0-5+deb10u2 all [residual-config]

> Ben.
Thanks.

Julian Schreck

unread,

Jul 20, 2021, 5:50:03 AM7/20/21

to

These packages are also ”[residual-config]“. Which of them should also be (fully) installed with cryptsetup-initramfs?
cryptsetup docutils-common golang-github-gotk3-gotk3-dev ipython3-qtconsole libxvmc1 sgml-base tiny-initramfs-core tlp
xml-core

Ben Hutchings

unread,

Jul 20, 2021, 8:20:03 AM7/20/21

to

On Tue, 2021-07-20 at 11:31 +0200, Julian Schreck wrote:
> These packages are also ”[residual-config]“. Which of them should also be (fully) installed with cryptsetup-initramfs?
> cryptsetup docutils-common golang-github-gotk3-gotk3-dev ipython3-qtconsole libxvmc1 sgml-base tiny-initramfs-core tlp
> xml-core

cryptsetup is needed (and cryptsetup-initramfs depends on it).

Ben.

--
Ben Hutchings
Kids! Bringing about Armageddon can be dangerous. Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

signature.asc