With recent udev you can try add workaround I tried to write here
https://bugzilla.redhat.com/attachment.cgi?id=431413
(from Fedora equivalent bug https://bugzilla.redhat.com/show_bug.cgi?id=613909 )
Thanks,
Milan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
On 07/09/2010 03:26 PM, Jonas Meurer wrote:
Hey again,
On 09/07/2010 Milan Broz wrote:
On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote:
# WARNING: other process locked internal device
temporary-cryptsetup-18450, retrying remove.
# WARNING: Process PID 18473 (hald-probe-volu) [PPID
reassign 586286 hal
thanks
On 10/07/2010 Γιώργος Πάλλας wrote:
On 07/09/2010 03:26 PM, Jonas Meurer wrote:
On 09/07/2010 Milan Broz wrote:
On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote:
# WARNING: other process locked internal device
temporary-cryptsetup-18450, retrying remove.
#
On 07/08/2010 12:23 PM, Jonas Meurer wrote:
Hey Giorgos,
On 18/06/2010 Giorgos Pallas wrote:
I am experiencing a reproducable behaviour everytime I unlock a LUKS
partition (unrelated with booting).
So:
aris:/home/encmp/gpall# cryptsetup luksOpen /dev/sdb4 dataspace_crypt
Enter
On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote:
# WARNING: other process locked internal device
temporary-cryptsetup-18450, retrying remove.
# WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)]
spying on internal device /dev/dm-4.
Ha! So finally the debug code found
On 07/09/2010 10:59 AM, Milan Broz wrote:
On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote:
# WARNING: other process locked internal device
temporary-cryptsetup-18450, retrying remove.
# WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)]
spying on internal device
Hey again,
On 09/07/2010 Milan Broz wrote:
On 07/09/2010 09:41 AM, Γιώργος Πάλλας wrote:
# WARNING: other process locked internal device
temporary-cryptsetup-18450, retrying remove.
# WARNING: Process PID 18473 (hald-probe-volu) [PPID 1711 (hald-runner)]
spying on internal device
On 07/09/2010 02:26 PM, Jonas Meurer wrote:
But then still the problem is, how should hal distinguish temporary
cryptsetup devices reliably, when '/dev/dm-X' is used? Milan, is there
any better/cheaper solution than a lookup for symlinks in /dev/mapper/*?
this is infamous change which was
Hey Giorgos,
On 18/06/2010 Giorgos Pallas wrote:
I am experiencing a reproducable behaviour everytime I unlock a LUKS
partition (unrelated with booting).
So:
aris:/home/encmp/gpall# cryptsetup luksOpen /dev/sdb4 dataspace_crypt
Enter passphrase for /dev/sdb4:
device-mapper: remove
9 matches
Mail list logo
