Bug 921757

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.