On Fri 29 Mar 2024 at 11:06:45 (-0400), Henning Follmann wrote: > On Fri, Mar 29, 2024 at 12:01:27PM +0100, Lucas B. Cohen wrote: > > > > 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). > > Was there any error message during the update? > I think what might have gone wrong, that you ran out of space on /boot. > > > I've poured through the grub scripts a bit but they're quite complex. I've > > noticed that : > > Yeah, don't do that. These files are all automatically managed. > All changes should be done in /etc/default/grub or in the config files in > /etc/default/grub.d > Then the grub config files are created by running > update-grub > > > - uninstalling the second of two kernels caused the remaining one to > > correctly use the device UUID in grub.cfg ; > > and that might have freed enough space on /boot. > So now everything works again :) > > > - 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.
I'd write "upgraded" rather than "pulled", if that's what you meant. > > Has anyone witnessed something similar? Would anyone here care to check this > > somehow? Or should I open a bug against gnome-desktop without waiting? > > > Usually it requires some trickery to install a new kernel on machines which > might not have enough remaining space on the boot partition. > > For simple housekeeping it often is sufficient to run > apt autoremove > after recent updates (after you confirmed that the newly installed kernel > boots fine). > That usually frees enough space for a possible new update. You can also reduce the space taken up by initrd files, which are getting rather large nowadays if they are built with MODULES=most rather than MODULES=dep. When you have at least two working kernels, remove any unnecessary backups, copy the older kernel's initrd somewhere else, then rebuild it with MODULES=dep. If that kernel still boots ok, then you probably have a lot more room available now for the next kernel upgrade. Finally, reboot the newer kernel. Cheers, David.
