READ THROUGH THIS WHOLE POST BEFORE TRYING ANY OF IT!

My computer runs on Linux Mint Xfce 22.3.

My computer was acting normally yesterday; tried to boot it up for the first time today and I was inexplicably met with a purple screen reading something to the effect of KERNEL PANIC! Please reboot your computer. VFS: Unable to mount root fs on unknown-block(0,0) — I had gotten a similar if not identical screen before, when I botched a Timeshift and it broke initramfs, so I wasn’t too scared. I remembered I could boot into an older version of the kernel and try to sort things from there.

I tried to follow this YouTube tutorial first, albeit with the following differences:

  • I used dpkg --list 'linux-image*' 'linux-headers*' | grep 6.17 -i instead of dpkg --list 'linux-image*' 'linux-headers*' | grep 6.17* -i (i.e. I got rid of the asterisk after 6.17)
  • I did NOT run sudo apt autoremove --purge since the list of packages to be removed looked completely different from those in the tutorial and it seemed like a risky move.

The packages that I purged were only ones related to kernel version 6.17.0-35 (IIRC). All the tutorial I followed seemed to do for me was just get rid of that kernel version altogether without reinstalling it, but the newest kernel version after that had the exact same failure to boot issue, as did apparently all my 6.17 kernel versions (I was booting into 6.14 kernel versions).

Anyways, after doing that, I noticed that Update Manager was showing a kernel update, so I ran that kernel update, but the issue persisted after that as well. I think it was at this point that I backed up my personal files to an external hard drive, which I probably should’ve done before trying to fix the issue but eh it went fine.

And then I took a break to fill my stomach.

After this, I returned to my own posts here the last time I had failures to boot, in particular this post. I think I first tried sudo dpkg-reconfigure linux-image-6.17.0-29-generic only for it to tell me that that kernel was “broken or not fully installed”. Then I ran sudo update-initramfs -c -k linux-image-6.17.0-29-generic, and I noticed it was giving me a syntax error about how the version didn’t start with a digit. “A-ha!” I thought, “So I’m supposed to drop the linux-image- part here.” — and so I did that and tried to reboot the computer, and once again I ran into the purple kernel panic screen. So then I tried running sudo dpkg-reconfigue 6.17.0-29-generic, and I think it gave me a different but similar error as before, about how it had “no information” on that kernel version. So then I tried running sudo update-grub and restarted the computer one more time, and then it booted into the newest kernel version.

TL;DR: I think what I was supposed to do to begin with was sudo update-initramfs -c -k linux-image-6.17.0-29-generic (or I suppose 6.17.0-35 if I hadn’t accidentally deleted that kernel version while trying to solve my issue) and then sudo update-grub — just the one or the other wouldn’t work, but both of them together in that order. But also, I’m not a computer wiz, this is just what seemed to work for me.

It is very confusing and frustrating in any case that I would just randomly get that issue. I hadn’t updated the kernel or run Timeshift or done anything else likely to break startup, it just broke completely randomly. But at least I’ve got enough Linux experience now that solving this sort of issue only took a few hours instead of taking days.

PS: Now there’s another kernel update in Update Manager, apparently for the kernel version I accidentally deleted. I guess I should probably install that update now. Also, I was going to tell you all about this fix for the mt7921e issue I’d been experiencing, but the Github page is now a 404 and it’s not on the Wayback Machine and I don’t remember what I did well enough to relay it to you from memory. Alas!

  • trompete [he/him]@hexbear.netEnglish
    6·
    21 hours ago

    I’m pretty sure you are correct that the initramfs is corrupted. The initramfs is a cpio archive (kinda like a zip file) that functions as the early root file system (hence the error message referring to the “root fs”), before the real root file system is mounted. Grub loads it into RAM, I think directly behind the kernel, and the kernel then expects to find it there. Since grub doesn’t complain about the initrd file (/boot/initrd.img-*blabla*) missing, it means it’s there, it’s just corrupted.

    The initramfs corruption almost certainly occurs when it is being generated, which is usually during kernel installation, or when certain packages are being updated. During apt upgrade or apt install basically. There should be errors. In fact I suspect apt would error out in that case.

    Why it fails to generate the initramfs I don’t know. A common issue I think is a full /boot partition. Look out for error messages when upgrading the system, or installing a kernel, I guess?

    Some notes about the commands you mention:

    If one were to totally manually install a kernel, one would indeed need to run update-initramfs to generate the initramfs (/boot/initrd.img-*blabla*), followed by update-grub, which regenerates /boot/grub/grub.cfg, which is the file containing the grub menu entries. I.e. if one were to forget running update-grub, it would not show up in the grub menu when you boot next time. Of course, all this should happen automatically when the kernel is installed.

    About apt autoremove: That removes packages that were installed automatically as a dependency, but are no longer needed. E.g. if you did apt install foo, and that installed foo, but also libfoo, autoremove would never remove foo (since it was manually installed by you), but if you later uninstalled foo, libfoo would no longer be needed, and apt autoremove would remove that. The --purge option removes config files also, which may stay installed otherwise. This refers to system wide config files in e.g. /etc, it will not touch anything in /home. Whether you use --purge or not doesn’t matter pretty much ever.

    These unneeded packages can accumulate, as updates sometimes no longer depend on them, so it is to expected that you see a bunch that are unique to your system. Notably, apt autoremove will remove old kernels as well, I think as long they’re not currently booted. This could explain why they tell you to run autoremove, to free up the /boot drive.