Description of problem: I have older system which I wanted to "upgrade"/clean install+keeping /home, /dev/sda - sda1, /boot (ext4) - sda2, LUKS - LVM_PV - lv_swap - lv_root - lv_home I used anaconda to unlock LUKS, it recognized old system, and all partitions, I set mount point for /home without formatting, formated /dev/sda1 and set /boot mountpoint, for root, and swap when I selected to format them, and set mountpoint, anaconda automatically checks "encrypt" checkbox, and later asks for passphrase. Version-Release number of selected component (if applicable): I used beta-tc8 (which is the same as tc7) uses python-blivet-1.0.6-1.fc22,anaconda-22.20.8-1.fc22 (copied from rel-eng trac) How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I can confirm this is easily reproducible. The result is that not only Anaconda asks for a new passphrase it actually creates LUKS devices (on LVs) for all mountpoints that originally were on the encrypted LUKS.
I feel like I've seen another report of this, too? This feels Final blocker-ish, under our 'awesome' Final criterion (no, really, it's horrible): https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Disk_layouts "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." wdyt, vpod?
Well, in the case the installer is able to create and install to it, but the result is not what the user would expect. bitlord reported some further issues with this that might be better suited for final blocker criteria, but I don't have the descriptions available here to post them. To be honest, I don't mind if this is a blocker, freeze exception or just nothing as long as it gets fixed. Which is my goal for today.
(In reply to Vratislav Podzimek from comment #3) > Well, in the case the installer is able to create and install to it, but the * in this case...
Two patches sent two anaconda-patches.
if it gets fixed, we don't care either =) now Beta slipped, though, we do have a choice whether to pull it into Beta or wait for post-Beta. WDYT?
Well, I now have the patches ready, tested and reviewed. And they are not really intrusive so we can quite easily get them to beta.
Agh, sorry, busy morning - didn't see this in time to propose for an FE. RC2 is spinning without the change. Sorry!
Discussed at today's blocker review meeting [1]. This bug was rejected as Final Blocker but accepted as Freeze Exception - as described there's nothing here that really violates the criteria, the installed system seems to be operable, though not what would be reasonably expected, so accepted as a freeze exception issue. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-20/
anaconda-22.20.10-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/anaconda-22.20.10-1.fc22
Package libblockdev-0.11-1.fc22, python-blivet-1.0.8-1.fc22, anaconda-22.20.10-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libblockdev-0.11-1.fc22 python-blivet-1.0.8-1.fc22 anaconda-22.20.10-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-6866/libblockdev-0.11-1.fc22,python-blivet-1.0.8-1.fc22,anaconda-22.20.10-1.fc22 then log in and leave karma (feedback).
libblockdev-0.11-1.fc22, python-blivet-1.0.8-1.fc22, anaconda-22.20.10-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.