Created attachment 1123268 [details]
File: anaconda-tb

Created attachment 1123269 [details]
File: anaconda.log

Created attachment 1123270 [details]
File: environ

Created attachment 1123271 [details]
File: journalctl

Created attachment 1123272 [details]
File: lsblk_output

Created attachment 1123273 [details]
File: nmcli_dev_list

Created attachment 1123274 [details]
File: os_info

Created attachment 1123275 [details]
File: program.log

Created attachment 1123276 [details]
File: storage.log

Created attachment 1123277 [details]
File: ifcfg.log

11:29:08,880 INFO program: Running... mount -t btrfs -o subvolid=5,subvol=root /dev/sda3 /mnt/sysimage

It shouldn't use both subvolid and subvol mount options at the same time.

Feb 11 13:29:08 localhost kernel: BTRFS: subvol 'root' does not match subvolid 5

And also the logic is wrong because it's mounting two different subvolumes.

Probable dup, bug 1253481.

Proposed as a Blocker for 24-beta by Fedora user chrismurphy using the blocker tracking app because:

 "When using the custom partitioning flow, the installer must be able to: Create mount points backed... btrfs volumes. Correctly interpret, and modify .... btrfs volumes."

The direct problem is that anaconda is using an invalid mount command, which fails and then the installer crashes. However it doesn't always use the wrong mount command, it seems to only happen with a totally empty Btrfs volume, e.g. one that's been formatted outside of the installer (even when using mkfs defaults, same as the installer). If it contains subvolumes, such as from previously installed systems, the problem doesn't happen.

Looks like it snuck through testing in Fedora 23, and users are hitting it.

Discussed at 2016-02-15 blocker review meeting: [1]. 

We decided to delay the decision: this seems a strong candidate as there are many people hitting the 'potential dupe' bug, but reporter did not explain precisely what he actually did, we need that clarified to make a decision

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-15/f24-blocker-review.2016-02-15-17.00.html

There's more than one way to hit this but a simple version is:
1. New qcow2
2. fdisk to create a 500M and "remainder" partitions; 2 partitions.
3. mkfs.btrfs /dev/vda2  ## does not matter what the options are, including defaults
4. Custom partitioning
5. Change partition scheme popup to btrfs
6. Click under Unknown, click sda1, check reformat, select ext4, mount point set to /boot
7. + to add mount point for / and optionally anything else.

Oops.
8. Click Done, Done (due to no swap in the example), Begin Installation.
Crash.

Two clues for what's going on:
1. anaconda-blivet have used 'subvolid=5,subvol=root' mount option when starting with empty btrfs filesystems the installer did not create, for some time. It goes back to at least Fedora 21. 
2. What's changed is since kernel 4.2, conflicts in those options aren't permitted anymore. [1] The mount failure aggravates the installer into crashing.

But I'm uncertain why installer created fs causes subvolid=5 to be supressed. Maybe the reuse empty fs is sufficiently rare that it's just a stale code path.

This is loosely similar to bug 1198437 where fstab btrfs entries always had both mount options, which were also in conflict in the same way as in this bug. Fortunately that bug was fixed, or users upgrading kernels would have had boot failures.

[1]
https://lkml.org/lkml/2015/4/9/908

This includes the kernel patch and discussion on the change. Gist is subvolid and subvol together are OK if they point to the same subvolume. But if they conflict, better to fail to mount because what the user expects is ambiguous. Using subvolid=5, in particular, always fails with subvol=<name> because id=5 points to the unnamed default subvolume created at mkfs time that also can't be deleted.

Similar problem has been detected:

I tried to install rawhide (F24 2016-02-20) to subvolumes under an existing F23 Btrfs partition.

For example, F23's opt subvolume is "opt", while rawhide's opt subvolume was supposed to be "opt00". The "00" suffix was added automatically by Anaconda.

Other details:
UEFI mode
Reusing the F23 ext4 /home LV.
Shrunk the Windows NTFS partition in order to create a new /boot partition.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-rawhide-x86_64 quiet
dnf.rpm.log:    Feb 21 09:11:13 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.5.0-0.rc4.git3.1.fc24.x86_64
package:        anaconda-24.13-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        rawhide

OK anytime I reuse an existing Btrfs volume with either F23 or F24 installers, I hit this. Only if the installer creates the fs does it NOT try to mount with subvolid=5, and thus the problem doesn't happen.

Discussed at 2016-02-22 blocker review meeting: [1]. 

This bug was accepted as Beta blocker: this seems to be a clear violation of "When using the custom partitioning flow, the installer must be able to: ... Assign mount points to existing storage volumes" , where an earlier section of the criterion makes clear that btrfs "storage volumes" are in the set expected to be supported

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-22/f24-blocker-review.2016-02-22-17.00.html

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Similar problem has been detected:

Clicked "begin installation", and the error message came up soon after starting the installation.

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-24_A-7 rd.live.image rd.live.check quiet
hashmarkername: anaconda
kernel:         4.5.0-0.rc7.git0.2.fc24.x86_64
other involved packages: python3-blivet-1.19-1.fc24.noarch, system-python-libs-3.5.1-7.fc24.x86_64
package:        anaconda-core-24.13-1.fc24.x86_64
packaging.log:  
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 24 (Twenty Four)
version:        24

Was using custom partitioning. Created subvolumes for / and /home on existing btrfs partition /dev/sda2, /boot on new partition /dev/sda4, and /boot/efi on existing partition /dev/sda1.

*** Bug 1253481 has been marked as a duplicate of this bug. ***

Created attachment 1145233 [details]
patch to filter monut options (from Ivan Sizov)

Ivan Sizov posted this patch in the dupe, I'm re-attaching it here for convenience. All credit to him.

Mmmmmm, monuts - the famous cross between the madeleine and the donut...

Updates.img for Fedora 24: https://vtrefny.fedorapeople.org/img/subvol.img

Another user experienced a similar problem:

Trying to install Fedora... crash after selecting "Begin Installation"
(same happened when trying to install Fedora 24 alpha, so I'm back to Fedora 23... same issue now?!)

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-23-10 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
other involved packages: python3-blivet-1.12.8-1.fc23.noarch, python3-libs-3.4.3-5.fc23.x86_64
package:        anaconda-core-23.19.10-1.fc23.x86_64
packaging.log:  
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 23 (Twenty Three)
version:        23

Problem doesn't happen with Fedora-Workstation-Live-x86_64-24-20160411.n.1.iso + https://vtrefny.fedorapeople.org/img/subvol.img applied.

python-blivet-1.20.0-1.fc24 anaconda-24.13.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-45ca29d07c

anaconda-24.13.4-1.fc24, python-blivet-1.20.0-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-45ca29d07c

anaconda-24.13.4-1.fc24, python-blivet-1.20.0-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Another user experienced a similar problem:

Installing in existing LVM-partitioned disk on some btrfs volume

cmdline:        /usr/bin/python3  /usr/sbin/anaconda --kickstart /root/2016e1,ks.cfg
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Xfce-x86_64-23-10 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
dnf.rpm.log:    May 16 08:22:52 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
other involved packages: python3-libs-3.4.3-5.fc23.x86_64, python3-blivet-1.12.8-1.fc23.noarch
package:        anaconda-core-23.19.10-1.fc23.x86_64
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 23 (Twenty Three)
version:        23

Another user experienced a similar problem:

Installing Fedora 23 on multiple btrfs-formatted logical volumes.

cmdline:        /usr/bin/python3  /usr/sbin/anaconda --kickstart /root/2016e1,ks.cfg
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Xfce-x86_64-23-10 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
other involved packages: python3-libs-3.4.3-5.fc23.x86_64, python3-blivet-1.12.8-1.fc23.noarch
package:        anaconda-core-23.19.10-1.fc23.x86_64
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 23 (Twenty Three)
version:        23