Hide Forgot
Description of problem: As commented by egdoc the change https://github.com/rhinstaller/anaconda/commit/a8b4f2d547f5ea987e52b32e33bc323c7aa21442 "makes impossible to perform a kickstart installation on an already existing LUKS container. This is usually done by opening the LUKS container in the %pre section of the kickstart file, and then re-using the decrypted partition or lvm logical volumes. Since the container is not opened by anaconda, the device doesn't get a key, therefore the installation is aborted." Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: "The existing unlocked LUKS device X cannot be used for the installation without an encryption key specified for this device. Please, rescan the storage." Expected results: To be able to reuse partition in kicstart : logvol / --name=root --vgname=fedora_x --useexisting logvol swap --name=swap --vgname=fedora_x --noformat logvol /home --name=home --vgname=fedora_x --noformat part /boot --onpart=sda2 part /boot/efi --onpart=sda1 --noformat after an 'cryptsetup luksOpen ...' in %pre section Additional info We have to create an updates.img to remove 'self.add_check(verify_unlocked_devices_have_key)' and bypass the pb
vtrefny, could you have a look at this bug, please?
Hi, Any news? Or will this bug still be present in F32? I can't test F32 beta install because of containment ;-( but according to the source (https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/storage/checker.py) the line 'self.add_check(verify_unlocked_devices_have_key)' is still there.
I've bumped into this recently trying to install F32 (having some other, unrelated for installation LUKS LVM partition). @Derrien, thanks for a tip with checker.py! After I commented this check out, I was able to finish the installation (I didn't use Blivet for which it seems to be added, based on the commit message).
Simple summary of the root of this issue: Blivet (library that Anaconda uses for storage configuration) needs to be able to open the LUKS device during the installation. Yes, it was opened in the %pre script, but we close it during the initial scan of the storage (we do this to all LUKS devices, we are also stopping RAID arrays, deactivating LVs etc.). It's not ideal but changing this behaviour will require changing a lot of code and could possibly break other things. We plan to change this in future releases but not for F32. We thought that installation on a manually opened LUKS device doesn't work at all so the new check in Anaconda was meant to just show a "nice" error instead of crashing during the installation. But due to another bug in Blivet it is possible to open the LUKS device in %pre script and successfully finish the installation -- we expect the cleartext device name to be the standard "luks-<UUID>" and if you choose different name when opening it manually with cryptsetup, Blivet thinks it's not opened so we don't try to close it.
Thank you for the explanations. So if I understood correctly, it used to work 'by chance'. I hope that in the future we will always have the possibility to do it because it is very useful for us: reinstalling the system while keeping the data from /home on another partition.
Hi, we will temporarily add an exception to the storage check, but it will be removed if it causes further issues. See the pull request: https://github.com/rhinstaller/anaconda/pull/2424
Thanks
FEDORA-2020-176362208a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-176362208a
FEDORA-2020-176362208a has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-176362208a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-176362208a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-176362208a has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.