Bug 1329034

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.