Bug 1419222 - tmp option of crypttab unusable
Summary: tmp option of crypttab unusable
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.8
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: David Kaspar [Dee'Kej]
QA Contact: qe-baseos-daemons
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-04 00:23 UTC by Leon Fauster
Modified: 2017-02-13 10:47 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-02-13 10:47:15 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Leon Fauster 2017-02-04 00:23:25 UTC
Description of problem:

I have successfully used the swap option of crypttab (# man crypttab)
to encrypt the swap partition dynamically. rc.sysinit enables that 
swap partition successfully at the right point (after encryption). 

The same doesn't work for the tmp option of crypttab (# man crypttab).
The encrypted partition is present after booting the system. Manually   
mounting it works but adding "/dev/mapper/luks-tmp" into fstab shows that 
the boot process tries to mount it too early (not encrypted yet). 

This is confusing because other encrypted volumes (not dynamically) 
in fstab are successfully mounted. 

Okay, I see (line 842 /etc/rc.d/init.d/functions). It seems that 
volumes with random keys are skipped at that stage.

Version-Release number of selected component (if applicable):


How reproducible:

echo "luks-tmp /dev/device /dev/urandom tmp" >> /etc/crypttab
echo "/dev/mapper/luks-tmp /tmp	ext4	defaults 1 2" >> /etc/fstab  

Actual results:
Failure while booting respectively while mounting general fstab entries

Expected results:
mounting /tmp after encryption

Solution info:
rc.sysinit should skip volumes and memorize them that have key_is_random() 
while in the general mounting loop.

after mounting / rw and feeding random device, the line 563 in rc.sysinit will
generate the tmp enc fs. Therefore after this the mount loop must be called 
again but just for the memorized (skipped) volumes.

Comment 2 David Kaspar [Dee'Kej] 2017-02-13 10:47:15 UTC
Hello Leon,

thank you for you bug report.

Unfortunately, making changes to encryption might potentially negatively affect many other customers, who require stability of RHEL-6, because we are in phase 2 of its lifecycle. FOr more info, please, visit:


I would suggest you to upgrade to RHEL-7, if possible. As far as I know, the encryption process for partitions has been changed there, and initscripts no longer take care of that.

Best regards,


Note You need to log in before you can comment on or make changes to this bug.