Red Hat Bugzilla – Bug 855644
F18 Live (alpha RC2) Anaconda custom partition layout: no access to existing LVM/LUKS volumes
Last modified: 2012-10-22 14:26:44 EDT
Description of problem:
Given a local disk with one partition, one LVM and one large LUKS containing another LVM : to install F18, I need to select as "/" mount point, one of the LVs located inside the LUKS.
In custom partition setup screen, LUKS volume does appear, but it doesn't seem possible to unlock it from the UI. Clicking The white arrow to its right, brings no more information. Clicking the configure button at the bottom, produce no effects, except the above white arrow disappears.
Version-Release number of selected component (if applicable):
F18 KDE Live alpha TC5
Steps to Reproduce:
1. Boot, launch Anaconda from Desktop, select language and accept fate
2. Start custom partitioning
LUKS volume is listed but unusable
LUKS volume is listed, clicking it prompts for unlock passphrase.
Then, LVM inside it is available hence its LVs can be selected as mount points
LUKS and LVM are otherwise just fine on this system (reporting from F16 as installed within it, and I could successfully proceed with such installation, with the exact same conditions, using Anaconda from F17 KDE Live)
( and this is a blocker for me to test any F18 installation to hard disk from Live/Anaconda on this hardware )
Discussed at 2012-09-10 QA meeting, acting as a blocker review meeting. We agreed that this issue qualifies as a blocker under current criteria, but the criterion is outdated and specifically tied to the old UI. It is currently undergoing revision. We will revisit this bug once the criterion has been revised.
Tested F18 Live alpha RC2 ISOs. As previously :
* 2 volumes appear matching my LUKS/LVM size: one named "LUKS" and another named "Unknown", further down the volume list
* Hitting the "configure-like" icon, nothing happens with either of these two,
besides the white arrow to disappear
New: I now tried unlocking the crypt manually, prior to launching Anaconda.
* `cryptsetup` unlocked it fine, confirmed by status command. Then in Anaconda, all was exactly as previously, including the right arrows / configure behavior, and LUKS contents were still not listed.
* I checked its status again from cli, and `cryptsetup status` said it was back to offline (?!). I unlocked it for the second time, confirmed by status, and could list its contents with lvm commands once again.
* From this point onwards in Anaconda, despite going "back" and trying again a few times, *none* of the existing volume on this local disk, did ever show up any more : only the Fedora 18 / new section at the top, was displayed.
Quitting Anaconda (thus causing reboot), I could confirm disk layout was untouched, still all good and functional.
Created attachment 612187 [details]
anaconda.log, unlocking crypt prior to launch Anaconda, then again during execution
(from anaconda log, "Unknown" is the extended partition i.e. sda4 ?)
Discussed at 2012-09-12 blocker review meeting. After further consideration we agreed this actually doesn't even hit the existing criterion, which is about *creating* encrypted/LUKS partitions, not re-using existing ones. It certainly doesn't hit any of the proposals currently under discussion for revising the criterion, all of which are looser than the current wording. Therefore, this is solidly rejected as a blocker.
This appears to be fixed, tested Fedora-18-Beta-TC6-x86_64-Live-KDE.iso