I am dual boot system with windows 10, fedora 41. I have a kernel panic issue, where it says “VFS: Unable to mount root fs on unkown-block(0,0)”.
I have only one option to use grub to get back to my fedora.
suggest any commands to download or update the kernel from grub menu or
method to download a kernel .img file and send it to fedora from windows 10 .
or does using the live installation media helpful, if so can i know the steps to perform that task.
any suggestions are greatly helpful
Attaching necessary screenshots to understand the problem and my system drives.
When an update is requested that contains a kernel update, Fedora does a few things:
It will determine if adding this kernel and associated /boot/loader entry will increase the kernel count to more than three excluding the rescue-kernel).
If that count is three, it will delete the oldest (excluding the rescue-kernel) and do the same for the /boot/loader entries.
It will also update /boot/grub2/grubenv so that it references the latest /boot/loader entry.
It is my opinion that these steps have been implemented to assist in times when all of the pieces required to boot the latest kernel are not functioning as expected. This condition could be caused by hardware issues, a bad download of updates or inexact fat fingering.
Sometimes it may be more expedient to use an older kernel that works with your environment than to fiddle with a newer one that does not.
There are ways to patch your system that come with NO guarantees but the fastest way to repair your system ONCE follows:
That was a bad idea because now you are stuck with one kernel that doesn’t boot.
You can boot from Live Media, chroot into system and update or install other kernels. Or you reinstall.
I have fedora 41. After running sudo dnf update fedora installed some new kernel. After booting into the new kernel. I have deleted the the previous kernels
But now I can’t able to boot into the kernel andy grub menu does not show initramfs rescue file.
I’m afraid to say that you’ll need reinstall the fedora. The reason is because you don’t have any kernel, at least not damaged, in your Fedora system. So you can’t boot the system.
As mentioned, you seem to not have a bootable kernel.
The image seems to show that you may have manually removed some kernel files, or somehow the boot loader is not working properly.
My suggestion
boot to the live image then open a terminal window and perform the recovery. The recovery process has been posted many times but I will repeat it for you.
Enable the network before doing anything else since it will be needed.
everything from this point on is in a terminal window.
su since everything from this point on will require root privileges
lsblk -f to identify the partition containing the root file system for fedora.
mount <the root file system partition> /mnt
for F in sys proc run dev sys/firmware/efi/efivars ; do mount -o bind /$F /mnt/$F ; done whici will mount all the necessary extra bits into the file system you mounted in step 4
chroot /mnt
mount -a to mount all the remaining partitions (/boot, /boot/efi, and /home)
now to finish the recovery. dnf update will upgrade all the packages and install the latest kernel (at present 6.12.11)
Once the upgrade completes wait a few minutes for processes running in the background to complete, then exit to leave the chroot environment and reboot.
Manually deleting kernels is almost always a bad idea.
Fedora by default keeps the last 3 installed kernels plus the rescue kernel. If there are already 3 kernels installed the oldest one not used for booting is the one removed when a new one is installed. The space used is minimal and having known good kernels to use if needed is good security.
The idea is that the kernels installed immediately after a kernel update are:
the one currently booted
The next oldest
the new one being installed that has not yet been booted and tested.
Having this ensures that at least one of the 3 should always be bootable.
If you deleted kernels in any way except by using a dnf or rpm command the rpm database will probably be corrupted as well.
If you properly mounted the root file system in step 4 then step 5 would work.
After running step 4 do ls /mnt and see what is shown. It will reveal whether you mounted the proper file system since the sys, dev, run, & proc directories will be shown by the ls command.
If you selected the wrong file system then find and mount the proper one before attempting step 5 again.
However, after looking at what you show with the mount command it appears you mounted the btrfs volume and not the root subvolume. If so then ls /mnt should reveal the root and home directories.
This means the root file system will be at /mnt/root instead of /mnt
Alter step 5 to read
for F in sys proc run dev sys/firmware/efi/efivars ; do mount -o bind /$F /mnt/root/$F ; done
and alter step 6 to read chroot /mnt/root
Everything else should work as intended.
