Created attachment 1062801 [details]
File: anaconda-tb

Created attachment 1062802 [details]
File: anaconda.log

Created attachment 1062803 [details]
File: environ

Created attachment 1062804 [details]
File: journalctl

Created attachment 1062805 [details]
File: lsblk_output

Created attachment 1062806 [details]
File: nmcli_dev_list

Created attachment 1062807 [details]
File: os_info

Created attachment 1062808 [details]
File: program.log

Created attachment 1062809 [details]
File: storage.log

Created attachment 1062810 [details]
File: ifcfg.log

Another user experienced a similar problem:

My disk was already set up with LUKS+LVM, so I just told anaconda which logical volumes to use for the root and swap filesystems.  It crashed when installation began.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=(loop)/isolinux/vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-WS-23_B-x86_64 iso-scan/filename=/Fedora-Workstation-netinst-x86_64-23_Beta.iso
hashmarkername: anaconda
kernel:         4.2.0-300.fc23.x86_64
package:        anaconda-23.19.4-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

Another user experienced a similar problem:

I tried to install with LVM-on-LUKS (but anaconda was trying to create ext4-on-LUKS-on-LVM-on-LUKS for some weird reason) and then it crashed.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=(loop)/isolinux/vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-WS-23_B-x86_64 iso-scan/filename=/Fedora-Workstation-netinst-x86_64-23_Beta.iso
hashmarkername: anaconda
kernel:         4.2.0-300.fc23.x86_64
package:        anaconda-23.19.4-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

Another user experienced a similar problem:

I tried to install F23 Beta with LUKS encryption and two LVM volumes, one for the root filesystem and one for swap.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=(loop)/isolinux/vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-WS-23_B-x86_64 iso-scan/filename=/Fedora-Workstation-netinst-x86_64-23_Beta.iso
dnf.rpm.log:    Oct 04 17:57:02 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.2.0-300.fc23.x86_64
package:        anaconda-23.19.4-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

