Fedora 32 switch root won't start after upgrade


I just upgraded from Fedora 30 to Fedora 32 directly using the commands specified in the upgrading guide. Note that I used --allowerasing.

When I try to reboot using any of my Fedora releases (I am using a dual boot with Windows Boot Manager on a laptop), I get the following error:

[FAILED] Failed to start Switch Root.

When running systemctl status initrd-switch-root.service I get:

Failed to switch root: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing.

/sysroot is indeed an empty folder, link to os-release is missing, but I still have /usr/lib/os-release with correct content, it seems.

Following some solutions I found online, I tried:

mkdir -p /sysroot/etc
cp /usr/lib/os-release /sysroot/etc/

But on reboot, I keep getting same error.

Any idea on how to solve this? It would be an immense help, thanks!

You might find inspiration by reading 1492208 – Failed to switch root: Specified switch root path /sysroot does not seem to be an OS tree. os-release file is missing

Myself, I don’t understand enough to suggest you to try what is there… and you should realize it was an other time/product.

Hi tzee,

any resolution ?
I am facing exactly the same problem after upgrading F31 => F32 including “–allowerasing”.
Same sysroot error , and in emergency console the “/sysroot” is completely empty. Even if I create some folders/files in there, after reboot it is empty again
Thanks !!

@gkoenig No, no resolution yet, I’m still looking into it. I could just reinstall the whole of Fedora after backing up but is not really an acceptable solution for me right now…

@pauld Thanks for the link, I actually already tried that. But when I try mount -o remount,rw /sysroot I get mount point not mounted or bad option. Not sure what to do with that I must say.

The following comment seems to me to have some wisdom attached to it:

same here, upgrading from f31 to f32.
it seams strange, that initrd-mount-sysroot.service doesn’t fail, bc ofc there is no sysroot/etc/os-release, bc std root is not mounted

fsck’d all partitions, just in case
no luck
fedora-32-switch-root-wont-start-after-upgrade-journal.txt - Pastebin.com ← journalctl -b after fsck and reboot

Here too…
And I also encrypted my home folder (not with LUKS) and don’t know how to acces the my files now from a live stick :confused:
I’m having a LUKS encrypted LVM and inside that the root partition and my home partition. But since someone else might use this computer too, I also set the flag to encrypt my home directory as I created it with the KDE Plasma user dialog.
Has someone any ideas how I can access them again?

Maybe I’m trying out sliverblue the next time ?_?

there are instructions somewhere in the internet on how to decrypt and mount encrypted lvm partitions from the commandline.

But I have a simpler solution.
Live-Stick with Peppermint OS
run gnome-disks
there you can easily decrypt your partition in gui.


sudo su
cd /
mount /dev/mapper/fedora*root /mnt/
for d in dev sys tmp proc ; do { mount --rbind /$d /mnt/$d ; mount --make-rslave /mnt/$d ; } ; done
chroot /mnt/ /bin/bash
. /etc/profile
mount -a

now at this point you are running your unbootable system from under another system, nearly like after normal boot, and you can do whatever backups you want.

you may mount some external harddrive lets say at /mnt/ and do

rsync -aAXv --exclude=lost+found /home /mnt/

to verify that files are copied correctly you may additionally run

rsync -aAXcv --exclude=lost+found /home/mnt/

If you need something to install or access the internet, then after you connect Peppermintos to the internet, run


in the chrooted terminal


Found this thread with a similar problem and an encrypted system, so maybe it helps.

@pauld Thanks for the suggestion, I tried fsck my partitions and they all return “clean”.
As for the journalctl -b I might be missing something obvious, but if I generate the file on the Live media won’t it return the boot journal of the Live Fedora version, and not the broken one? If I generate the file in emergency mode, will it be accessible via Live Media so I can copy paste it?

What you have tried to do other did it this way (in the time with success) [in the emergency shell]:

