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" <gmazyland@gmail.com>
To: "Frederick Gotham" <thomas123@gmx.ca>, dm-crypt@saout.de
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