Bug 2029101

Summary: [RHEL 8.5] Unable to set luks passphrase during installation in GUI , if --passphrase is skipped in kickstart file.
Product: Red Hat Enterprise Linux 8 Reporter: Ameya Patil <amepatil>
Component: anacondaAssignee: Vendula Poncova <vponcova>
Status: CLOSED ERRATA QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact: Sagar Dubewar <sdubewar>
Priority: unspecified    
Version: 8.5CC: alrodrig, jikortus, jkonecny, jstodola, pdwyer, rvykydal, sbarcomb, sdubewar, tgunders, vponcova, zveleba
Target Milestone: rcKeywords: TestCaseNeeded, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: anaconda- Doc Type: Bug Fix
Doc Text:
.Installer asks for the passphrase missing in the Kickstart file for the encrypted devices during the installation Previously, when running the installer in graphical mode, if the passphrase was not specified in the Kickstart file, the installer would not ask for entering the passphrase for encrypted devices. As a consequence, the partitioning specified in the Kickstart file was not applied during the installation. This update adds a dialog window that appears during the installation and asks for the missing passphrase. As a result, the installer properly applies the partitioning scheme specified in the Kickstart file.
Story Points: ---
Clone Of:
: 2087218 (view as bug list) Environment:
Last Closed: 2022-11-08 09:17:10 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:

Description Ameya Patil 2021-12-05 02:00:06 UTC
This is similar to the issue discussed at https://bugzilla.redhat.com/show_bug.cgi?id=1970319 however the context is different here.

During kickstart installation with encrypted partitioning if user omit the --passphrase part so they can set it during installation. The partitioning scheme is not retained hence unable to set passphrase similar to how we have for RHEL 7

part pv.01     --fstype="lvmpv"        --size=1	  --ondisk="$INSTALLDISK"	--grow --encrypted [--passphrase testtest]

Current documentation, points to that if --passphrase is not given with --encrypted, then installer will prompt for it.

--encrypted - Specifies that this partition should be encrypted with Linux Unified Key Setup (LUKS), using the passphrase provided in the --passphrase option. If you do not specify a passphrase, Anaconda uses the default, system-wide passphrase set with the autopart --passphrase command, or stops the installation and prompts you to provide a passphrase if no default is set.

--passphrase= - Specifies the passphrase to use when encrypting this partition. You must use this option together with the --encrypted option; by itself it has no effect.

Under RHEL 7 when used to leave the --passphrase parameter.  The user was prompted for checking Installation Destination (due to incomplete Kickstart) and the partitioning was retained there, the user could set passphrase and click done and continue with installation.

While in RHEL 8.4 and RHEL 8.5 , as per the bug https://bugzilla.redhat.com/show_bug.cgi?id=1970319 , once user select the when the Installation Destination the information in the Kickstart file for partition layout is not presented and if we want to proceed we would have to enter all of the custom partitions manually.

I tested and it works in Text installation as it does not need to enter the graphical installer stoke for storage, and anaconda itself prompts for password on the Anaconda Tmux screen.

May be we need to give a similar prompt in graphical installation with Kickstart to set the LUKS password without entering the storage stoke which would cause a reset the partitioning similar to Text install with Kickstart or if its not supported then update  the documentation to reflect this behavior for GUI installs with Kickstart

Version-Release number of selected component (if applicable):
Anaconda RHEL 8.5 DVD/BOOT ISO

How reproducible:

Steps to Reproduce:
1. Set up Kickstart with encrypted partitioning and only specify --encrypted and leave --passphrase.
2. Boot with kickstart file inst.ks=<url_to_kickstart_file>
3. When the anaconda stops prompted Installation Destination (Kickstart insufficient) , we can go to the 'Installation Destination' and observe if we select 'manual partitioning' it does not retain the information from our kickstart and hence not able to set passphrase, so need to redo the full partitioning.

Actual results:
Anaconda does not retain the data we used for partitioning under installation destination so not able to set luks encryption similar to RHEL 7

Expected results:
May be we need to give a similar prompt in graphical installation with Kickstart to set the LUKS password without entering the storage stoke which would cause a reset the partitioning similar to Text install with Kickstart or if its not supported then update  the documentation to reflect this behavior for GUI installs with Kickstart

Additional info:
The customer reason for skipping the passphrase was to avoid embedding it in the Kickstart file.

Comment 1 Jiri Konecny 2021-12-13 16:19:18 UTC
After a consultation with a team (Vendy) we might have a solution. 
The current problem is that the Anaconda "new" solution is taking kickstart data separate from the custom partitioning. So, before custom partitioning asked you for password because it was a requirement to continue. Now the custom partitioning is empty (because it doesn't share data with kickstart) so it will not ask.

Our proposed solution is to add a new radio button with "kickstarted" (or similar name) option to the Storage spoke which would then ask you for the password there if not provided. This new radio button will be there only if Anaconda is booted with a kickstart file. The side benefit is that it makes obvious to a users that the configuration is not shared between "kickstarted" and "Custom Partitioning". We can also give users a possibility to return to the kickstart configuration in case when the user will change their mind after switching to something else (e.g. "Custom Partitioning"). 

Proposing this for next minor planing.

Comment 2 Jan Stodola 2021-12-13 16:35:07 UTC
the proposed solution would add the "kickstarted" button every time a kickstart installation is running? Or just when a passphrase for LUKS devices is missing in the kickstart file?
Having the "kickstarted" button with every kickstart installation would be very confusing for users running an interactive installation with a kickstart file defining for example just a liveimg installation source (RHVH).

Comment 3 Vendula Poncova 2021-12-14 10:43:33 UTC
Hi, the new radio button should be there only if the kickstart file defines a custom partitioning using the reqpart, part, logvol, volgroup, raid and mount(?) commands. Otherwise, it is an automated partitioning and we already have a radio button for that.

Comment 4 Jan Stodola 2021-12-15 16:03:10 UTC
OK, I need more data to understand the proposal.
1) Let's say I have a kickstart file with a missing passphrase:

part /boot --size=500
part swap --fstype=swap --recommended
part / --grow --size=2048 --encrypted

What will happen after I select the "kickstarted" button on the storage screen? I can think of two options:
* anaconda will simply ask for the missing passphrase and nothing more.
* anaconda will enter the custom partitioning screen with the partitioning layout defined in the kickstart file and asks me for the passphrase when leaving the screen (the user might be (or not) able to do additional partitioning changes).

2) I have a kickstart file with an incomplete partitioning:

part /boot --size=500
part swap --fstype=swap --recommended
#part / --grow --size=2048

What would happen in such a case after selecting the "kickstarted" button?

Comment 13 Jan Stodola 2022-05-17 15:34:04 UTC
rhel-9 clone: bug 2087218

Comment 18 Jan Stodola 2022-06-20 14:28:30 UTC
Checked that anaconda- is in nightly compose RHEL-8.7.0-20220619.0

Moving to VERIFIED

Comment 22 Jan Stodola 2022-10-03 12:20:20 UTC
*** Bug 1942574 has been marked as a duplicate of this bug. ***

Comment 24 errata-xmlrpc 2022-11-08 09:17:10 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (anaconda bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.