mount - o remount,rw /sysroot
rm -rf /sysroot/etc/os-release
cp /usr/lib/os-release /sysroot/etc
My guess is that your case is different… you would have to do mkdir -p /sysroot/etc before doing the cp… because /sysroot/etc does not exist… because /sysroot is empty… which I guess is a problem (seems /sysroot is what will become your / filesystem I think… after a chroot there… at least this is my feeling)

I took a look at your patebin… one thing that I remarked is:

Apr 30 18:16:37 ds.lenovo.dh systemd-gpt-auto-generator[671]: EFI loader partition unknown, exiting.
Apr 30 18:16:37 ds.lenovo.dh systemd-gpt-auto-generator[671]: (The boot loader did not set EFI variable LoaderDevicePartUUID.)

Maybe you are booting in Inherited BIOS mode… where you could boot in UEFI mode.


Apr 30 18:16:37 ds.lenovo.dh systemd[1]: Condition check resulted in dracut pre-mount hook being skipped.

But it could be normal… I have no idea.

Hi there, as you can guess I’ve just tried updating Fedora from 31 to 32 and here I am :frowning_face:

Something I should note is that I had the exact same problem last week when I installed the proprietary nvidia drivers. My system wouldn’t boot and I would get the error “[FAILED] Failed to start Switch Root.”.
I then uninstalled the faulty driver using a live-usb to chroot on the partition where my system is.

Unfortunately I don’t have enough knowledge to relate the two instances of this problem but some of you might.

Now I realized your Grub entry seems very anormal:

Apr 30 18:16:19 ds.lenovo.dh kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.6.7-300.fc32.x86_64

If I compare with something like:

Mar 28 09:12:20 kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.5.11-200.fc31.x86_64 root=/dev/mapper/fedora_localhost–live-root ro resume=/dev/mapper/fedora_localhost–live-swap rd.lvm.lv=fedora_localhost-live/root rd.lvm.lv=fedora_localhost-live/swap rhgb quiet
taken from: journalctl-1 - Pastebin.com (found by Googling)

I begin to ask myself where is your missing part.

[Edit1] Might have a link with the the way we come to use BootLoaderSpec
but I think F30 was already using it. [/Edit1]

This issue could be relevant: 1765297 – System become unbootable (Failed to start Switch Root) after the last upgrade
I’ll try the given suggestions tomorrow.

Hey again, as mentioned before, when I try mount -o remount,rw /sysroot I get mount point not mounted or bad option . Not sure what to do with that I must say.

Now we might have a lead with @deadgnom32 Grub’s issues as I had in the past many issues with Grub on this system, already when I upgraded to Fedora 30, in the past.
Edit: investigating further the issue, I have exactly the same values that @pauld pointed out, with the EFI loader partition unknown and weird Grub entry looking the same.

To also share my journalctl entry so we can see if I have the same issue, can I generate the file from Fedora live media? If I generate the file in emergency mode, will it be accessible via Live Media so I can copy paste it?

@antoine59 I imagine you followed this guide, maybe?

I had issues when upgrading to F30 with nvidia drivers breaking my grub as well and following instructions there did the trick at the time (it was a year ago so I’m a bit blurry on the details). I had to fix my grub at some point.

i also noticed the message about efi,
but it doesn’t throw an error. and i have only efi boot, configured, and the partition is marked as such.

i tried to reinstall everything from under chroot and yet, it looks different.
i will investigate this issue later today.
i have a couple ideas on what may cause this problem.

I updated the system from chroot. and got grub entries fixed.
I reached the graphical login screen, but couldnt login neither on graphical login nor on tty. root or my user. both fail.
ON tty screen gets reloaded, and i land on


again and again

no, you generate the file in rescue shell.
then do

mkdir /d 
blkid # look at where your boot ext4 partition is 
mount /dev/$yourBootPartition /d
cd /d 
journalctl -b > journal.txt

then you have it saved to boot partition

I can confirm I solved my problem following this comment: 1765297 – System become unbootable (Failed to start Switch Root) after the last upgrade
My grubenv didn’t contain the needed arguments to give to the Grub command line.

1 Like