While reviewing the status of F39 Changes, I tested https://fedoraproject.org/wiki/Changes/cleanup_systemd_install and found it seems to be broken. I did an install from Fedora-Everything-netinst-x86_64-39-20230910.n.0.iso (the most recent one I have handy) to a UEFI non-Secure-Boot VM with inst.sdboot. The install completes successfully and the installed system boots to a clearly-not-grub2 bootloader, but when I actually try to boot Fedora from it, I'm dumped at the rescue prompt. The journal shows: Failed to switch root: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing Looking under /sysroot , I see that the installed system *is* there, but it's nested. There's a /sysroot/root , and *that* is the actual installed system root. So you'd have to do `chroot /sysroot/root` to be at the root of the installed system. When I boot a normal grub2 install, the installed system root is directly at /sysroot , so you would do `chroot /sysroot` to be at the root of the installed system. Presumably this is how it should be with a systemd-boot install too. I honestly have no idea which component is responsible for this, so filing against sdubby just since I know that will get it to the attention of an appropriate person. Reproducible: Always Steps to Reproduce: 1. Install Fedora 39 from Everything netinst with inst.sdboot 2. Try and boot the installed system Actual Results: You wind up at the dracut emergency shell Expected Results: You should wind up in the installed system
Checked and confirmed this is the same with the most recent nightly (20230920.n.0, as today's compose failed).
Duping becasue this is the symptoms of anaconda not putting the btrfs specific args in the arg list like it does for other filesystems, rather depending on the final bootloader to fix it up and systemd of course doesn't do that. Once the fix lands, reopen if the problem persists. *** This bug has been marked as a duplicate of bug 2237327 ***