Bug 911106
| Summary: | cryptsetup fails silently | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Karel Volný <kvolny> |
| Component: | cryptsetup | Assignee: | Milan Broz <gmazyland> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | agk, gmazyland, okozina |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-04-05 23:10:46 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Karel Volný
2013-02-14 11:38:18 UTC
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. |