Red Hat Bugzilla – Bug 1436304
RHEL 7 kickstart text mode installation halts when just --encrypted is mentioned
Last modified: 2018-10-30 03:55:12 EDT
Description of problem: When RHEL7 is kickstarted in text mode using the following partitioning, it fails with unfinished Disk configuration (Error checking storage configuration) error and would not prompt for luks password as RHEL 6 text mode or RHEL 7 graphical installation. ~~~ clearpart --all --initlabel part /home --fstype=ext4 --size=500 --encrypted part /boot --fstype=ext4 --size=200 part swap --size=1000 part / --fstype=ext4 --grow --size=200 ~~~ In RHEL 6 text mode, this was prompting the user to provide the password and even RHEL7 documentation mentions as follows. --encrypted — Specifies that this logical volume should be encrypted, using the passphrase provided in the --passphrase= option. If you do not specify a passphrase, the installation program will use 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. Version-Release number of selected component (if applicable): RHEL7.x How reproducible: Always Steps to Reproduce: 1. Use the partitioning mentioned above and start the installation in text mode. 2. See the error Actual results: anaconda installer fails with "Error checking storage configuration" error and doesn't prompt for luck passphrase Expected results: It should have asked for password for passphrase like RHEL6 and as per documentation. Additional info: Similar bug (Bug 1185466) was filed for RHEL 7 graphical installation and resolved with an error but customer is expecting same behaviour in RHEL 7 text mode installation as well.
Please attach logs to this bug as individual, text/plain attachments. They can be found in /tmp.
Created attachment 1322176 [details] Anaconda Log
Created attachment 1322177 [details] Anaconda Interface Config Log
Created attachment 1322178 [details] Anaconda Yum Log
Created attachment 1322180 [details] Anaconda Program Log
Created attachment 1322181 [details] Anaconda Storage Log
(In reply to Samantha N. Bueno from comment #2) > Please attach logs to this bug as individual, text/plain attachments. They > can be found in /tmp. I have attached logs of a kickstarted text installation of RHEL 7.4 on a virtual machine using the following kickstart partitioning scheme: - # System bootloader configuration. bootloader --location=mbr --boot-drive=vda clearpart --all --initlabel --drives=vda zerombr # Disk partitioning information. part /home --fstype=ext4 --size=2048 --encrypted part /boot --fstype=ext4 --size=512 part swap --size=1000 part / --fstype=ext4 --grow --size=200 - The error I get in Anaconda is: "LUKS device vda2 has no encryption key" If I provide a blank --passphrase flag Anaconda dies with the error: "The following problem occurred on line 40 of the kickstart file: --passphrase option requires an argument"
I am experiencing this issue as well. I am using a plaintext passphrase right now, but this is very undesirable as the config is stored on our PXE install server and then shows up in original-ks.cfg in /root. Are there plans to implement an encrypted passphrase such as it is done with the root password? I noticed some discussion here years back but haven't found info on the current state of that as of today with centOS 7.
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/1468
Verified with anaconda-21.48.22.143-2.el7. Anaconda running in text mode asks for the encryption password. Tested the autopart, part and pv kickstart commands. Also retested cmdline and graphical installations for possible regressions - no change comparing to RHEL-7.5 GA was found. Moving to VERIFIED.
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3035