I recently installed stock Fedora 40 Workstation from live media. Since installing, I updated once successfully to kernel 6.10.8. More recent updates to 6.10.9, and 6.10.10 both failed with “kernel panic – not syncing: VFS: Unable to mount root fs on unknown-block(0,0).”
I’m wondering if there’s something about my hardware setup that may be causing this problem, as it’s the same thing that happened when I tried to upgrade Fedora 38 to 39, which is what induced me to do a clean install of 40 to a different partition. I have a Grub2 multiboot with Windows, could that be the/an issue.
Athlon 950
Radeon R250 2G
32G
2 x 1T hdd ( Fedora is installed to one), and 1, 100G SDD (Windows)
VFS: Unable to mount root fs on unknown-block(0,0). usually means there is a problem with the grub configuration, so you should check (use Gnome Disks if you aren’t familiar with command-line tools) for duplicated UUID’s. The installer uses UUID’s to identify partitions, so the grub configuration should be OK unless you made manual changes after installing. One issue is that some systems unexpectedly swap sda and sdb.
We need more details to understand your problem, but there are some things you can try that may resolve the issue
make sure that all updates have been applied, including vendor firmware. Newer kernels may fail when there are “unpatched” security issues in firmware. Fedora has fwupd for vendor firmware, with command-line tools fwupdtool and fwupdmgr, or many vendors support firmware updates using a Windows GUI tool.
try booting 610.10 after using the grub menu editor to remove rhgb quiet from the kernel command-line or by editing /etc/default/grub, then running sudo grub2-mkconfig -o /boot/grub2/grub.cfg to “permanently” remove those options. You will immediately see error messages that are hidden by the default configuration which I think is designed more for mass deployments than for individual users. The error message is often enough to allow you find a solution with searches in this forum or a wider web search (but be very careful of clickbait sites promising “easy” solutions).
hardware tests: some vendors provide tests that can be run at boot time or by booting a USB stick they provide. Gnome Disks can be used to run S.MA.R.T tests.
If you are still having the problem, please provide: hardware and software details:
inxi -Fzxx provides a useful overview but often needs followup questions. inxi is not installed by default, but you can install it in 6.10.8. Please past the output as pre-formatted text (use the </> button from the top line of the text entry panel).
details of the disk layout from lsblk -o +UUID (as pre-formatted text).
There aren’t any duplicate UUIDs shown from blkid command. I did remove “rhgb quiet” during boot to see the error messages. A common message to my FC38 and FC40 update woes is “Initramfs unpacking failed: junk within compressed archive.” This message also happened in FC38 when I used dracut to manually remake the initramfs (I haven’t bothered to try it in 40 yet)
Confusing because earlier kernels aren’t affected by this issue, and I never encountered it before in using successive releases of the past ~15-years until I tried the dist-upgrade of 38-39.
/boot/initramfs-6.10.10-200.fc40.x86_64.img
Similar errors have been reported across distros for years with many different distros. There seem to be many just in the past month. Some appear to stem from experiments with alternate compression methods. I suggest you try a web search for the above error in the past month to see if any of the causes look familiar.
Your BIOS is quite old – you really should look for updates.
Here:
% sudo file /boot/initramfs- 6.10*
/boot/initramfs-6.10.10-200.fc40.x86_64.img: ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.10.8-200.fc40.x86_64.img: ASCII cpio archive (SVR4 with no CRC)
/boot/initramfs-6.10.9-200.fc40.x86_64.img: ASCII cpio archive (SVR4 with no CRC)
Check whether lsinitrd has issues with the problem files.
Doesn’t appear to be a problem with the initramfs-6.10.10-200.fc40.x86_64.img (I’m only pasting the first part of the output, the rest appears to be a standard Linux system folder):
If you don’t get the error using lsinitrd then the most likely explanations include non-default initramfsimages (could be created by experiments or malware) or a bug in the boot-time code that does the unpacking. Since initramfs is needed to start the linux filesystems, I assume it relies on the BIOS for disk access, so you should look for a BIOS update.
I’m not understanding why 6.10.8 (dnf upgraded from 6.10.5) works with the current BIOS, yet 6.10.9 and 6.10.10 don’t. I’m not using non-default anything.
I was able to get 6.10.10 to boot by regenerating it in dracut. As an aside, I ran memtest and my RAM failed spectacularly. I’m running it in dual-channel mode (same make-model), but the sticks were purchased a couple of years apart, and a RAM supplier tech guy said it wouldn’t work in dual channel. This could explain some other periodic issues in both Fedora and Windows.