Description of problem: While experimenting with lvm, I've got into a state when I cannot deconfigure the things' I've set up. But cryptsetup does not bother to inform that the action has failed. Version-Release number of selected component (if applicable): cryptsetup-1.6.0-1.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. break your encrypted lvm setup 2. cryptsetup close bla 3. echo $? 4. cryptsetup status bla Actual results: [root@kvolny mnt]# cryptsetup close bla [root@kvolny mnt]# echo $? 0 [root@kvolny mnt]# cryptsetup status bla /dev/mapper/bla is active and is in use. type: LUKS1 cipher: - keysize: 0 bits device: (null) offset: 4040 sectors size: 975743032 sectors mode: read/write Expected results: [root@kvolny mnt]# cryptsetup close bla Error: cannot close 'bla' because of ... [root@kvolny mnt]# echo $? 1 Additional info:
Yes, it should return error code. Please attach log with added --debug (cryptsetup close bla --debug) and "dmsetup table bla; dmsetup info -c bla". How did you created/activated that bla device? (Table seems kind of broken from the status).
(In reply to comment #1) > Yes, it should return error code. > > Please attach log with added --debug (cryptsetup close bla --debug) and [root@kvolny sdb]# cryptsetup close bla --debug # cryptsetup 1.6.0 processing "cryptsetup close bla --debug" # Running command close. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device context by device bla. # Initialising device-mapper backend library. # dm version OF [16384] (*1) # dm versions OF [16384] (*1) # Detected dm-crypt version 1.11.0, dm-ioctl version 4.23.0. # Device-mapper backend running with UDEV support enabled. # dm status bla OF [16384] (*1) # Releasing device-mapper backend. # Allocating crypt device (null) context. # Initialising device-mapper backend library. Zařízení nižší úrovně pod šifrovaným zařízením bla zmizelo. # dm table bla OFW [16384] (*1) # Releasing crypt device (null) context. # Releasing device-mapper backend. # Unlocking memory. Příkaz úspěšně vykonán. > "dmsetup table bla; dmsetup info -c bla". 0 975743032 crypt aes-xts-plain 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0 8:18 4040 Name Maj Min Stat Open Targ Event UUID bla 253 2 L--w 2 1 0 CRYPT-LUKS1-a90272ab010f43789b1e43cd98085515-bla > How did you created/activated that bla device? (Table seems kind of broken > from the status). I've used these commands: cryptsetup luksOpen /dev/sdb2 bla vgchange -a y the thing is that running "vgchange -a n" says there are no volume groups but trying the same without step 1(*), it worked for me to call "cryptsetup close" without having to do "vgchange -a n" at first (*) in my case, I got things broken by controller reset - hardware problem, which may be possibly simulated by pulling out the cable
oops, right after submitting I've noticed the translations ... once again for colleagues who do not speak Czech: [root@kvolny sdb]# LANG=C cryptsetup close bla --debug # cryptsetup 1.6.0 processing "cryptsetup close bla --debug" # Running command close. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device context by device bla. # Initialising device-mapper backend library. # dm version OF [16384] (*1) # dm versions OF [16384] (*1) # Detected dm-crypt version 1.11.0, dm-ioctl version 4.23.0. # Device-mapper backend running with UDEV support enabled. # dm status bla OF [16384] (*1) # Releasing device-mapper backend. # Allocating crypt device (null) context. # Initialising device-mapper backend library. Underlying device for crypt device bla disappeared. # dm table bla OFW [16384] (*1) # Releasing crypt device (null) context. # Releasing device-mapper backend. # Unlocking memory. Command successful.
I added upstream issue for it here http://code.google.com/p/cryptsetup/issues/detail?id=149
(In reply to comment #4) > I added upstream issue for it here > http://code.google.com/p/cryptsetup/issues/detail?id=149 thankyou btw, as for the testcase, my problem happens with a broken harddrive which I'm about to return for replacement - would that be worthy to keep it (possibly passing that to you ... if you're stilll nearby :-)) for testing, or is the above output enough?
Fixed in devel git http://code.google.com/p/cryptsetup/source/detail?r=f64064fe71363a14ab0c62359e451f9cdc39dc50# I'll release 1.6.1 soon. For that harddrive - I am not going to RH office anytime soon, perhaps just trash it away... Anyway, thanks. I simulated bug just by removing device node, that's more friendly to my hw :-) (It can be done with USB drive too I think.)
cool, thanks
cryptsetup-1.6.1-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/cryptsetup-1.6.1-1.fc18
Package cryptsetup-1.6.1-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing cryptsetup-1.6.1-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4621/cryptsetup-1.6.1-1.fc18 then log in and leave karma (feedback).
cryptsetup-1.6.1-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.