Bug 506107

Summary: encrypted /home partition makes unattended boot impossible, timeout requested
Product: [Fedora] Fedora Reporter: Jens Hardings <jens>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: notting, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-15 21:13:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jens Hardings 2009-06-15 15:43:53 UTC 
Description of problem:
It is not possible to add an option to /etc/crypttab so it does not query the passphrase for a crypted device. This makes it impossible to have an unattended boot, even if that particular partition is not necessary for booting.

Version-Release number of selected component (if applicable):
initscripts-8.95-1.x86_64

How reproducible:
on every boot.

Steps to Reproduce:
1. create an encrypted /home partition
2. add corresponding entry to /etc/crypttab
3. reboot

When nobody is in front of the machine, it gets to the crypted filesystem passphrase promt, without any possibility of logging in remotely to enable the decryption of the encrypted partition.

Adding a timeout option in /etc/crypttab and accordingly some parsing in /etc/rc.d/rc.sysinit would allow the machine to wait some time and proceed without mounting the specified partitions, which would be unavailable until someone mounts them manually. This manual mount could be done remotely.

Additional info:
This is a similar request as in Bug 434696. The request of an noauto option would allow the system to be booted, but a timeout would be more flexible in this case.
Comment 1 Bill Nottingham 2009-06-15 21:13:58 UTC 

*** This bug has been marked as a duplicate of bug 434696 ***