I posted about this a while back and when no one replied I just decided to wait a little bit before sending the question again.
Hey guys, I’ve updated my computer 2 times as of now and both times after updating I have gotten a failure with the switch root. The first time this happened (updating to 5.13.7), I had to keep using 5.13.5 and then one day it had just happened to boot onto the new kernel. I had also tried using the terminal upgrade and the same issue occurred. As of now, I tried to upgrade my kernel to 5.13.9 and everything turned out successful except for the grub boot into it where it once again failed at the switch root. Why does this happen? What do I need to do? Is there a way to fix this so that in the future I won’t have to deal with this occurring every single time I update? I’ve tried looking up solutions but I’m still not too sure what to do, and I’ve seen other people with the same problem but I’m not sure how they turned out. I just kinda need some help with my specific situation
I should also mention that I have updated my laptop twice since then and now I only have one working grub entry (surprisingly, still 5.13.7) and I’m scared to update again in fear of losing this last working kernel version.
fedora does not remove the currently running kernel so as long as you are booted to that kernel when you update it will remain.
With that said, what version of fedora are you using? Doing an update of fedora 34 today will install kernel 5.14.10. I am not sure what the last kernel version on fedora 33 is, but 33 goes EOL about mid-december or before (~30 days after the final release of fedora 35)
I’m on Fedora 34, kernel 5.13.7 at the moment. I have updated twice to higher kernels (i think 5.14.x and 5.13.9 but that doesn’t really matter) but both of them have had a switch root issue which has been posted on other bugzilla forums, reddit, etc. This one from what I can tell is the most similar to mine, but I can’t get the issue to fix and I’m not sure what to do. It appears that this issue has been ongoing for quite some time now.
My strong suggestion, and likely fix, is to (while booted to the 5.13.7 kernel) do a full “sudo dnf upgrade”. When that is done see if the system boots properly with the new 5.14 kernel.
Grub has also seen several updates, and since grub manages the actual boot the problem does not seem likely to still be hanging after more than a year and half since the article you referenced was put out there. VERY few posts on that issues have shown up.
There have been a lot of changes in the kernel and in other things all across the system so it seems likely your issue is solved but the reluctance to take a chance has prevented investigation.
Sorry for taking so long to get back to you. I know very few posts have shown up for this issue, but the most recent one that I have seen was about 4 months ago, which I’m pretty sure was F34 at the time. I’ve seen this go all the way back to 2015 if I’m not mistaken. Like you said, I understand that a reluctance of upgrading is a scary thing, but did try to sudo DNF upgrade at one point in time after upgrading via gnome software and had the same fail to switch root issue. The last time I tried updating was not too long ago, and that was to 5.14.9
I decided to take a leap of faith and sudo dnf upgrade. I deleted one grub entry just in case it decided to fail to switch root once again on the new kernel, and surely enough it did. I upgraded to 5.14.11-200.fc34, but the same issue persists. I’m not sure what I need to do to fix the issue. I should also mention that the kernel that does work, 5.13.7, was at one point a broken kernel with the same issue. It just randomly decided to work one day for me. Iirc, it was this kernel, if not it was another (but the point still stands)
For future reference, here’s the official procedure for an upgrade: DNF System Upgrade.
You can remove old kernels with the following code. Be sure to boot into the latest kernel before running the command.
#!/usr/bin/env bash
old_kernels=($(dnf repoquery --installonly --latest-limit=-1 -q))
if [ "${#old_kernels[@]}" -eq 0 ]; then
echo "No old kernels found"
exit 0
fi
if ! dnf -y remove "${old_kernels[@]}"; then
echo "Failed to remove old kernels"
exit 1
fi
echo "Removed old kernels"
exit 0
FYI
It is not necessary to run this script to delete old kernels.
By default dnf retains only 3 kernel versions, the newest and 2 older ones. Each kernel update removes the oldest that is not currently running leaving only 3 installed.
Also FYI
The OP has never shown any of the info he sees on screen, just complains that the kernel update fails with the switch root error.
I cannot fathom that problem as in over 25 years using RedHat & Fedora I have never seen a similar issue. The updates always work.
Without specific data from the OP it is impossible to identify what may be going wrong or why. He does not respond with details even when requested, only generic info.
I did not realize that there was such a detailed way to upgrade. I typically just use the GUI, but when it the first fail to switch root occurred, I decided to upgrade again using sudo dnf upgrade
I came to look back at this thread to see if I missed something or if I could add anything. Do you have any idea of what I could give you guys to make it less generic?
You have to remember I’m not a 25 year veteran. I’m no more than 6 months into daily driving linux and I still barely know how to work with grub and systemd. All these tutorials I’ve seen and prior solutions haven’t worked for me, and I don’t know why.
While there may be a hardware issue causing the problem, the simplest way to do a (usually) reliable update is to use the
sudo dnf update --refresh
command. You also can add the options --allowerasing or --best or --skip-broken so it can continue and try to fix any conflicts on its own. Any or all those can be used at the same time.
If it continues to have the problem with the /sysroot issue then I would suspect that something that was done by the way you first did the upgrade may have created the issue. If that is the case then the best fix could be to do a backup of the data in /home and do a complete new reinstall then restore your backup data.
The fact that it does not properly load the vmlinuz image into /sysroot implies dracut did not properly complete and that the vmlinuz image is not correctly formed or is missing. Someone else may be able to provide guidance on how to recreate the vmlinuz image with dracut as I have never encountered a need to do so and have no experience in that.
Remember that with fedora the recommended path to do software installs or upgrades is by using the command line with the dnf command above or by using the gnome software tool already installed.
Dnf is designed to identify any software for which updates are available and makes sure that the dependencies required are also handled properly. Dnf also handles properly installing new packages and their dependencies.
The best way for us to see what is happening during the update would be for you to run the update command with output to files so we can see the responses for everything and possibly help identify the problem points.
Then if the /sysroot error repeats attach the upgrade.log and upgrade.err.log to your post telling us what happened with the reboot so we can see what actually happened during the update.
Another possible step toward fixing this is to try reinstalling certain packages.
Those commands will reinstall most of the pieces that are involved in the actual boot and could totally fix the problem. Reinstalling the kernel last will ensure that a new vmlinuz image and a new grub.cfg file is created.
Sorry for the late response!! But I think that I have just figured out the issue after doing two sucessful fixes to my kernels. I installed the grub customizer gui application (this was months ago before I ever had these issues) in order to be able to add some parameters to fix some bugs that my laptop was specifically having with some drivers. Had I known that there was a grubby command or a config file before I had done this install, I would not have installed this application.
Anyways, one day I decided to open up the application to see if there was something wrong in here or that I could potentially change, and when I tried to close the application, it told me that my save was out of date (I’m not sure for what specifically, but when I preform a future update I will check to see what it told me so that if somebody else comes across this issue, this thread will be here) (I’m pretty sure the issue was my kernels saved in my grub boot menu). Once I saved these changes it was recommending, I rebooted and my grub was no longer delayed in response (a bug that a couple of people have had), and most importantly my fail to switch root issue was no longer apparent! I have tested this twice, with the first time fixing all of my kernels in grub and my second time allowing me to fix my fail to switch root error right after installing Fedora 35!
Does this answer any of your questions or speculations of what you were thinking the root of the problem was? I’m thinking that maybe your reinstall of grub was what would’ve potentially fixed the issue. I’m also thinking that you’ve probably never encountered this issue partially because you have never installed the GUI grub-customizer. With your 25 years of experience with RedHat, I wouldn’t expect you to!