Bug#846098: Works for me
Dear Maintainer, I've read that Keepass2 is going to be removed from Debian testing. Perhaps I misunderstood this bug report. Anyway, I'm surprised because my keepass2 works perfectly (though much slower to open a database than on Windows). I've an up-to-date Debian testing install, running with KDE. I can of course provide additional information. Best, Quentin
Bug#768407: [pkg-cryptsetup-devel] Bug#768407: cryptsetup: dm-crypt disk unlocks on older Debian, does not on current testing
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;
}
Bug#768407: [pkg-cryptsetup-devel] Bug#768407: cryptsetup: dm-crypt disk unlocks on older Debian, does not on current testing
Hi Jonas, On 17/12/2014 14:31, Jonas Meurer wrote : Am 17.12.2014 um 12:32 schrieb Quentin Lefebvre: IN 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. thanks for the patch. Now I see that this is a systemd-only problem with askpass.c, which explains why few people ran into it yet. Right. Just keep in mind that systemd is the default when you install Debian Jessie. So I consider there is quite a big issue here. I'll incorporate your patch into the next upload, hopefully in time for jessie. Cool! I hope it will be in time. Thanks for your work. Cheers, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: Patch applied upstream
Hi, For your information, a patch has been applied upstream. Here is the link: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93 Cheers, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: Patch applied upstream
Hi, On 24/11/2014 16:37, intrigeri wrote : Quentin Lefebvre wrote (24 Nov 2014 14:35:45 GMT) : For your information, a patch has been applied upstream. Here is the link: http://cgit.freedesktop.org/systemd/systemd/commit/?id=8a52210c93 Congrats! Can you please try to apply the upstream patch on top of Debian unstable's systemd, and confirm that it works and fixes the issue for you? Thanks for making me test the new patch. Actually it is a rewrite of the one I first proposed, and it doesn't work. I hope the developers will agree on my original patch. So... waiting! Cheers, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: Patch applied upstream
So here is the point of view of the developers. The upstream patch works provided that hash=plain is mentioned in /etc/cryptab. To summarize: - when a user creates a plain dm-crypt device providing a --hash parameter along with a key file - he *should* be aware of the fact that the hash parameter is ignored - and as a consequence, he should write hash=plain in /etc/crypttab - in short, it's a cryptsetup bug, and systemd won't be compatible with cryptsetup's bug... Let's say that's fine. It may be worth documenting this. Please note that this patch basically changes nothing about the aforementioned bug, so I'm not convinced it should be applied in Debian, and I don't attach it. The trick with hash=plain already works with Debian's current version of systemd. Best regards, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
Hi, On 19/11/2014 10:38, intrigeri wrote : I suggest attaching the patch to the upstream bug, so that it doesn't get lost in the mailing-list archive. I just did that. In the meanwhile, is it useful to patch Debian? I suspect the maintainers will want to see upstream review and ack the patch first. But still, it would be good to get this in Jessie in time before December 5 (it's an important bug, not a RC one). December 5th is coming soon. So I hope the process will be quick enough. By the way, what is the proper tool to create a patch for Debian? I read about dpatch, but I was told it's not relevant. It depends on how the package is maintained. In this case, see debian/README.source in the source package :) Thanks for the information. Best, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768407: Proposition for a patch for this bug
Hi, I found a bug in askpass and could solve it. This explains why cryptdisks_start command doesn't behave the correct way. In fact, askpass doesn't remove the trailing '\n' character at the end of the input. It works for non-blank passwords, but blank passwords still cause trouble. Are you interested in a patch for Debian? Cheers, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768407: Bug solved
Hi again, Actually, I could make it work even with blank passwords (or empty key file provided either directly or through STDIN). I'd like to send you a patch. What is the preferred tool to write a patch for cryptsetup? Best, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
On 18/11/2014 09:39, intrigeri wrote: 1. The proper solution still seems to patch systemd-cryptsetup so that this workaround isn't needed; may you please send your patch upstream? If not, just tell us and I guess someone here will do it :) I sent the patch today. In the meanwhile, is it useful to patch Debian? By the way, what is the proper tool to create a patch for Debian? I read about dpatch, but I was told it's not relevant. 2. If a fix doesn't make it into systemd in Jessie, then I guess we'll want to document this workaround in NEWS.Debian, and make sure the release notes point there. IMO, let's not spend time on #2 right now, and instead focus on #1. All right. Cheers, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: There's also a problem with passphrases on plain mode
Hi intrigeri, First, thanks for your replies and for the links. I have been investigating cryptsetup behavior as you suggested, and I found out that there is also a problem with passphrases in plain mode. I described it here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768407#20 . This one may or may not be systemd-related. Anyway I'll continue to dig into this issue, maybe I can fix it. Best regards, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
Hi again, Actually, I solved the bug pretty easily (thanks to your links) by editing cryptsetup.c file in package systemd. What should we do now? Are you interested in a patch for Debian? Best, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768577: systemd-cryptsetup handles keyfile differently from cryptsetup on plain mode
I could provide a patch so that systemd-cryptsetup behaves the same way
as cryptsetup.
But actually, there is even an easier way to solve this: change the
'hash' parameter in /etc/crypttab to 'plain'.
Doing this, cryptdisks_{start,stop} scripts work well, and so do
systemd-cryptsetup (as it will pass a NULL pointer as hash parameter to
cryptsetup, which is also legacy cryptsetup's way to handle keyfile +
hash in plain mode).
This is the correct /etc/crypttab:
vaioHDpart6c_home /dev/sda6 /root/keys/home.key
cipher=aes-xts-plain64,size=512,hash=plain,offset=0
instead of
vaioHDpart6c_home /dev/sda6 /root/keys/home.key
cipher=aes-xts-plain64,size=512,hash=sha512,offset=0
Note that the hash algorithm sha512 was, in this case, just ignored.
Maybe next versions of cryptsetup will change that.
Of course, don't forget the command:
update-initramfs -k all -u
after changing /etc/crypttab.
Thank you for your help.
Cheers,
Quentin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768407: Passphrase management problem
Hi, I'm currently investigating such kind of trouble on my laptop. During my tests, I created the following plain partition : dd if=/dev/zero of=/test1.loop bs=10M count=1 cryptsetup open --type plain /test1.loop test1 (I enter a blank password by directly typing enter) mkfs.ext2 /dev/mapper/test1 Of course, at this stage, mounting /dev/mapper/test1 succeeds. BUT, then, I type : cryptsetup close test1 cryptdisks_start test1 mount /dev/mapper/test1 /media/TMP this last command fails ! By the way, the /etc/crypttab used for my test contains : test1/test1.loopnonenoauto which has the advantage to take the same default values as cryptsetup (I'm not saying it's good practice not to specify the cipher, hash algo, and so on... anyway...). So I investigated cryptdisks_start script... and I found a solution : dd if=/dev/zero of=/test1.loop bs=10M count=1 /lib/cryptsetup/askpass Damn password bug | cryptsetup --key-file=- open --type plain /test1.loop test1 (I enter a blank password by directly typing enter) mkfs.ext2 /dev/mapper/test1 cryptsetup close test1 cryptdisks_start test1 mount /dev/mapper/test1 /media/TMP THIS works... So, obviously, there is a problem in the passphrase management made by the current cryptsetup version. I encourage you to test the scenario I described. If I can, I'll debug cryptsetup and askpass to find the bug. I hope this can help to solve Clayton's bug, and maybe mine (which I'll report soon as it doesn't involve a passphrase but a key file). Best regards, Quentin PS : By the way, I also upgraded recently from Wheezy to Jessie. This bug is definitely Jessie-related. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710119: initramfs-tools: Installation with dmraid randomly fails to boot
Package: initramfs-tools Version: 0.109.1 Severity: grave Dear Maintainer, I found this bug described very well in bug #699437, but as the author of the bug, I strongly believe that the bug is related to initramfs-tools. My RAID controller is a Silicon Image SiI 3112A SATARaid, configured in RAID1. I strongly encourage you to read the previously mentionned bug report. Basically, my box randomly fails to boot (meaning that sometimes it succeds) on my RAID partition, with the exact same screen as in the bug #688437. I tried to add a rootdelay=5 option, which didn't change anything. I'm not completely sure about that, but it seems that the bug only occurs with kernel 3.2 and not with kernel 2.6. A patch to handle dmraid better would be most appreciated. Best regards, Quentin Lefebvre -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-4-686-pae root=UUID=... ro dmraid=true quiet -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes do_bootloader = no do_initrd = yes link_in_boot = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n COMPRESS=gzip DEVICE= NFSROOT=auto -- /etc/initramfs-tools/update-initramfs.conf update_initramfs=yes backup_initramfs=no -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 Versions of packages initramfs-tools depends on: ii cpio 2.11+dfsg-0.1 ii klibc-utils2.0.1-3.1 ii kmod 9-3 ii module-init-tools 9-3 ii udev 175-7.2 Versions of packages initramfs-tools recommends: ii busybox 1:1.20.0-7 Versions of packages initramfs-tools suggests: ii bash-completion 1:2.0-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710119: Definitely see bug #699437
Sorry for the mistake, please read #699437 instead of #688437. The direct link to the original bug report : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699437 And the direct link to the error screen : http://beilagen.dreael.ch/Diverses/dmraid_Wheezy_Bugs/Boot_Fehler_sporadisch.jpg Best regards, Quentin Lefebvre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699437: Error in /usr/share/initramfs-tools/hooks/dmraid ?
Hi, I have the exact same problem with my Wheezy stable installation. My computer has a Silicon Image SiI 3112 A SATA RAID controller, and also randomly fails to boot. I found a first fix : edit the /usr/share/initramfs-tools/hooks/dmraid file and change the line : force_load dm-raid45 into : force_load dm-raid . This allows to get rid of the message : modprobe: module dm-raid45 not found in modules.dep on kernel 3.2. But with the kernel 2.6, modprobe: module dm-raid not found in modules.dep appears. So maybe both lines are necessary : force_load dm-raid45 force_load dm-raid one for each kernel. But then the bug reproduced with : modprobe: module ehci-hcd not found in modules.dep. modprobe: module uhci-hcd not found in modules.dep. modprobe: module ohci-hcd not found in modules.dep. modprobe: module usbhid not found in modules.dep. So I also added in /usr/share/initramfs-tools/hooks/dmraid : force_load ehci-hcd force_load uhci-hcd force_load ohci-hcd force_load usbhid (maybe /usr/share/initramfs-tools/hooks/dmraid is not the right place for that...) Then the bug reproduced again, but with no modprobe error message. Trying a rootdelay=5 option didn't change anything. At last, I'd like to stress an important point, that is the bug only appears for kernel 3.2. Kernel 2.6 seems to load each time perfectly (at least I had no bug with it yet). Some clues or feedback would be most appreciated. Best regards, Quentin Lefebvre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699437: Modifying GRUB config file
Hi again, I found something new. If I modify my /boot/grub/grub.cfg file as follows : linux vmlinuz... root=/dev/mapper/sil_bia...cdf2 ... instead of linux vmlinuz root=UUID=... ... then the bug doesn't occur anymore. Andreas, could you try this and confirm ? It seems to me that with this syntax, initrd is waiting the /dev/mapper/... device to be ready and set up, while there is a problem with UUIDs. Unfortunately, the grub-update command can not generate the appropriate grub.cfg file. There's still a problem, either in dmraid or kernel-related packages, as UUIDs should work with dmraid (I mean work all the time, and not randomly). Best regards, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710168: grub2: GURB_DISABLE_LINUX_UUID=true not handled properly with /dev/mapper/... (dmraid) devices
Package: grub2 Version: grub-common Severity: important Dear Maintainer, I have trouble to boot Debian Wheezy stable release with a dmraid device, as described in #699437. I may have found a workaround, which is to activate the directive : GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub. Unfortunately, update-grub is generating a grub.cfg file where linux lines mention root=/dev/sdb2 while this should be root=/dev/mapper/sil_biabbhcdccdf2 .. Indeed, my device.map mentions (hd0) /dev/mapper/sil_biabbhcdccdf .. If this bug could be solved, it would help to boot computers with RAID (dmraid) devices. As for now, I have to write the grub.cfg file by hand, which is not a proper solution. Thanks for your astounding work. Best regards, Quentin Lefebvre -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710168: Bug closed ?
Hi, It seems it was a one-time bug. Indeed, now I have modified my grub.cfg by hand, update-grub works fine and writes the good line with linux ... root=/dev/mapper/sil_...2 no more linux ... root=/dev/sdb2 . Sorry for the inconvenience. Best regards, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699437: /etc/default/grub involved
You can try to uncomment the line GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub, and then run update-grub . You should have linux lines with root=/dev/mapper/... in your /boot/grub/grub.cfg file, which seems to solve the bug. Best regards, Quentin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
