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 dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
