“KERNEL PANIC! Please reboot your computer. VFS: Unable to mount root fs on unknown-block(0,0)”
also grub boot options have dropped from 4 to 2, that is, duplicates are not listed.
from reading seems possible to be failed grub update? and i should update grub. but what caused the failure?
i am booted on a usb an old non-fedora distro, and also latest fedora core-os, no apparent hardware issues.
are there any instructions on updating grub from a live boot?
Hello @splace and welcome to 
!
Could you try to explain more precisely what exactly caused the issue? What version was your last successful booting deployment and what was the version you rollback to?
Did you by any chance roll back from F42 or rawhide to F41? Was it an actual rpm-ostree rollback or was it a rebase/deploy?
Backwards rollbacks between major versions could cause such problems.
The “no duplicate entries” indicates the migration process to blscfg
If you didnt do that yourself, maybe it was done automatically and broke things…
I personally use that on all my systems without issues
I believe the change, making duplicate entries to go away, is unrelated to the actual issue at hand. I’m currently also facing the problem that my system is not booting.
At the moment I have 2 deployments on my system:
Rawhide 20250224.n.0Rawhide 20250220.n.0I did use for the past few days the latter of the deployment but as of now it does not boot. Upon booting I get a kernel panic with the message:
Attempted to kill init! exitcode=0x0000000b
When booting the former of the entries I also get a kernel panic but with a different message:
VFS: Unable to mount root fs on unknown-block(0,0)
All updates have been done in the classic rpm-ostree upgrade way. I haven’t been playing around with initramfs, GRUB or anything else. After the last update I just shutdown the laptop to have it boot into a kernel panic this morning. I didn’t see any error messages in the output of rpm-ostree upgrade.
Me too, but I’m not entirely sure and the Atomic Desktops maintainers should know better what causes these issues.
If F42, which is not even officially available as a beta, can be arguably considered somewhat stable, that is probably not the case with Rawhide, so some instability is expected.
As I already mentioned in other topics, If you decide to rebase, make sure to pin your current deployment, so you don’t accidentally lose it (by default, only the two most recent deployments are kept). This should be done if you are trying a new, even considered stable, version.
I booted up a Live CD and started looking around /boot/grub2/ and I see that grub.cfg was last changed on 20250217 which is older than the 2 deployment I have on my machine. So, my guess is that rpm-ostree failed to do update the config properly on upgrade.
Now I wonder, what is the right way to fix it.
Me too, but I’m not entirely sure and the Atomic Desktops maintainers should know better what causes these issues.
Myself, I applied these changes months ago and haven’t any problems.
If F42, which is not even officially available as a beta, can be arguably considered somewhat stable, that is probably not the case with Rawhide, so some instability is expected.
As I already mentioned in other topics, If you decide to rebase, make sure to pin your current deployment, so you don’t accidentally lose it (by default, only the two most recent deployments are kept). This should be done if you are trying a new, even considered stable, version.
That’s a wise thing to live by that I, of course, failed to do in my very case. I got too used to Silverblue being quite stable that I did not expect a failure on the boot level which is much more difficult to recover from.
In the next steps, could we focus on resolving the issue for us who are stuck with faulty rawhide images? I believe we all would like to avoid having to reinstall our systems as that is a major inconvenience. Thank you!
Is it correct that you managed to boot into any of the two deployments (20250224.n.0 and 20250220.n.0) before, but you cannot do now, with no rpm-ostree upgrade after the last successful boot?
Or was there actually an upgrade (maybe performed by GNOME Software automatically, if not manually with rpm-ostree upgrade), which doesn’t appear in the grub menu?
I did manage to boot into the earlier deployment BEFORE performing an upgrade to the later deployment. My suspicion is that the GRUB entry kept on pointing to my previous 20250217.n.0 deployment which has been removed upon the successful upgrade.
Actually my question was if you have ever managed to boot into 20250224.n.0? What about 20250220.n.0?
Apologies for being unclear.
Last night I upgraded from 20250220.n.0 to 20250224.n.0. I was booted in the former. At that point I had a previous deployment present → 20250217.n.0 (exact date is a guess at this point since it is gone). I could never boot into 20250224.n.0 and now I cannot boot into 20250220.n.0 anymore.
In that case a pinned deployment wouldn’t have helped, as the last deployment seems to have affected the boot config. Would you have a backup of the /boot and /boot/efi partitions by any chance, so that you can perform a comparison?
Backup of the partitions from before the upgrade? Sadly, no.
Also, I should not this as it could be relevant, the root filesystem (not the /boot or /boot/efi partitions) are encrypted using LUKS2.
You could install Silverblue in a VM, and then rebase to rawhide, with and without encrypted root partitions, and check if there is a difference. It would also make sense to check for file changes in /boot and /boot/efi between the two deployments (with and without issues). Afterwards you might report the issue to the developers.
I would only be able to test this later this week, so it might not be helpful.
As as side note, I really recommend backing up the boot partitions, given their small size, and the fact that it’s there where a system might fail on boot (given that for the rest of the system one usually has a previous functional deployment).
I’ll try that with the VM and see if it is possible to reproduce.
In the meantime, any idea on how I could make the system boot?
As as side note, I really recommend backing up the boot partitions, given their small size, and the fact that it’s there where a system might fail on boot (given that for the rest of the system one usually has a previous functional deployment).
I’ll keep that in mind in the future.
seems similar to @harrymichal situation
i was running Rawhide 20250116.n.0 pinned, updated to …0222.n.0, and gnome failed to start, so i did rollback, as i have previously, and here i am unable to boot.
the previous deployment is now top of the grub list, so rollback did something.
and everything in boot part was modified at the time of the update/rollback…
I have rebased to Rawhide on one of my Silverblue VMs, which deployed version 20250225.n.0. Unfortunately rolling back to 20250224.n.0 didn’t work for some reason, so I couldn’t tell if that specific deployment has issues.
You could boot into a live image, mount the system partitions and post here the contents of /boot/grub2/grub.cfg and /boot/efi/EFI/fedora/grub.cfg as preformatted text) (though I feel it’s not these files where the issue lies). Please also post the output of cat /boot/loader/entries/ostree-2.conf.
Do you also have a LUKS-encrypted root partition?
