Hide Forgot
Description of problem: Situation: An encrypted filesystem exists on a machine that is being booted. There is no immediate need to obtain the filesystem password and/or the filesystem is unavailable at this point in time. (Scenario: Maintenance on usually powered-down system to be performed by a person that has no "need to decrypt") Problem: The boot procedure asks you for the password and does not relent (using CTRL-C for example) Your options: reboot single, then mess around with /etc/fstab and possible /etc/crypttab or During earlier installation, have remembered to add "noauto" to /etc/fstab so that the encrypted filesystem is not mounted by default. Solution: Allow to skip mounting an encrypted filesystem by accepting CTRL-C or similar at the prompt. (On second thoughts, the "noauto" option would be a good solution if one knew about it) Version-Release number of selected component (if applicable): initscripts-9.03.23-1.el6.x86_64
In future major releases we may have a timeout here. However, the current infrastructure does not support that, and it can't easily be added. 'noauto' is documented in both the fstab and crypttab man page. The initscripts check should exit after 3 attempts. plymouth code may not, assigning there.
plymouth has a --number-of-tries option to the ask-for-password command. I believe initscripts already does --number-of-tries 3 ctrl-c should cancel any pending password requests immediately
initscripts in RHEL 6, at least, does not pass any --number-of-tries.
okay, moving back to initscripts.
Created attachment 524265 [details] potential patch
Hi, I tried the patch on RH6.1. I works insofar as the system gives up on the password query after 3 tries, BUT: After that, automounting causes problems. The filesystem-supposedly-decrypted is mounted normally through /etc/fstab, which of course fails: "The superblock could not be read or does not describe a correct ext2 filesystem" You are then dropped to the maintenance shell. This happens even if "noauto" has been given in /etc/fstab!
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/