Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
Hi Jonas, Jonas Meurer wrote (24 Feb 2011 10:56:34 GMT) : But, Debian just began a new release cycle, and the bug isn't too important to fix. Thus I would prefer to wait for a proper fix. I agree we should wait for a proper fix to be found for Wheezy. However, do you intend to apply a workaround, such as udevadm settle, to the luksformat script shipped in the Squeeze package? I can understand this bug is not that important from the point of view of the whole cryptsetup package, luksformat being only a tiny bonus part of it; this is the reason why I initially assigned priority normal to this bug. On the other hand, this script being shipped in $PATH, one may expect it not to be entirely broken: some people have been used to a working luksformat script at least since Lenny was released; had luksformat been shipped in its own package, this bug would have been pretty much RC. Bye -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Then we'll come from the shadows. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
hey Milan, On 22/02/2011 Milan Broz wrote: On 02/22/2011 02:53 PM, Milan Broz wrote: # watch for future changes KERNEL!=sr*, OPTIONS+=watch blah, this is not called for dm devices, moreover there is nowatch set... well, I need to reproduce it to check what is going on here. thanks for your support. I'll wait until you futher debugged the issue before taking any action. In case that you don't have time to work on this right now, I'm happy to add the workaround in the meantime. But, Debian just began a new release cycle, and the bug isn't too important to fix. Thus I would prefer to wait for a proper fix. greetings, jonas signature.asc Description: Digital signature
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
Hey Milan, On 19/02/2011 Milan Broz wrote: On 02/19/2011 04:48 PM, Jonas Meurer wrote: but i guess that the race condition is between libdevmapper and udev. maybe this is related to the outdated devmapper (+udev rules) in debian? on irc someone said that cryptsetup (luksClose) should wait for the device to become free in case that udev sync is enabled. device-mapper udev rules are constructed such way that after cryptsetup operation udev links processing should be finished. (iow dmsetup udevcomplete must be the last udev rule which manipulates with these links. Debian breaks it by reordering udev rules.) first the good news: Bastian finally uploaded latest lvm2 and device-mapper upstream to debian unstable. the udev rules are still slightly different from upstream, but I believe that they're at least more common than in the past. (There is still race with watch udev rule but AFAIK only udisks using that - but this is not the case here.) Sorry but I cannot help here until Debian maintaner wakes up and updates lvm/device-mapper udev rules. The changed Debian udev device-mapper rules are not supported by upstream. now the bad news: i'm still able to reproduce the bug with recent versions of lvm2 and device-mapper. I even replaced the debian udev rules by the upstream ones (LVM2.2.02.84/udev) restarted udev, and unfortunately still was able to reproduce the bugreport. It seems like now the luksClose error device is busy occurs less often than before, but i'm still able to reproduce it something like 3 out of 10 tries. (You can add udevadm settle instead of sleep 1, but all these hacks are workarounds which are not needed with upstream.) i fear that workarounds like this are still needed. do you have any suggestion what to do about it? i'm really not enough into udev magic to work on race conditions like this, but i'd at least like to forward this to the right adress to increase the chance that it will be fixed once. greetings, jonas signature.asc Description: Digital signature
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
On 02/22/2011 02:22 PM, Jonas Meurer wrote: now the bad news: i'm still able to reproduce the bug with recent versions of lvm2 and device-mapper. I even replaced the debian udev rules by the upstream ones (LVM2.2.02.84/udev) restarted udev, and unfortunately still was able to reproduce the bugreport. It seems like now the luksClose error device is busy occurs less often than before, but i'm still able to reproduce it something like 3 out of 10 tries. I probably misinterpreted the bug. So, luksformat cals: cryptsetup luksFormat cryptsetup luksOpen x mkfs x cryptsetup luksClose And the last luksClose fails with device busy? If so: Are there some WATCH rules? (I see this one in Debian) # watch for future changes KERNEL!=sr*, OPTIONS+=watch So, after mkfs id finished, it closes device and watch rule triggers udev scan (it uses inotify on read-write close). This scan is not related to lvm udev, it is asynchronout device scan (to create various uuid links etc). Unfortunately it locks device for some time, so if it is not quick enough, following luksClose fails. You can verify it by commenting this watch rules out - then it should work without any sleep. I am afraid that in this case you must use udevadm settle before luksClose, this is just wonderful world of udev watch... (I think that mkfs should generate change event to fix uuid links and do not rely on these asynchronous hacks but I know that udev/udisks upstream disagrees here:-) Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
On 02/22/2011 02:53 PM, Milan Broz wrote: # watch for future changes KERNEL!=sr*, OPTIONS+=watch blah, this is not called for dm devices, moreover there is nowatch set... well, I need to reproduce it to check what is going on here. Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
Hey intrigeri, On 30/10/2010 intrig...@boum.org wrote: Hi, # ls -l /dev/mapper/luksformat1 ls: cannot access /dev/mapper/luksformat1: No such file or directory # luksformat /dev/sdb1 Creating encrypted device on /dev/sdb1... WARNING! This will overwrite data on /dev/sdb1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: Verify passphrase: Please enter your passphrase again to verify it Enter passphrase for /dev/sdb1: mkfs.vfat 3.0.9 (31 Jan 2010) unable to get drive geometry, using default 255/63 Device luksformat1 is busy. # ls -l /dev/mapper/luksformat1 lrwxrwxrwx 1 root root 8 Oct 30 18:23 /dev/mapper/luksformat1 - ../dm-11 mh, seems like another race condition. the device is still busy when mkfs.vfat terminates. a workaround like sleep 1 in between would work, but i would prefer to find the reason for this race condition and fix it. milan, maybe you could take a look at this? unfortunately i don't know enough udev/devmapper details to further debug this issue. but i guess that the race condition is between libdevmapper and udev. maybe this is related to the outdated devmapper (+udev rules) in debian? on irc someone said that cryptsetup (luksClose) should wait for the device to become free in case that udev sync is enabled. greetings, jonas signature.asc Description: Digital signature
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
On 02/19/2011 04:48 PM, Jonas Meurer wrote: but i guess that the race condition is between libdevmapper and udev. maybe this is related to the outdated devmapper (+udev rules) in debian? on irc someone said that cryptsetup (luksClose) should wait for the device to become free in case that udev sync is enabled. device-mapper udev rules are constructed such way that after cryptsetup operation udev links processing should be finished. (iow dmsetup udevcomplete must be the last udev rule which manipulates with these links. Debian breaks it by reordering udev rules.) (There is still race with watch udev rule but AFAIK only udisks using that - but this is not the case here.) Sorry but I cannot help here until Debian maintaner wakes up and updates lvm/device-mapper udev rules. The changed Debian udev device-mapper rules are not supported by upstream. (You can add udevadm settle instead of sleep 1, but all these hacks are workarounds which are not needed with upstream.) Milan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601886: [pkg-cryptsetup-devel] Bug#601886: cryptsetup: luksformat leaves the Luks device open
Hello Milan, hey Bastian, first thanks for your comments, Milan. On 19/02/2011 Milan Broz wrote: On 02/19/2011 04:48 PM, Jonas Meurer wrote: but i guess that the race condition is between libdevmapper and udev. maybe this is related to the outdated devmapper (+udev rules) in debian? on irc someone said that cryptsetup (luksClose) should wait for the device to become free in case that udev sync is enabled. device-mapper udev rules are constructed such way that after cryptsetup operation udev links processing should be finished. (iow dmsetup udevcomplete must be the last udev rule which manipulates with these links. Debian breaks it by reordering udev rules.) (There is still race with watch udev rule but AFAIK only udisks using that - but this is not the case here.) Sorry but I cannot help here until Debian maintaner wakes up and updates lvm/device-mapper udev rules. The changed Debian udev device-mapper rules are not supported by upstream. Bastian, could you comment on your future plans for lvm2/devmapper? Do you intend to package recent upstream, and replace the custom debian udev rules by the upstream ones? If that's not the case, please elaborate on why you don't intend to sync with the upstream udev rules. (You can add udevadm settle instead of sleep 1, but all these hacks are workarounds which are not needed with upstream.) I'm happy to add this workaround as a temporary solution. But in the long term I'd rather prefer to see these race condition fixed than circumvented. greetings, jonas signature.asc Description: Digital signature
