Bug 845701 - Crypttab does not mount volume at boot
Crypttab does not mount volume at boot
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Lukáš Nykrýn
Depends On:
  Show dependency treegraph
Reported: 2012-08-03 18:43 EDT by Todd
Modified: 2016-11-25 08:05 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-06 14:46:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Todd 2012-08-03 18:43:11 EDT
Hi All,

I am coming from the "Community": Scientific Linux 6.2, 64 bit.  Would one of our interpret heroes at Red Hat please fix this for me?

I just encrypted my backup drives.  In the process, I found the /etc/crypttab ignores my entry for my backup drive, forcing an error at fstab time.  I am forced to mount my backup drive with rc.local.

$ grep -i lin-bak /etc/crypttab
lin-bak /dev/sdb1 /etc/crypttab.lin-bak.key

$ grep -i lin-bak /etc/fstab
/dev/mapper/lin-bak /lin-bak ext4 defaults 1 0

fstab errors out with mount: "special device /dev/mapper/lin-bak does not exist".  This error is what you would expect as /etc/crypttab does not create /dev/mapper/lin-bak.   (/dev/mapper/lin-bak disappears after each reboot.)

There are no other errors other than the mount error at boot up.

My other UUID mounted drives (my main and swap drives) do get /dev/mapper entries and do mount correctly.

Here is my rc.local work around:

# if I can not get /etc/crypttab to work, this will populate /dev/mapper
# with lin-bak and mount /lin-bak

if [ ! -L /dev/mapper/lin-bak ]; then
   cryptsetup luksOpen /dev/sdb1 lin-bak < /etc/crypttab.lin-bak.key
   mount /lin-bak

Many thanks,
Comment 2 Milan Broz 2012-08-06 05:06:27 EDT
cryptsetup luksOpen /dev/sdb1 lin-bak -d /etc/crypttab.lin-bak.key

If not, your keyfile contains EOL (\n) and because keyfiles take EOL as normal char (while in interactive or pipe) input EOL causes end of input.

So in this case just trim your keyfile so it contain only chars before first \n - or change LUKS keyslot to use this keyfile. 
(Check with "hexdump -c /etc/crypttab.lin-bak.key".)
Comment 3 Todd 2012-08-06 13:10:16 EDT
# umount /lin-bak

# cryptsetup remove /dev/mapper/lin-bak

# cryptsetup luksOpen /dev/sdb1 lin-bak -d /etc/crypttab.lin-bak.key
No key available with this passphrase.

# cryptsetup luksOpen /dev/sdb1 lin-bak < /etc/crypttab.lin-bak.key
<It worked>

# hexdump -c /etc/crypttab.lin-bak.key
0000010 ...   \n

At this point, I have to cry foul!  "vi -b /etc/crypttab.lin-bak.key" shows this file to be a simple one line file.  If I add a second empty line, hexdump gives me two "\n" at the end of the file.  Since "vi" will not create a "\n" free file, how in the world am I to create a text file without a "\n" at the end?

And, more foul,
# hexdump -c < /etc/crypttab.lin-bak.key
0000010 ...   \n

Which does work, also has a "\n" in it!

I am really confused!

Comment 4 Todd 2012-08-06 13:25:54 EDT
More confusion, if I am not mistaken, if I find a way to remove the "\n", do I not get a 1024 character long file?
Comment 5 Milan Broz 2012-08-06 14:46:47 EDT
You can create it e.g.
echo -n "mypassword" >file

For removing \n... I would ether use dd (dd if=oldfile of=newfile bs=1 count=N-1) or something even more clever like... vi?

:set binary
:set noeol
(first hit on google btw ;-)

If you use it as keyfile (luksAddKey for example) then the \n will be just part of keyfile. 

So this is not bug, just quite problematic handling of \n in cryptsetup (which must be there for compatibility reasons...)
Comment 6 Todd 2012-08-06 15:36:29 EDT
Hi Milan,

Maybe not a bug, but really bad programming.  Who in the world in going to know they have to create the keyfile without the "\n"?

This there any chance you can use your considerable influence to get this fixed?  If not, can you at least get something put into the man page on the "\n" free requirement and how to create a  "\n" free keyfile?

Many thanks,
Comment 7 Todd 2012-08-06 15:53:22 EDT
Hi Milan,

I rebooted with my rc.local work around commented out.  I am confirming that your fix works.  /lin-bak mounted properly from fstab.

Thinking about the problem: I do believe that crypttab is expected to accept lie feeds (\n) as a possible password, so this is why I had the problem.  That being the case, the \n feed requirement must be documented in the man page.  Otherwise it is going to drive a lot of folks nuts, especially since I googled my eyeballs out and found nothing before reporting to you.

Should I open a new bug on the man page or can you just use this one and change the name?
Comment 8 Milan Broz 2012-08-06 16:03:28 EDT
see man cryptsetup - NOTES ON PASSPHRASE PROCESSING FOR LUKS section

crypttab has parameter for keyfile, so it is processed like a keyfile.
(but I do not maintain crypttab processing...)

Btw Debian crypttab man page has this:

The third field, key file, describes the file to use as a key for decrypting the data of the source device. Note that the entire key file will be used as the passphase; the passphase must not be followed by a newline character.

No idea why it is not in Fedora/RHEL man page. Reopen this bug it you want to fix man crypttab page (it is part of initscritps package).
Comment 9 Milan Broz 2012-08-06 16:10:03 EDT
(...and eventually RHEL can do it even without "passphase/passphrase" typos :-)
Comment 10 Todd 2012-08-06 16:16:59 EDT
(In reply to comment #9)
> (...and eventually RHEL can do it even without "passphase/passphrase" typos
> :-)

I went to publik skol!  :-)

How about my question about correcting the man page?  If you decide to do that, I will volunteer to write it.  (You can fix my spelling and cherry it out)

Comment 11 Todd 2012-08-06 19:27:58 EDT
Please move all activity on this bug to:

crypttab tab man page password section needs to be updated

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