Hi,
Sorry it took me so much time to answer, I have been quite busy these days.
On 15/12/2014 21:11, Jonas Meurer wrote :
Am 07.11.2014 um 14:56 schrieb Clayton:
On Fri, 07 Nov 2014 11:08:31 +0100
Milan Broz <gmazyl...@gmail.com> wrote:
backcrypt /dev/sdb2 none
cipher=aes-cbc-plain,size=256,hash=ripemd160,noauto,loud
If it is not passphrase, are you sure these were the correct
parameters? Who added them there? (mainly check mode:
-plain /-essiv:sha256, key size 128/256 ?)
(it should be, these are old cryptsetup plain defaults but you should
check old crypttab backups for sure...
....like I said that file has not changed. The same partition unlocks
using an older cryptsetup on an older Debian and EXACTLY the same
crypttab. Therefore, something ails the new version of cryptsetup -or-
there is some kind of new undocumented default behavior.
really better use LUKS to avoid this problem,
Yes, I use LUKS on all new installs, but this disk was built many years
ago. I am sure there will be a few Wheezy --> Jessie upgrades with
similar legacy disks.
Honestly, I don't think that the cipher/size/hash parameters are the
cause for trouble here. If they were, others (e.g. me) would have run
into this issue as well. Something else must have changed.
or even better - if you have systtem which opens
it correctly, use cryptsetup status for active device and check it)
Like you said,
cipher=aes-cbc-plain,size=256,hash=ripemd160
are the old old defaults and should work. And they still do. With a
slightly older version of crytpsetup, same encrypted partition.
Did you try manual unlocking of the dm-crypt device? That way, all
changes to initscripts, crypttab processing, etc. could be factored out
as possible root for the issue.
Please try manual unlocking both with the up-to-date system and with the
old usb live system:
# cryptsetup --cipher=aes-cbc-plain --size=256 --hash=ripemd160 \
create backcrypt /dev/sdb2
# blkid /dev/mapper/backcrypt
I agree with that, and actually manual unlocking worked for me.
To my opinion, the problem comes from Debian's askpass utility, as I
tried to mention earlier. The point is that the function systemd_read(),
which is used by default with a new Debian Jessie system, does not
remove the trailing '\n' at the end of the input, while it should.
You can find attached the patch for askpass.c, which fixes the bug.
Best regards,
Quentin
--- askpass.c.orig 2014-12-17 12:18:19.507662401 +0100
+++ askpass.c 2014-12-17 12:20:56.720441977 +0100
@@ -195,13 +195,13 @@
{
debug("In systemd_read\n");
if (fifo_common_read(fd, &systemdbuf, &systemdused, &systemdsize)) {
- *buf = systemdbuf;
- *size = systemdused;
/* systemd likes to include the terminating newline */
- if (systemdused > 1 && systemdbuf[systemdused - 1] == '\n') {
+ if (systemdused >= 1 && systemdbuf[systemdused - 1] == '\n') {
systemdbuf[systemdused - 1] = '\0';
systemdused--;
}
+ *buf = systemdbuf;
+ *size = systemdused;
return true;
}
