Actually my script is only working sometimes. Sometimes dmsetup fails to remove the device and says 'ioctl device is busy'. When I try to enquire into which process is using the LUKS volume, it doesn't show any. I have confirmed that the LUKS volume isn't listed in '/proc/mounts', so it's definitely not mounted. Even if I use the '--force' option with dmsetup, it still fails to remove the node from '/dev/mapper'. I have tried deleting the node myself with 'rm /dev/mapper/monkeydisk', and while this succeeds in removing the node from the Linux file system, it still doesn't allow me to open the LUKS volume again with 'cryptsetup luksOpen' (it comes back with the error 'Device already open'). So is there anything more I can do to forcefully close the LUKS volume and remove the node from '/dev/mapper', so that I can then go on to re-open the LUKS volume and re-mount it? (I of course realise that the user shouldn't be spontaneously pulling out the SDcard while it's still mounted, but I'm trying to make the best of a bad situation here). Sent: Wednesday, January 20, 2021 at 4:07 PM > From: "Frederick Gotham" <thomas123@xxxxxx> > To: dm-crypt@xxxxxxxx > Cc: gmazyland@xxxxxxxxx > Subject: Re: 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" <gmazyland@xxxxxxxxx> > To: "Frederick Gotham" <thomas123@xxxxxx>, dm-crypt@xxxxxxxx > Subject: 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 dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
