I have a disk partitioned as so: /dev/sda1 - /boot (1GiB) /dev/sda2 - /boot/efi (1GiB) /dev/sda3 - unused (2GiB) /dev/sda4 - LUKS-encrypted device containing btrfs filesystem (400 GiB) /dev/sda5 - LUKS-encrypted device containing LVM block device (48 GiB) I have Fedora 16 installed onto a top-level subvolume named "F16" of the btrfs filesystem. The btrfs filesystem only has ~28% of its capacity used. My goal was to install Fedora 18 onto the btrfs filesystem, also in a top-level subvolume. My understanding is that although the UI gives no indication that it is mucking around with subvolumes, this is what it will do. I performed the following actions: Click "Installation Destination" in the "Installation Summary" screen. Click "Continue". The "Installation Options" pop-up appears. Expand "Partition scheme configuration" and select BTRFS as the partition type. Select "I don't need help". Click "Reclaim space." This goes to the "Manual Partitioning" screen. Expand "Unknown". Format sda1 as /boot (ext4). Format sda2 as /boot/efi (EFI System Partition). Select sda3 and type the password to unlock it. Click "+" to add a new mount point. Enter "/" for the mount point; leave the desired capacity blank. Click "Add mount point". Select the "Root" entry in the "New Fedora 18 Installation" pane. Enter "root" in the "Label" field. Leave "Device Type" set to "BTRFS". (All other options will be grayed out.) Click "Finish partitioning". Click "Begin Installation". Anaconda will crash shortly into the "Preparing to install" phase. If I go through the installer again, but instead unlock the LVM device and configure anaconda to install the root filesystem onto a new logical volume, then the install succeeds. I attempted to submit a bug report in anaconda, but my report was rejected as a duplicate of bug 870586. The title of the bug report I was unable to submit was: DeviceCreateError: ('12', 'root') - anaconda This is a critical bug, because Fedora 17 is incapable of installing onto btrfs, and Fedora 16 is now at end-of-life. So people who installed Fedora 16 using btrfs now have no upgrade path.
Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual text/plain files.
Created attachment 734474 [details] anaconda.log
Created attachment 734475 [details] ifcfg.log
Created attachment 734476 [details] packaging.log
Created attachment 734477 [details] program.log
Created attachment 734478 [details] storage.log
Created attachment 734479 [details] X.log
I think the critical part is this line: 17:03:08,876 INFO program: Running... /bin/mount -n -t btrfs -o defaults /dev/mapper/luks-fa897310-ff6e-4ea8-92aa-c85cfffcafcc /tmp/btrfs-tmp.33ddJ_P2 It looks like anaconda is assuming that mounting the btrfs filesystem will automatically mount the top-level subvolume (subvolid=0). That is a false assumption, because my btrfs top-level subvolume contains only subvolumes that are complete snapshots of the entire system. E.g.: $ mount -o subvolid=0 /dev/mapper/luks-fa897310-ff6e-4ea8-92aa-c85cfffcafcc /mnt $ ls -1F /mnt F16/ F18/ F18.20130314/ F18.20130318/ F18.20130320/ F18.20130322/ F18.20130325/ F18.20130326/ F18.20130327/ F18.20130329/ F18.20130331/ F18.20130401/ F18.20130403/ F18.20130404/ F18.20130405/ F18.20130407/ F18.20130409/ F18.20130411/ The datestamped subvolumes are subvolumes I created via making snapshots. I do this each time I perform yum updates. If any yum update breaks the system, then I boot single-user (or from a rescue image if I have to), change the default subvolume to the last known-good snapshot, and then reboot. (Each one of those subvolumes actually contains multiple other subvolumes, but let's not get into that right now.) The subvolume that currently is mounted by default is the "F18" one, not the root subvolume. So when anaconda executes its mount operation, it gets the F18 subvolume, and the subsequent attempt to create a "root" subvolume fails because there is already a /root directory. I think the only sane thing for anaconda to do when installing onto btrfs is to mount the top-level subvolume, create a subvolume for the install (e.g., "Fedora_18"), change that subvolume to be the default, unmount and remount, and then install. If that's not where the user wanted the install to go, he can always "move" it by making a snapshot. Honestly, the only other alternative is for anaconda to probe the subvolume structure of the btrfs filesystem and ask the user to select the location where the subvolume for the install should be created.
The bug here is that we're not overriding the default subvol for preexisting btrfs. I'll work on a patch to do that. As a workaround, all you have to do it reset the default subvol to be the top-level prior to installing.
anaconda-19.24-1.fc19, python-blivet-0.12-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/python-blivet-0.12-1.fc19,anaconda-19.24-1.fc19
Package anaconda-19.24-1.fc19, python-blivet-0.12-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-19.24-1.fc19 python-blivet-0.12-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-7403/python-blivet-0.12-1.fc19,anaconda-19.24-1.fc19 then log in and leave karma (feedback).
anaconda-19.24-1.fc19, python-blivet-0.12-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.