Re: [dm-crypt] Recover from Spontaneous Ejection

In my UDEV script that handles the spontaneous ejection of SDcards, I have replaced "cryptsetup luksClose" with "dmsetup remove --force".

This solution worked, thanks Milan.

Of course ideally I don't want the user to spontaneously remove the SDcard from the slot without unmounting it first, but at least I can make a good attempt to recover from this scenario.

Sent: Wednesday, January 20, 2021 at 11:23 AM

From: "Milan Broz" <[email protected]>

To: "Frederick Gotham" <[email protected]>, [email protected]

Subject: Re: [dm-crypt] 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