(In reply to Jeff Bastian from comment #13)
> Another user experienced a similar problem:
> 
> I tried to install F23 Beta with LUKS encryption and two LVM volumes, one
> for the root filesystem and one for swap.
> 
> addons:         com_redhat_kdump
> cmdline:        /usr/bin/python3  /sbin/anaconda
> cmdline_file:   BOOT_IMAGE=(loop)/isolinux/vmlinuz initrd=initrd.img
> inst.stage2=hd:LABEL=Fedora-WS-23_B-x86_64
> iso-scan/filename=/Fedora-Workstation-netinst-x86_64-23_Beta.iso
> dnf.rpm.log:    Oct 04 17:57:02 INFO --- logging initialized ---
> hashmarkername: anaconda
> kernel:         4.2.0-300.fc23.x86_64
> package:        anaconda-23.19.4-1
> product:        Fedora
> reason:         blivet.errors.FSError: mount failed: 32
> release:        Cannot get release name.
> version:        23

Please attach the anaconda-tb-* file. It might be worthwhile to open a different bug since the original traceback here is btrfs related not lvm.

I don't have the original anaconda-tb-* file since it was just on the RAM disk, and abrt decided this was a duplicate. :(

I'll see if I can reproduce it.

Ah-hah: I think I may have created my own problem and my issue is likely not-a-bug (or not supported anyway).  I didn't have any USB flash drives or burnable DVDs handy, so I thought I'd be clever and I placed the F23 Beta ISO file in /boot and then added an entry to grub.cfg:

menuentry "Fedora 23 Beta Netinstall Boot ISO" --class fedora {
    set root='hd0,1'
    set isofile="/Fedora-Workstation-netinst-x86_64-23_Beta.iso"
    loopback loop ${isofile}
    linux (loop)/isolinux/vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-WS-23_B-x86_64 iso-scan/filename=${isofile}
    initrd (loop)/isolinux/initrd.img
}


So, of course, when anaconda tried to mount sda1 to /mnt/sysimage/boot, it failed because sda1 was already loopback mounted with this ISO file.

Created attachment 1080100 [details]
anaconda traceback

Now that I realized I was too clever for my own good, I used a real USB flash drive and F23 Beta installed just fine.  Sorry for the noise.

(In reply to kuchiman from comment #0)
> Description of problem:
> Download Fedora-Live-Workstation-x86_64-23_Alfa-2.iso
> Run and set try fedora
> Run LO and close LO
> Run install fedora
> When set root password i get error

Please retry with the current nightly, I can't reproduce this with the Beta.

Another user experienced a similar problem:

failed new install under existing btrfs partition.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=http://192.168.5.204/a/m/sf/dev/x86_64/os/isolinux/vmlinuz inst.ks=http://192.168.5.204/a/ks/fddb6
dnf.rpm.log:    Oct 22 11:14:36 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
package:        anaconda-23.19.7-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

Another user experienced a similar problem:

Failed new install under existing linux btrfs filesystem. 

Procedures for partitioning.

1. select manual partitioning
2. select brtfs partition
3. delete "/" partition
4. recreate "/" partition with size=10gb
5. select and reuse/update existing /home partition 
6. select and reuse/update existing /boot/efi partition
7. select and format/update existing /boot partition
8. select and format/update existing swap partition
9. i selected default workstation install
10. installation proceed but failed once it start to repartitioning the drive


addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=http://192.168.5.204/a/m/sf/dev/x86_64/os/isolinux/vmlinuz inst.ks=http://192.168.5.204/a/ks/fddb5
dnf.rpm.log:    Oct 30 11:35:29 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
package:        anaconda-23.19.10-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

(In reply to eric magaoay from comment #21)
> Another user experienced a similar problem:
> 
> Failed new install under existing linux btrfs filesystem. 
> 
> Procedures for partitioning.
> 
> 1. select manual partitioning
> 2. select brtfs partition
> 3. delete "/" partition
> 4. recreate "/" partition with size=10gb
> 5. select and reuse/update existing /home partition 
> 6. select and reuse/update existing /boot/efi partition
> 7. select and format/update existing /boot partition
> 8. select and format/update existing swap partition
> 9. i selected default workstation install
> 10. installation proceed but failed once it start to repartitioning the drive
> 
> 
> addons:         com_redhat_kdump
> cmdline:        /usr/bin/python3  /sbin/anaconda
> cmdline_file:  
> BOOT_IMAGE=http://192.168.5.204/a/m/sf/dev/x86_64/os/isolinux/vmlinuz
> inst.ks=http://192.168.5.204/a/ks/fddb5
> dnf.rpm.log:    Oct 30 11:35:29 INFO --- logging initialized ---
> hashmarkername: anaconda
> kernel:         4.2.3-300.fc23.x86_64
> package:        anaconda-23.19.10-1
> product:        Fedora
> reason:         blivet.errors.FSError: mount failed: 32
> release:        Cannot get release name.
> version:        23

NOTE: new install works if I delete the entire existing linux brtfs filesystem and recreating new install btrfs partitions. It fails only when I try to save the existing /home and /boot/efi partitions.

Another user experienced a similar problem:

Im doing a clean install. The installer crash at creating swap partition.

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-23-10 ro rd.live.image quiet rhgb
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

Another user experienced a similar problem:

Attempted an installation, swap device is an LVM logical volume.  Appears to have created the swap device, but the installer makes no further progress.

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:UUID=555afdcb-0fc1-4b3a-b646-74b1491a4799 rootfstype=ext4 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

Correction - the last message displayed in the UI seems to indicate that the issue involves creating swap.  The issue is indeed related to mounting the previously-created root file system which is formatted BTRFS.

This system is configured with LVM on a LUKS-encrypted physical volume.  The root file system is a BTRFS subvolume which is located on a BTRFS-formatted LVM logical volume.

The system has other BTRFS-formatted logical volumes for /var, /var/log, /var/log/audit, /var/tmp and /tmp.  These volumes either do not present an issue or the system does not reach the point of attempting to mount them, I'm not sure.

Looks like the root file system is mounted with options 'subvolid=5,subvol=f23-root' in my case.  When I attempt to mount with these options in the terminal, I get an interesting log in dmesg:

  BTRFS: subvol 'f23-root' does not match subvolid 5

The 'btrfs subvolume show' command indicates that the subvolume ID is 257, but the parent volume ID is 5, which is more along the lines of what I'd expect.

Another user experienced a similar problem:

Tried to install fedora 23 workstation with anaconda. Anaconda stalled after I configured disk partitons (set the root "/" partition to a new btrfs subvolume) and started installation process.

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

Another user experienced a similar problem:

I started the installation with the netinstall metod and the installation crashed during the partitioning of the hard disk.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-WS-23-x86_64 quiet
dnf.rpm.log:    Nov 08 20:35:50 INFO --- logging initialized ---
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
package:        anaconda-23.19.10-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

Another user experienced a similar problem:

I started the fedora installation with the live install method and crashed while partitioning the hard disk.

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

(In reply to John F Sullivan from comment #26)
> Looks like the root file system is mounted with options
> 'subvolid=5,subvol=f23-root' in my case.  When I attempt to mount with these
> options in the terminal, I get an interesting log in dmesg:
> 
>   BTRFS: subvol 'f23-root' does not match subvolid 5
> 

My case was the same. Anaconda tried to use subvolid of the parent volume and failed. (The id of the parent volume happens to be 5 too.)

I randomly removed the portion of blivet/devices/btrfs.py: 

          # propagate mount options specified for members via kickstart
          opts = "subvol=%s" % self.name
 -         if self.volume.format.mountopts:
 -             opts = "%s,%s" % (self.volume.format.mountopts, opts)

I did not know what I was doing exactly but it worked. Lucky me.

Another user experienced a similar problem:

Installing from Fedora Live 23.
Anaconda has a crash while entering the root password in the second field to confirm the first password entered.

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

Looks like this code adds the 'subvol' option, then prepends any other mount option before passing it to the mount command.  I would suggest that the problem is the inclusion of 'subvolid=5' in self.volume.format.mountopts when a subvolume is specified, not the inclusion of the previously-specified mount options to the options string.

Though if 'subvolid' is the only other mount option, the removal of these two lines will certainly work around the issue.

(In reply to Takehiko Abe from comment #30)
> I randomly removed the portion of blivet/devices/btrfs.py: 
> 
>           # propagate mount options specified for members via kickstart
>           opts = "subvol=%s" % self.name
>  -         if self.volume.format.mountopts:
>  -             opts = "%s,%s" % (self.volume.format.mountopts, opts)
> 
> I did not know what I was doing exactly but it worked. Lucky me.

Created attachment 1092809 [details]
patch for blivet's btrfs.py

Comment on attachment 1092809 [details]
patch for blivet's btrfs.py

John F Sullivan wrote:
> Though if 'subvolid' is the only other mount option, the removal of these two lines will certainly work around the issue.

I think filtering inherited options for 'subvolid' is better:
  
  # propagate mount options specified for members via kickstart
  opts = "subvol=%s" % self.name
  for option in self.volume.format.mountopts.split(','):
      if option and option.split('=')[0] != 'subvolid':
          opts = "%s,%s" % (option, opts)

I agree this solution is better.  But, wouldn't it be even better still to not pass 'subvolid=5' in the mount options if a subvolume other than the default is used?

(Please keep in mind I'm not a blivet developer - this look is my first into this code.)

Looks like vol_id is defined as a class variable and set to btrfs.MAIN_VOLUME_ID in line 159.  Fascinating since all instances will share this value, and any changes will affect all instances.  I don't see where it's changed, but perhaps it should be defined in the init function instead of in the class definition so I can safely be changed without modifying all BTRFS devices.

(In reply to Brian Lane from comment #19)

Brian - does this bug still need information?  It's been reproduced many times with the GA version of Fedora 23.

I can work around the problem with the Fedora Workstation installer by adding the changes recommended in comment #30 and comment #34, but I can't seem to make the Fedora Server installer correctly function once it encounters this specific issue.

Another user experienced a similar problem:

Existing LUKS-encrypted BTRFS volume with /home and / (root) as subvolumes from Fedora 22 setup.

root deleted and re-created (not able to select Reformat without deleting/recreating)

/home should stay intact.

Once the installer is started, when reaching root-subvolume re-create/format it it crashes.

addons:         com_redhat_kdump
cmdline:        /usr/bin/python3  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-WS-23-x86_64 quiet
hashmarkername: anaconda
kernel:         4.2.3-300.fc23.x86_64
package:        anaconda-23.19.10-1
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Cannot get release name.
version:        23

Another user experienced a similar problem:

1) Launch the installer vía iso from grub2
2) Started the installation
3) After a while it stops of installing

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=(loop)/isolinux/vmlinuz0 iso-scan/filename=/Fedora-Live-KDE-x86_64-23-10.iso root=live:CDLABEL=Fedora-Live-KDE-x86_64-23-10 rootfstype=auto ro rd.live.image rd.live.debug=1 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

I think that error comes from choosing partition when Fedora ISO file resides on as /usr. But I choose *not* to format only create the partition on it. I think it's a bug it should allow to do that.

What do you think?

Sergio Belkib, look at the previous messages and the patch. It's the bug in Blivet.

Another user experienced a similar problem:

Started Fedora installer by having the ISO image on local partition /dev/sda5 and using 'iso-scan/filename' kernel parameter. I chose /dev/sda5 to be the /home partition but not to reformat it.

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/vmlinuz-install.fc23.x86_64 iso-scan/filename=Fedora-Live-Workstation-x86_64-23-10.iso root=live:CDLABEL=Fedora-Live-WS-x86_64-23-10 rootfstype=auto ro rd.live.image quiet rhgb rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=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
packaging.log:  
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 23 (Twenty Three)
version:        23

Another user experienced a similar problem:

Installing F23 workstation onto an SSD that has a previously installed Centos 7 install.  Reusing the /sda1 and /sda2 partitions for /boot/efi and /boot. Ignoring swap on /sda3. (Crashes whether or not I try to reformat swap, and whether or not I even define swap for the install.) Reusing the btrfs file system on /dev/sda4. Remounting the 'home' subvolume as /home, remounting the old root subvolume (subvolume name doesn't matter) as /oldroot, and creating a new subvolume for /.  Crash happens after partitions are wiped/recreated.

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-WS-x86_64-23-10 ro rd.live.image quiet rhgb
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

Another user experienced a similar problem:

installing on compact flash

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-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
packaging.log:  
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 23 (Twenty Three)
version:        23

Another user experienced a similar problem:

Tried to reinstall Fedora 23 over exising installation on encrypted BTRFS. Steps taken:

1. Choose custom partitioning
2. Unlock encrypted drives
3. Remove existing root btrfs subvol.
4. Add '/' mountpoint using btrfs on existing btrfs volume
5. Add '/home' mountpoint for existing sybvol
6. Add swap (reformat), /boot (reformat - ex4)
7. Done & Begin install => crash at creaging filesystems stage

cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=ext4 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
packaging.log:  
product:        Fedora
reason:         blivet.errors.FSError: mount failed: 32
release:        Fedora release 23 (Twenty Three)
version:        23

(In reply to John F Sullivan from comment #35)
> I agree this solution is better.  But, wouldn't it be even better still to
> not pass 'subvolid=5' in the mount options if a subvolume other than the
> default is used?

What we're trying to do is pass subvolid=5 when mounting the main volume. Obviously we did not intend to pass it when mounting any subvolumes.

> 
> (Please keep in mind I'm not a blivet developer - this look is my first into
> this code.)
> 
> Looks like vol_id is defined as a class variable and set to
> btrfs.MAIN_VOLUME_ID in line 159.  Fascinating since all instances will
> share this value, and any changes will affect all instances.  I don't see

The main volume id is always 5 AFAIK, so there is no need for any instance to modify that value. Also, if an instance sets 'self.vol_id = 23' python will create an instance attribute 'vol_id' and assign to that, preventing the change from affecting other instances. The only way to change the class attribute is to assign to it explicitly via 'BTRFSVolume.vol_id = 22'.

1306808 is an F24 blocker, so closing this as a dupe of that. I'll make a note of Ivan's patch there so it doesn't get lost.

*** This bug has been marked as a duplicate of bug 1306808 ***