Bug 1772902 - Impossible to perform a kickstart installation on an already existing LUKS container [NEEDINFO]
Summary: Impossible to perform a kickstart installation on an already existing LUKS co...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
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: 2019-11-15 14:46 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
vponcova: needinfo? (vtrefny)


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?


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