Hi,
I've had a bit of a headache understanding why my Debian bookworm system
suddenly panicked at boot with an 'unable to mount root fs' error. Turns
out the first of my two menuentries in grub.cfg were no longer
specifying the linux root by its device UUID (as I was expecting it to
do, by honoring GRUB_DISABLE_LINUX_UUID != true) ; instead these
menuentries were using the device node/file (/dev/md0 in this case,
hence the kernel panic).
I've poured through the grub scripts a bit but they're quite complex.
I've noticed that :
- uninstalling the second of two kernels caused the remaining one to
correctly use the device UUID in grub.cfg ;
- reinstalling that second kernel caused grub.cfg to use UUIDs in all
menuentries, as expected.
(Kernel were the two most recent stable ones: 6.1.0-17 and -18.)
This leads me to suspect that my grub.cfg might have been damaged in the
way described above because update-grub might have been called in some
unusual, limited execution environment. I'd very recently powered off my
system and let the default "install pending software updates" option
checked by accident, which caused every updated package from the 12.5
release mark to be pulled. I'm guessing that linux-image-6.1.0-18 was
part of it.
Has anyone witnessed something similar? Would anyone here care to check
this somehow? Or should I open a bug against gnome-desktop without waiting?
Thank you for any insight.
Apologies for possible e-mail client misconfiguration.
Regards,
--
Lucas
