Bug 921757 - anaconda crashes when attempting to install onto existing btrfs filesystem
anaconda crashes when attempting to install onto existing btrfs filesystem
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: python-blivet (Show other bugs)
19
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-14 16:36 EDT by James Ralston
Modified: 2013-05-21 23:13 EDT (History)
8 users (show)

See Also:
Fixed In Version: anaconda-19.24-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-21 23:13:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
anaconda.log (63.47 KB, text/plain)
2013-04-11 20:12 EDT, James Ralston
no flags Details
ifcfg.log (485 bytes, text/plain)
2013-04-11 20:13 EDT, James Ralston
no flags Details
packaging.log (163.11 KB, text/plain)
2013-04-11 20:13 EDT, James Ralston
no flags Details
program.log (55.16 KB, text/plain)
2013-04-11 20:14 EDT, James Ralston
no flags Details
storage.log (298.61 KB, text/plain)
2013-04-11 20:14 EDT, James Ralston
no flags Details
X.log (29.32 KB, text/plain)
2013-04-11 20:15 EDT, James Ralston
no flags Details

  None (edit)
Description James Ralston 2013-03-14 16:36:14 EDT
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.
Comment 1 Brian Lane 2013-03-14 19:03:03 EDT
Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual text/plain files.
Comment 2 James Ralston 2013-04-11 20:12:59 EDT
Created attachment 734474 [details]
anaconda.log
Comment 3 James Ralston 2013-04-11 20:13:24 EDT
Created attachment 734475 [details]
ifcfg.log
Comment 4 James Ralston 2013-04-11 20:13:45 EDT
Created attachment 734476 [details]
packaging.log
Comment 5 James Ralston 2013-04-11 20:14:04 EDT
Created attachment 734477 [details]
program.log
Comment 6 James Ralston 2013-04-11 20:14:23 EDT
Created attachment 734478 [details]
storage.log
Comment 7 James Ralston 2013-04-11 20:15:16 EDT
Created attachment 734479 [details]
X.log
Comment 8 James Ralston 2013-04-11 20:40:30 EDT
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.
Comment 9 David Lehman 2013-04-24 16:01:51 EDT
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.
Comment 10 Fedora Update System 2013-05-03 19:04:18 EDT
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
Comment 11 Fedora Update System 2013-05-04 14:50:30 EDT
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).
Comment 12 Fedora Update System 2013-05-21 23:13:08 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.