Created attachment 1570778 [details] rdsoreport.txt from boot to normal kernel Description of problem: I used dnf-system upgrade intending to migrate a F29 system to a F30 system. After the 'dnf system-upgrade reboot' command the system successfully rebooted and began the long process of updating everything. When the update finished and the system rebooted it ended up in an initramfs shell My system has the following setup: sda1: /boot ext4 sda2: lvm / ext4 swap sdb1: btrfs volume sdc1: btrfs volume subvolumes /var btrfs /home btrfs From the initramfs I am unable to mount any btrfs volumes. /proc/filesystems does not list btrfs. The grub boot menu did not have a rescue option, so I created a rescue initramfs for the same F30 kernel that was booting. I ended up in the same situation with the rescue intramfs. I also tried the 2 alternate F29 kernel boot options, with the same result. If I boot with the F30 live USB I am able to see and mount all of my partitions, so I don't think there are any problems with the file systems themselves. I can't figure out where in the boot process the problem is. I had a very similar problem when upgrading from F28 to F29. (It's hard to recall exactly since it was a while ago.) After a few days of troubleshooting back then I finally gave up and did a fresh install, which wiped my /var partition. I would like to avoid that this time since I have lots of data on /var now that I would rather not have to slowly restore from backup into a fresh install. The system seems to indicate that it is booting from a suspended session in swap, but I don't know if that is relevant to the problem. Steps to Reproduce: 1. system upgrade reboot 2. end up in initramfs shell with no btrfs support Actual results: An unusable system Expected results: A working, upgraded system Additional info: I have attached the rdsosreport from booting into the initramfs shell. I also have the rdsosreport from the attempt at using a rescue kernel if that is helpful. I can copy things off the system onto a usb drive if needed to help solve the problem and figure out what caused the problem.
I noticed the switchroot problem at the end of the rdsosreport.txt that referred to os-release. After investigation, I remembered that fedora-release-matecompiz was one of the packages that had listed conflicts. I had proceeded with --allowerasing. I mounted and switched into the host filesystem and found that fedora-release-matecompiz was installed on my broken system. A working system had fedora-release-workstation installed. Installing fedora-release-workstation required removing fedora-release-matecompiz. After that, I rebooted and all was fine. Fedora-release-matecompiz was apparently missing some incredibly important file that prevented the switchroot.
Per previous comment moving to fedora-release component. It's most likely a packaging / upgrade path problem rather than a problem with DNF.
*** This bug has been marked as a duplicate of bug 1710543 ***