Bug 1772902

Summary:	Impossible to perform a kickstart installation on an already existing LUKS container
Product:	[Fedora] Fedora	Reporter:	Derrien <derrien>
Component:	anaconda	Assignee:	Vendula Poncova <vponcova>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	31	CC:	anaconda-maint-list, bwaldo, exnihilo, jkonecny, jonathan, kellin, mszpak, vanmeeuwen+fedora, vponcova, vtrefny, wwoods
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	anaconda-32.24.5-1 anaconda-32.24.5-1.fc32	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-07 05:05:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.

Comment 12 Brett Waldo 2023-08-31 16:08:24 UTC

i don't know if i'm supposed to really comment on a closed bug, but i'll try anyway.  It looks like this is claimed to be closed by adding a check that map_name differs from child name. The comment seems to think the default is luks-{uuid}.  I see this failing still on the latest RHEL9. map_name and name are the same, in my case tcs-custom-pkgs.  I've created a new RHEL case to try and turn off this check. it is such a regression in my opinion.  unless there is some way to force child and map names to differ....

Comment 13 thomas 2024-04-10 16:38:38 UTC

Thanks to your comment, I have indeed be able to see that it's still an issue. I have tried several ways to try to get it to work (change name of the volume to something other than luks-UUID, select the same passphrase, tried to exclude the volume, checked the source to remove the check for locked LUKS as described here: https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://linuxconfig.org/how-to-install-fedora-rhel-centos-via-kickstart-on-an-existing-luks-device, etc). I don't know if the new installer may change this issue.