Hide Forgot
Description of problem: After choosing menu option 1, followed by which subvolume to use for root, the page is filled with rows of ================== and there's no recovery, and the resulting system is not ready to be chrooted, not everything is properly assembled. Version-Release number of selected component (if applicable): Fedora-Workstation-netinst-x86_64-24-20160419.n.0.iso How reproducible: Always on Btrfs. Steps to Reproduce: 1. Root fs on Btrfs 2. Boot netinstall 3. Choose option 1 to continue 4. I run into bug 1187465, where two subvolumes have identical names in the listing, but I just pick the default 5. screen is filled with =========================== Actual results: Runaway program. Expected results: Should properly assemble things and then let me know it's ready to be chrooted. Additional info: The program log, it's somehow confused itself on how many times the same thing is mounted at /mnt/sysimage, like one of the umounts is missing. 'grep mount | program.log' makes it a bit easier to sort through. I'm confused by the repeats of mounting some of the subvolumes, starting at 00:26:04,616 each subvolume is mounted the umounted twice. But the real problem is this line: 00:26:33,295 INFO program: Running... mount -t btrfs -o subvolid=5 /dev/sda5 /mnt/sysimage There is no subsequent umount, it also uses subvolid=5 rather than the proper subvolume which I'd expect from fstab to be used by default but I'm uncertain of the logic, and that might be related to bug 1187465. After this it continues with bind mounts but this does this again 00:26:39,863 INFO program: Running... mount -t btrfs -o subvolid=5 /dev/sda5 /mnt/sysimage And that's where we get the failure because that's already mounted in that same mount point. 00:26:39,885 INFO program: b'mount: /dev/sda5 is already mounted or /mnt/sysimage busy' 00:26:39,885 INFO program: b' /dev/sda5 is already mounted on /mnt/sysimage' 00:26:39,893 INFO program: Running... mount -t btrfs -o subvolid=5 /dev/sda5 /mnt/sysimage So now it loops indefinitely. I know that inst.rescue did work previously with Btrfs despite bug 1187465, so there might be a regression here induced by the fix for bug 1306808, but that's speculation.
Created attachment 1149261 [details] program.log
Created attachment 1149262 [details] storage.log
Created attachment 1149263 [details] btrfs sub list -t
anaconda 24.13.3-1 python3-blivet-1.19-1.fc24.noarch
Bad bug report. Works on a clean installation, and one with snapshots. Bug 1187465 is still true, but there is no regression. The problem is due to a stale /etc/fstab, where subvol= was invalid. The system continued to boot despite this because boot param rootflags= had correct information.