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 wi
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 J
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 wrote:
backcrypt /dev/sdb2 none
cipher=aes-cbc-plain,size=256,hash=ripemd160,noauto,
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 par
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
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...@li
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...@lis
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
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
pat
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, i
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 wi
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
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
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/tes
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 UNSUBSC
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, ema
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
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 tha
ld 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
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
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=
21 matches
Mail list logo
