Re: [dm-crypt] cryptsetup hangs on "waiting for zero"

[Ondrej Kozina <okozina@redhat.com>]

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