Re: Recover from Spontaneous Ejection

On 20/01/2021 12:06, Frederick Gotham wrote:
> 
> I'm developing a product running embedded Linux.
> 
> We have an SDcard with one partition on it, and this partition is an
> encrypted LUKS volume.
> 
> While the SDcard is mounted, the user can spontaneously eject the
> SDcard. I have successfully altered the UDEV script to handle this
> eventuality, as follows:
> 
> umount /mnt/sdcard cryptsetup luksClose cryptocard
> 
> Then when the user re-inserts the SDcard after a spontaneous
> ejection, I try to re-mount it again. So the entire process from
> start to finish goes as follows:
> 
> echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard - mount
> /dev/mapper/cryptocard /mnt/sdcard [ User spontaneously ejects SDcard
> ] umount /mnt/sdcard cryptsetup luksClose cryptocard [ ... ... ... 1
> minute goes by ... ... ... ] [         User re-inserts SD card
> ] echo -n password | cryptsetup luksOpen /dev/sdb1 cryptocard - mount
> /dev/mapper/cryptocard /mnt/sdcard
> 
> This appears to work just fine, however when I try to do more complex
> write operations, it starts to freak out a little (files that were
> previously visible are no longer visible). When I reboot the machine,
> everything's working fine again.
> 
> So it seems that the system is not adequately recovering from the
> spontaneous ejection of the SDcard. Do I need to somehow "flush out"
> the LUKS system in order to successfully re-mount the volume? Is it
> possible to 'restart' the LUKS subsystem to get this to work properly
> again? I only ever have one LUKS volume open at a time so I don't
> have to worry about closing other volumes before 'flushing out'.

There is nothing like LUKS subsystem running - it is only kernel dm-crypt
configuration that need to be removed. Cryptsetup can only wait here for kernel.

What you see here is probably that something in kernel is blocking the dm-device
until some timeout expires (see lsblk; dmsetup info).

You can try to use "dmsetup remove --force <name>" instead of luksClose here
(that will try to replace dm-crypt with error target if there are active users,
that should fail more quickly).

For the flush - there is nothing to flush, underlying device already disappeared.
You should see the same problem even without LUKS/dmcrypt.

If you see this more often, perhaps report it to the distribution,
if it is your own distro, then you need to setup udev/kernel properly.

Milan
_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt