Arch Linux

I'm not sure what could cause this right now. However, the best idea is to use a key file instead of a passphrase.

I'll see if I can come up with the cause of this problem though.

The problem here is that midline comments are intentionally being trimmed from the end of the line. Please try this patch:

http://sprunge.us/jNUX

I can confirm this. Hadn't updated for some time, but now I run into this issue too.
I get the error message "No key available with this passphrase".

Daves patch doesn't work for me. With this patch I get:
/etc/rc.d/functions: line 274: cannot create temp file for here-document: Read-only filesystem
Device doesn't exist or access denied.

Keyfile doesn't work either or I'm too stupid to understand. I wrote my passphrase into the file /etc/cryptkey and wrote "/etc/cryptkey" in the second column in the crypttab. This failes too with "No key available with this passphrase".

If you use a keyfile, you must make sure that there is no newline at the end of it.

I have not looked further into the issue with the passphrase field yet, but I will.

Ahh, the read only error makes a whole lot of sense there.

What doesn't make sense is the eval, which actually will misinterpret your password should it contain a $ character, e.g.:

line="foo bar secretpas$phrase"
eval nspo=($line)
printf '%s\n' "${nspo[@]}"

You'll see that the 3rd column is neatly truncated to secretpas, as $phrase is interpreted via eval before assignment. not good.

I think we have multiple problems here...
For the '#'-sign it is enough to apply the attached patch. I think with this substring removal it is intended to remove comments at the end of line like this one:
home /dev/sda2 mysecretpass # this is the pass for my home partition

Is this right? Sadly, if there is no comment at the end of the line and you have a '#' in your pass, it removes this too, which alters your password obviously.

If you have a '$'-sign in your pass eval is trying to expand this as a variable, which is one of it purpose, isn't it? See this test script:
#!/bin/bash

phrase='foobar'
line='foo bar secretpas$phrase'
eval nspo=("${line}")
echo ${nspo[@]}

Output is: foo bar secretpasfoobar
Without eval the output is: foo bar secretpas$phrase

If you have an extra line declaring a variable inside /etc/crypttab which you intend to be a part of your passphrase, then your crypttab will not properly parse because of this bogus variable declaration.

It'a also worth noting that the quotes are meaningless here. They're interpreted on the eval which means that word splitting occurs on the eval'd contents inside the array declaration. If we remove the eval, the quotes need to go as well or else nspo is declared as an array with a single element, instead of word splitting cutting it on IFS into 3+ elements.

You're right of course. I just wanted to show that eval is trying to expand the variable $phrase here and if you don't have a declaration for $phrase (which should be like that in a normal crypttab) it is just NULL, which causes your password to be just "secretpas".

Please use a keyfile instead. I'll close this as wontfix.

Though, if someone posts a non-intrusive and tested fix to arch-projects@archlinux.org, I'll look into it.