Bug 1772902 - Impossible to perform a kickstart installation on an already existing LUKS container
Summary: Impossible to perform a kickstart installation on an already existing LUKS co...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Vendula Poncova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-15 14:12 UTC by Derrien
Modified: 2020-04-07 13:16 UTC (History)
9 users (show)

Fixed In Version: anaconda-32.24.5-1 anaconda-32.24.5-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-07 05:05:14 UTC
Type: Bug


Attachments (Terms of Use)

Description Derrien 2019-11-15 14:12:21 UTC
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

Comment 1 Vendula Poncova 2019-11-15 14:46:35 UTC
vtrefny, could you have a look at this bug, please?

Comment 2 Derrien 2020-03-27 10:54:11 UTC
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.

Comment 3 Marcin Zajaczkowski 2020-03-28 17:39:58 UTC
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).

Comment 4 Vojtech Trefny 2020-04-02 11:18:17 UTC
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.

Comment 5 Derrien 2020-04-02 15:53:01 UTC
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.

Comment 6 Vendula Poncova 2020-04-03 12:23:01 UTC
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

Comment 7 Derrien 2020-04-03 13:03:46 UTC
Thanks

Comment 8 Fedora Update System 2020-04-03 13:59:01 UTC
FEDORA-2020-176362208a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-176362208a

Comment 9 Fedora Update System 2020-04-04 06:17:01 UTC
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.

Comment 10 Fedora Update System 2020-04-07 05:05:14 UTC
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.

Comment 11 Fedora Update System 2020-04-07 13:16:09 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.