Description of problem: After running a dnf system upgrade per instructions on https://fedoraproject.org/wiki/DNF_system_upgrade#How_do_I_use_it.3F, my system now no longer works and only can boot up into emergency mode. Upon further inspection, I can see that, after booting-up in emergency mode, under /sysroot/usr/lib, there is a broken symlink to ./os.release.d/os-release-fedora. There is nothing at ./os.release.d/os-release-fedora. There is not even a os.release.d directory at all. When removing "quiet rhgb" from the GRUB boot line, I can see the last line output of the boot process is "[FAILED] Failed to start Switch Root". When I run `systemctl status initrd-switch-root.service`, I can see: "Failed to switch root: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing". Apologies for any typos as I had to type all those messages out, now way to copy them over.
Having the exact same problem. Could only get the system to boot by renaming os-release and creating an empty os-release file. But now many other things don't work. Currently searching for the os.release.d folder.
Hi, I am having exactly the same problem with 2 different PC, that both use bcache. I found out that the problem is linked to fsck inside the initramfs. fsck considers that the root filesystem is corrupted, saying that the clean flag is set in the superblock, but the journal contains data. Running fsck manually gives a lot of errors I was able to boot using an initramfs generated under fedora 29, re-fsck and start. If I reboot, being sure that the fs is clean, fsck release 30 (initramfs) find errors that are not existing. I suspect it is a bug of the new fsck on bcache devices. This bug is critical, it prevents to migrate to fedora 30 !!!
If you use bcache, take a look on https://bugzilla.redhat.com/show_bug.cgi?id=1708315
For me this was caused by the FAQ-mentioned problem with a conflict in fedora-release-* packages. Unfortunately I did not see this conflict when I did the pre-system-upgrade dnf upgrade --refresh (perhaps the suggestion should be dnf upgrade --refresh --best --allowerasing?), so I only noticed it as the result of the dnf system-upgrade reboot (or perhaps --best --allowerasing arguments could be added here?). I was able to fix the problem as follows: 1) At the point where the Switch Root fails (and you see the message about it generating a .txt log file), hit the process with a SIGQUIT (CNTRL-\). NB: Using SIGQUIT (CNTRL-C) will simply result in the a repeat of the log-generation message; it has to be SIGQUIT. I generally hit it twice, but that might have just been my own impatience; one SIGQUIT and moment's wait probably does the trick. This will drop you into the rescue shell. 2) chroot /sysroot 3) mkdir -p /usr/lib/os.release.d # I'm not sure I had to do this, but just in case. The -p makes it work either way 4) cat > /usr/lib/os.release.d/os-release-fedora <<EOF NAME=Fedora VERSION="30 (Workstation Edition)" ID=fedora VERSION_ID=30 EOF 5) reboot This apparently gave the system enough information for the Switch Root systemctl service to run successfully. Once the machine was up, I was then able to fix the fedora-release conflicts with dnf upgrade --best --allowerasing. NB: once you have hit the boot process with the SIGQUIT, you can then run the systemctl status which the boot process mentions (and some of the comments above mention).
This may be related or even duplicate of bz1710543. Was there any fedora-release-* package removed in the upgrade transaction? (It could have been removed by using --allowerasing for example, because in F30 it is not possible to have multiple fedora-release-* packages at the same time)
I believe that this is a duplicate of 1710543 *** This bug has been marked as a duplicate of bug 1710543 ***
(In reply to amatej from comment #5) > This may be related or even duplicate of bz1710543. Was there any > fedora-release-* package removed in the upgrade transaction? (It could have > been removed by using --allowerasing for example, because in F30 it is not > possible to have multiple fedora-release-* packages at the same time) Sorry for the late reply, but yes, bz1710543 seems to have captured the issue I was having. I was able to overcome this, perhaps by continuing the upgrade after the fix was published. I don't remember the exact circumstances.