Greetings,
Using an external usb 2 hdd with recent kernels with cryptsetup containers that
contain lvm volumes.
After a suspend/resume cycle, with active lvm volumes, the mounted fs is "offline",
the dm-* devices don't respond to commands issued. No more access possible.
Have to reboot to free the devices.
Someone ever experienced that? Ideas to fix?
Thanks,
Nils
On 07/25/2010 06:06 PM, Nils Radtke wrote:
> Using an external usb 2 hdd with recent kernels with cryptsetup containers that
> contain lvm volumes.
>
> After a suspend/resume cycle, with active lvm volumes, the mounted fs is "offline",
> the dm-* devices don't respond to commands issued. No more access possible.
>
> Have to reboot to free the devices.
I guess it is not dm/block layer problem but USB related - can you check syslog if
the device is not attached after resume with another major:minor?
If this happens - you can free the mappings using dmsetup:
- try to force umount fs (if mounted), then run "dmsetup table" and manually remove
orphaned mappings using "dmsetup remove".
Milan
Hi,
Thanks for your answer.
On Sun 2010-07-25 @ 11-00-49PM +0200, Milan Broz wrote:
# On 07/25/2010 06:06 PM, Nils Radtke wrote:
#
# > Using an external usb 2 hdd with recent kernels with cryptsetup containers that
# > contain lvm volumes.
# >
# > After a suspend/resume cycle, with active lvm volumes, the mounted fs is "offline",
# > the dm-* devices don't respond to commands issued. No more access possible.
# >
# > Have to reboot to free the devices.
#
# I guess it is not dm/block layer problem but USB related - can you check syslog if
# the device is not attached after resume with another major:minor?
I'm not sure I can map this to what happened here.
What I can tell is, a plain usb conn survives nowadays (there were kernels in the days
of 200x where x < 8 when usb didn't survive) suspend/resume cycles.
It is as well working with a usb + cryptsetup (w/o lvm): survives suspend/resume.
However usb + cryptsetup + lvm does not survive as of these days.
# If this happens - you can free the mappings using dmsetup:
# - try to force umount fs (if mounted), then run "dmsetup table" and manually remove
# orphaned mappings using "dmsetup remove".
That's what I tried and failed gloriously. I'm trying to revive my memory about the
situation: fs could be unmounted, however, the cryptsetup luksClose failed (IRC) and
therefore the dmsetup remove consequently failed also.
These experiences let me to the conclusion that there might be some issue
regarding dmsetup in the ensemble of usb + cryptsetup + lvm.
Thanks for your opinion,
Nils
On 07/26/2010 03:06 PM, Nils Radtke wrote:
> That's what I tried and failed gloriously. I'm trying to revive my memory about the
> situation: fs could be unmounted, however, the cryptsetup luksClose failed (IRC) and
> therefore the dmsetup remove consequently failed also.
So instead of "cryptsetup luksClose" use dmsetup remove for crypt device too
(There was a bug in some version of cryptsetup which failed close if underlying device
disappeared, should be fixed in >=1.1.2, anyway "dmsetup remove" is low-level equivalent.)
Also see man page and "dmsetup remove -f" flag.
The usb device reinitialization is separate problem, maybe someone can help if you provide
more logs.
Milan
Hi Milan,
Thank you for your explanation.
So I'll try to find logs regarding this issue (won't be easy though..).
On the other hand, the usb device survives suspend/resume normally, that is,
when using a plain disk, std partition etc.
Ok, I'm going for the logs and if found be back.
Thank you again for your help.
Nils
On Mon 2010-07-26 @ 03-22-45PM +0200, Milan Broz wrote:
# On 07/26/2010 03:06 PM, Nils Radtke wrote:
# > That's what I tried and failed gloriously. I'm trying to revive my memory about the
# > situation: fs could be unmounted, however, the cryptsetup luksClose failed (IRC) and
# > therefore the dmsetup remove consequently failed also.
#
# So instead of "cryptsetup luksClose" use dmsetup remove for crypt device too
# (There was a bug in some version of cryptsetup which failed close if underlying device
# disappeared, should be fixed in >=1.1.2, anyway "dmsetup remove" is low-level equivalent.)
#
# Also see man page and "dmsetup remove -f" flag.
#
# The usb device reinitialization is separate problem, maybe someone can help if you provide
# more logs.
#
# Milan