Bug 1261721

Created attachment 1071993 [details]
anaconda.log

Created attachment 1071994 [details]
program.log

Created attachment 1071995 [details]
storage.log

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.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.