On 10/28/20 10:31 PM, 0xffce wrote:
Dear dm-crypt people,
I have an external USB drive encrypted by LUKS.
After unplugging it during io once, it now always hangs on "waiting for
zero" during decryption.
Could you please instruct me on what I could do?
FYI, here are what I have tried:
$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 3.65 TiB, 4000752599040 bytes, 7813969920 sectors
Disk model: [REDUCTED]
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 8CA64DA5-EE9C-405C-9D9A-3F876AD4308F
Device Start End Sectors Size Type
/dev/sdb1 2048 7813967871 7813965824 3.7T Microsoft basic data
$ sudo cryptsetup -v luksDump /dev/sdb1
LUKS header information for /dev/sdb1
Version: 1
Cipher name: aes
Cipher mode: xts-plain64
Hash spec: sha512
Payload offset: 4096
MK bits: 512
MK digest: 1a fe af 05 7d bc 18 1f 49 69 8b 7e a1 b9 09 f6 cc f9 8b 78
MK salt: 9a 50 9c ec 64 df ef 24 e1 b6 37 80 08 9c ab 2d
70 4f 98 56 d0 6a 1a 57 c5 a0 38 47 43 3b 23 86
MK iterations: 805000
UUID: eacc9933-21e6-4e1e-a92c-bbc4a897e008
Key Slot 0: ENABLED
Iterations: 6522285
Salt: 2f c2 a6 0d c4 1d 49 af 88 f7 d6 45 07 a8 fe 53
3f a2 e1 d1 c2 a0 51 b1 ee 07 fd c9 b9 c7 c8 1d
Key material offset: 8
AF stripes: 4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
Command successful.
$ sudo cryptsetup luksOpen /dev/sdb1 eblock --debug --verbose
# cryptsetup 2.2.2 processing "cryptsetup luksOpen /dev/sdb1 eblock
--debug --verbose"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/sdb1.
# Trying to open and read device /dev/sdb1 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/sdb1.
# Crypto backend (OpenSSL 1.1.1f 31 Mar 2020) initialized in cryptsetup
library version 2.2.2.
# Detected kernel Linux 5.4.0-52-generic x86_64.
# PBKDF pbkdf2-sha256, time_ms 2000 (iterations 0).
# Reading LUKS header of size 1024 from device /dev/sdb1
# Key length 64, device size 7813965824 sectors, header size 4036 sectors.
# Activating volume eblock using token -1.
# Interactive passphrase entry requested.
Enter passphrase for /dev/sdb1:
# Activating volume eblock [keyslot -1] using passphrase.
# dm version [ opencount flush ] [16384] (*1)
# dm versions [ opencount flush ] [16384] (*1)
# Detected dm-ioctl version 4.41.0.
# Detected dm-crypt version 1.19.0.
# Device-mapper backend running with UDEV support enabled.
# dm status eblock [ opencount noflush ] [16384] (*1)
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Reusing open ro fd on device /dev/sdb1
# dm versions [ opencount flush ] [16384] (*1)
# dm status eblock [ opencount noflush ] [16384] (*1)
# Calculated device size is 7813961728 sectors (RW), offset 4096.
# DM-UUID is CRYPT-LUKS1-eacc993321e64e1ea92cbbc4a897e008-eblock
# Udev cookie 0xd4db2cb (semid 5) created
# Udev cookie 0xd4db2cb (semid 5) incremented to 1
# Udev cookie 0xd4db2cb (semid 5) incremented to 2
# Udev cookie 0xd4db2cb (semid 5) assigned to CREATE task(0) with flags
DISABLE_LIBRARY_FALLBACK (0x20)
# dm create eblock CRYPT-LUKS1-eacc993321e64e1ea92cbbc4a897e008-eblock [
opencount flush ] [16384] (*1)
# dm reload eblock [ opencount flush securedata ] [16384] (*1)
# dm resume eblock [ opencount flush securedata ] [16384] (*1)
# eblock: Stacking NODE_ADD (253,3) 0:6 0660 [trust_udev]
# eblock: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4db2cb (semid 5) decremented to 1
# Udev cookie 0xd4db2cb (semid 5) waiting for zero
The debug output above does not look like genuine Fedora 33
installation. Perhaps this particular log is from different distribution
(Ubuntu)?
Anyway, in general this seems like missing/broken udev rules for dm
devices. Could you please report the bug for appropriate downstream
distribution?
For Fedora 33, please use https://bugzilla.redhat.com and provide us
with debug output captured on Fedora 33. There's been some big changes
in Fedora 33 with regards to default installation storage setup and
there may be some bugs wrt to installed udev rules.
What Fedora flavor do you use? Workstation?
Thanks
O.
And it hangs here forever. Even a SIGINT couldn't interrupt it.
Here is the log of udev:
$ sudo service udev status
Oct 28 15:32:36 user systemd-udevd[496]: dm-3: Worker [5144] processing
SEQNUM=9630 is taking a long time
Oct 28 15:34:36 user systemd-udevd[496]: dm-3: Worker [5144] processing
SEQNUM=9630 killed
Oct 28 15:34:36 user systemd-udevd[496]: Worker [5144] terminated by
signal 9 (KILL)
Oct 28 15:34:36 user systemd-udevd[496]: dm-3: Worker [5144] failed
I indeed tried `sudo service udev restart` several times before
decryption but same problem occurs.
I also tried the same command on two different machines, running Ubuntu
20.04 and Fedora 33 respectively.
But they all hang on "waiting for zero".
Thank you!
Best,
0xffce
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
