Red Hat Bugzilla – Bug 1261721
preexisting btrfs snapshot cannot be assigned as mountpoint for new installation
Last modified: 2016-09-09 20:53:02 EDT
Description of problem: Fedora 22 installation has a LUKS volume mounted at /home, and this cannot be re-used in the Fedora 23 installer.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fedora 22 with a working LUKS volume mounted at /home
2. Launch Fedora 23 installer, custom partitioning, click on LUKS volume and unlock.
3. Select unlocked LUKS volume and try to assign /home mount point
This device cannot be edited directly. You can remove it or select a different device.
To be able to re-use existing LUKS volumes.
Created attachment 1071993 [details]
Created attachment 1071994 [details]
Created attachment 1071995 [details]
Proposed as a Blocker for 23-final by Fedora user chrismurphy using the blocker tracking app because:
"The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration."
Created attachment 1071996 [details]
screenshot of problem
Created attachment 1072316 [details]
jsgallagh ournal of failed installation
I just attempted to reproduce this by taking the following steps:
1) Install a fresh VM with Fedora Server 23 Beta TC4 taking all defaults (including default filesystem layout) except check the encryption box on the storage pane and enter a password.
2) Verify that the installed system boots and can be logged in.
3) Shut it down and boot from the TC4 install media again. Go into the storage pane and select "I will configure storage myself".
4) Attempt to unlock the encrypted LVM partition. The installer will hang. I was able to get to a virtual terminal and extract the journal, which I'm attaching here, that shows a bug in the attempt to access the filesystem.
to me sgallagh's bug looks different from cmurf's, and they probably ought to be tracked differently - if they come down to the same code in the end we can dupe them off, but it doesn't look like it.
(In reply to Stephen Gallagher from comment #6)
> Created attachment 1072316 [details]
> jsgallagh ournal of failed installation
> I just attempted to reproduce this by taking the following steps:
> 1) Install a fresh VM with Fedora Server 23 Beta TC4 taking all defaults
> (including default filesystem layout) except check the encryption box on the
> storage pane and enter a password.
> 2) Verify that the installed system boots and can be logged in.
> 3) Shut it down and boot from the TC4 install media again. Go into the
> storage pane and select "I will configure storage myself".
> 4) Attempt to unlock the encrypted LVM partition. The installer will hang. I
> was able to get to a virtual terminal and extract the journal, which I'm
> attaching here, that shows a bug in the attempt to access the filesystem.
This may in fact be a separate bug, so I've opened BZ #1262086 to track it.
The original problem is that anaconda does not allow using btrfs snapshots as mountpoints.
Discussed at 2015-09-10 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-09-10/f23-blocker-review.2015-09-10-16.00.log.txt . At the meeting, we agreed that we would like more information on precisely what the affected layout was, and dlehman's input, before determining the blocker status.
Since then dlehman has made it clear that the issue here is not 're-using a LUKS /home' but 're-using any btrfs snapshot', and that this is essentially a feature request: anaconda does not currently support this and never has, it's not a *bug* exactly. I therefore vote -1 blocker.
(In reply to David Lehman from comment #9)
> The original problem is that anaconda does not allow using btrfs snapshots
> as mountpoints.
This seems incorrect:
a. home is a subvolume not a snapshot (not that they should be distinguished, as Btrfs itself doesn't)
b. Without LUKS underneath, I can assign a home subvolume to /home when doing a new installation. I do this regularly.
Created attachment 1072372 [details]
screenshot, no problem without LUKS
This is the F22 installer. It has no problem with existing home subvolume being assigned to /home mountpoint. I just tested this with Fedora 23 installer, and it work also. So there's something specific to this Btrfs on LUKS arrangement the installer doesn't like but I can't figure out what it is. In any case the summary of this bug is wrong.
OK so the summary is correct! And this is not a LUKS related bug.
If I do:
btrfs sub crea /mnt/home2
cp -a --reflink /mnt/home/* /mnt/home2/
Anaconda permits home2 to be assigned to /home, where home cannot. That's pretty goofy, but I'm going to bet it's an unintended side effect of whatever the logic is behind differentiating between snapshots (which are just pre-populated subvolumes) and non-snapshot subvolumes.
Therefore it's a legit bug, not a feature request. But whether it's a blocker is a gray area. The bug prevents the user from reusing a subvolume restored with btrfs send/receive from a backup, for example; as well as obviously breaking a snapshot/rollback workflow for /home.
Discussed at 2015-09-14 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-09-14/f23-blocker-review.2015-09-14-16.00.log.txt .
This was rejected as a blocker. We've consistently not interpreted the criterion to mean anaconda must support re-using absolutely anything you can put on a disk; the rule of thumb is that if the bug is effectively a feature request - anaconda simply doesn't have the capability and wasn't (yet) intended to - it's not a blocker. That fits this situation precisely, and so this bug is not a blocker.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is still a problem with python3-blivet-2.1.2-1.fc25.noarch and it prevents using an existing /home.