A mkfs.btrfs error: "ERROR: error during mkfs: Operation not permitted" when formating an encrypted (LUKS) disk with BTRFS format

I bought an external SSD (2 Tera Byte), called “WD My Passport SSD 2TB Mobile SSD Storage”.

I am trying to encrypt with LUKS and format the storage device with BTRFS format on Fedora Linux 39. I referred to Fedora’s document[1], and my past article blog article about encrypting and encrypting with LUKS and formatting 1 TB HDD with BTRFS[2].

Then I got an error. Let me explain it.

As an initial state, the SSD was detected as /dev/sda1 with the label by the lsblk command.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
...
/dev/sda disk   1.8T
/dev/sda1 part exfat BAB8-C8F1 1.8T My\x20Passport
...

Following the [1], as preparation before formatting the SSD, I filled random data into the storage device.

$ sudo badblocks -c 10240 -s -w -t random -v /dev/sda1

Then, I formatted the storage device.

$ sudo cryptsetup luksFormat /dev/sda1
...
Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/sda1:
Verify passphrase:
...

Then, I created a mapping to allow access to the device’s decrypted contents.

$ sudo cryptsetup luksUUID /dev/sda1
c522db23-e751-4fa6-a9a6-a45dc06878fc

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc

Below is the information about the mapped device.

$ sudo dmsetup info luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Name:              luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
State:             ACTIVE
Read Ahead:        4096
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1
UUID: CRYPT-LUKS2-c522db23e7514fa6a9a6a45dc06878fc-luks-c522db23-e751-4fa6-a9a6-a45dc06878fc

Then I got the following error when trying to format the storage with BTRFS.

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.7.1
See https://btrfs.readthedocs.io for more information.

NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)
ERROR: error during mkfs: Operation not permitted

Now I noticed the /dev/sda and /dev/sda1 lines disappeared in the output of the following lsblk command.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL

Do you have any ideas about how to fix the error by the above mkfs.btrfs command?

Thanks for your help!

I rebooted the OS. The /dev/sda and /dev/sda1 appeared again by the lsblk command.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live
$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

The lsblk still showed the /dev/sda and /dev/sda1.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc crypt   1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Another error “ERROR: superblock magic doesn’t match” was printed with the “ERROR: error during mkfs: Operation not permitted”.

$ ls -l /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
lrwxrwxrwx. 1 root root 7 Sep 27 23:25 /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc -> ../dm-1

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.7.1
See https://btrfs.readthedocs.io for more information.

ERROR: superblock magic doesn't match
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)


ERROR: error during mkfs: Operation not permitted

The /dev/sda and /dev/sda1 disappeared.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Added btrfs

btrfs-progs 6.7.1 is kinda old, current Fedora 39 btrfs-progs is 6.11. Maybe there’s a bug that’s been fixed since the older version? I suggest dnf update or at least make sure kernel, btrfs-progs, and cryptsetup are all up to date.

If you still get the error, looks to me like the drive is vanishing off the USB bus for some reason. Please run this command:

journalctl -k -o short-monotonic --no-hostname | fpaste

And post the URL.

Thanks for your advice! For the record, I was using the following packages. I will upgrade, and try it again.

$ uname -r
6.7.9-200.fc39.x86_64

$ rpm -q kernel
kernel-6.4.15-200.fc38.x86_64
kernel-6.7.9-100.fc38.x86_64
kernel-6.7.9-200.fc39.x86_64

$ rpm -q btrfs-progs
btrfs-progs-6.7.1-1.fc39.x86_64

$ rpm -q cryptsetup
cryptsetup-2.6.1-3.fc39.x86_64

Also, I’m curious if mkfs.ext4 works? Or if the USB drive also vanishes following that command?

Still another idea is to use mkfs.btrfs -vvv --nodiscard and see if that works? And if not the multiple v’s will add some verbose messages, hopefully providing a hint why it fails.

I ran the dnf upgrade and restarted the OS. Then below are the RPM packages.

$ uname -r
6.10.11-100.fc39.x86_64

$ rpm -q kernel
kernel-6.7.9-100.fc38.x86_64
kernel-6.7.9-200.fc39.x86_64
kernel-6.10.11-100.fc39.x86_64

$ rpm -q btrfs-progs
btrfs-progs-6.10.1-1.fc39.x86_64

$ rpm -q cryptsetup
cryptsetup-2.6.1-3.fc39.x86_64

Then I got the same error with the previous one below.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

$ sudo cryptsetup luksUUID /dev/sda1
c522db23-e751-4fa6-a9a6-a45dc06878fc

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

$ sudo dmsetup info luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Name:              luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
State:             ACTIVE
Read Ahead:        4096
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 1
Number of targets: 1
UUID: CRYPT-LUKS2-c522db23e7514fa6a9a6a45dc06878fc-luks-c522db23-e751-4fa6-a9a6-a45dc06878fc

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.10.1
See https://btrfs.readthedocs.io for more information.

ERROR: superblock magic doesn't match
Performing full device TRIM /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc (1.82TiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)


ERROR: error during mkfs: Operation not permitted

The journal log is https://paste.centos.org/view/64d732d5.

$ journalctl -k -o short-monotonic --no-hostname | fpaste

https://paste.centos.org/view/64d732d5

I rebooted the OS before trying the following commands with the mkfs.ext4. It didn’t work as well with showing an error.

First, after rebooting the OS, I inserted the external SSD, and confirmed that /dev/sda and /dev/sda1 existed.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Then I ran the cryptsetup luksOpen.

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

The mkfs.ext4 finished with an error.

$ rpm -qf /usr/sbin/mkfs.ext4
e2fsprogs-1.47.0-2.fc39.x86_64

$ sudo mkfs.ext4 /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 488365844 4k blocks and 122093568 inodes
Filesystem UUID: d0ccad7d-be2e-407a-8299-cb0e608cf940
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
	102400000, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: mkfs.ext4: Input/output error while writing out and closing file system

$ echo $?
1

The /dev/sda and /dev/sda1 disappeared from the output of the lsblk.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

Below is the link to the journalctl.

$ journalctl -k -o short-monotonic --no-hostname | fpaste
Uploading (131.7KiB)...
https://paste.centos.org/view/257d05be

OK. I tried the command too below.

First, I rebooted the OS to show the /dev/sda and /dev/sda1 in the result of the lsblk, and ran the cryptsetup luksOpen.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

$ sudo cryptsetup luksOpen /dev/sda1 luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
Enter passphrase for /dev/sda1:

Then I got the following error “checksum verify failed”.

$ sudo mkfs.btrfs -L my-passport-ssd-2tb -vvv --nodiscard /dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc
btrfs-progs v6.10.1
See https://btrfs.readthedocs.io for more information.

NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

checksum verify failed on 1081344 wanted 0xf6e2b79f found 0xefa6c526
ERROR: cannot read chunk root
ERROR: open ctree failed

$ echo $?
1

The journal log is below.

$ journalctl -k -o short-monotonic --no-hostname | fpaste
Uploading (121.0KiB)...
https://paste.centos.org/view/43049829

Interestingly, the /dev/sda and /dev/sda1 still appear after the above commands.

$ lsblk -r -p -o NAME,TYPE,FSTYPE,UUID,SIZE,LABEL
NAME TYPE FSTYPE UUID SIZE LABEL
/dev/sda disk   1.8T
/dev/sda1 part crypto_LUKS c522db23-e751-4fa6-a9a6-a45dc06878fc 1.8T
/dev/mapper/luks-c522db23-e751-4fa6-a9a6-a45dc06878fc crypt   1.8T
/dev/zram0 disk   8G
/dev/nvme0n1 disk   1.8T
/dev/nvme0n1p1 part vfat D0B0-4455 600M
/dev/nvme0n1p2 part ext4 1072bb16-2ca1-4502-8bda-750ad467f25f 1G
/dev/nvme0n1p3 part crypto_LUKS 09538e5a-f802-40a6-bc22-328604dc2312 1.8T
/dev/mapper/luks-09538e5a-f802-40a6-bc22-328604dc2312 crypt btrfs be430ab5-ebda-4f4f-a01e-427d18fb12f1 1.8T fedora_localhost-live

First indication of a device or connection problem:

[15545.899008] kernel: scsi 0:0:0:1: Failed to get diagnostic page 0x1
[15545.899013] kernel: scsi 0:0:0:1: Failed to bind enclosure -19
[15545.899028] kernel: ses 0:0:0:1: Attached Enclosure device
[16019.641158] kernel: sd 0:0:0:0: [sda] tag#20 uas_eh_abort_handler 0 uas-tag 21 inflight: CMD OUT 
[16019.641174] kernel: sd 0:0:0:0: [sda] tag#20 CDB: Write(10) 2a 00 00 00 95 d0 00 00 06 00

[16021.998089] kernel: scsi host0: uas_eh_device_reset_handler start

[16041.271039] kernel: scsi host0: uas_eh_device_reset_handler FAILED err -19
[16041.271049] kernel: sd 0:0:0:0: Device offlined - not ready after error recovery

This gist of all that is the device it confused and stops responding. That’s why it works after a reboot, or if you just unplug the device from USB and then plug it back in.

What’s the solution? Well, I’m not sure if this is a uas incompatibility problem, or a bus power problem. You might have to try both.

I use an externally powered hub for my USB drives in enclosures and it solved all problems. But it’s possible in your case that won’t work, so I suggest borrowing a powered USB hub to see if it fixes the problem or not before you buy one.

Another possibility is disabling UAS. It’s possible to disable it entirely for all devices, or set a quirk for the specific drive you’re working with, and then uas is only disabled for that device.

More here:

1 Like

Hi, thanks for your help and guidance!

After seeing your comment, just in case, I ran the commands again to create LUKS format for the SSD from the badblocks command again, and I also tried running the mkfs.btrfs command on another Laptop. But the result was the same, showing the same error.

My original report was on my Framework Laptop 13 Intel 11 Gen. Now I tried the mkfs.btrfs command on my other laptop Lenovo X1 Carbon. In both laptops, Fedora Linux 39 and the btrfs-progs-6.10.1-1.fc39.x86_64 are installed.

I will try what you told me. I will borrow or buy a powered USB hub. For “a possible uas incompatibility problem”, did you mean it was an incompatibility of the USB interface device or the SSD storage device?

Do you think trying with a powered USB hub may solve both “a uas incompatibility problem, and a bus power problem”?

I noticed that the btrfs-progs’s new version 6.11 RPM was released on Fedora 39,[1][2]. So, install and tried it. However, the mkfs.btrfs command failed with the same error.

$ rpm -q btrfs-progs
btrfs-progs-6.11-1.fc39.x86_64

I’m not a USB expert, but a feature of USB hubs is they “normalize” the command and data streams between host and device. I can’t tell from the errors if these are UAS errors or insufficient power supply errors.

It’s probably easier to figure out how to disable the UAS driver (just blacklist the driver) than borrow a USB hub. But try one, if that doesn’t work then try the other.

As a suggestion, you could use the entire disk instead of a partition: /dev/sda instead of /dev/sda1. It should not matter here, but as the current setup is not working for you and that’s what I usually do, it might be worth a try. Note that this will erase all the other partitions on the disk.

All right.

I bought a USB hub + universal power adapter at a local electrical shop. I tried to use these ones now. However, I feel a smell of smoke from the hole in the USB hub. Perhaps, the combination between the USB hub and universal power adapter was bad. So, I may go to the electrical shop to ask again.

Thanks for your suggestion!

Does that mean I can run the commands from the badblocks command with /dev/sda in my above steps like this?

$ sudo badblocks -c 10240 -s -w -t random -v /dev/sda

badblocks is an e2fsprogs utility that’s really intended for (spinning) hard drive.

I think you’d prefer the f3 package in Fedora repo. The basic strategy is:

  1. mount the file system on the drive you want to test (assumes it’s formatted already, and it doesn’t matter what the file system is)
  2. f3write /path/to/mountpoint
  3. f3read /path/to/mountpoint

The f3 documentation details the purpose, but it will check for things other than just defective media.

Sounds like bad luck. Or maybe just return it.

In the meantime, try this to disable the UAS driver for this drive and see if that helps.

Yes, I returned the USB hub. Thanks for the advice.

I tried the instruction “Disabling UAS - Manually reload the kernel module (temporary)” on the How to disable USB Attached Storage (UAS) - Leo's Notes . However, I still see the error log.

Below is my command log.

According to the result of the lsusb, the device ID is 1058:264f.

$ lsusb
...
Bus 002 Device 002: ID 1058:264f Western Digital Technologies, Inc. My Passport 264F
...

First, I got the following error with the expansion cards (USB type-C interfaces on Framework Laptop).

$ sudo rmmod usb-storage
rmmod: ERROR: Module usb_storage is in use by: uas

After removing all the expansion cards, and rebooting the OS, I got the following error.

$ sudo rmmod usb-storage
rmmod: ERROR: Module usb_storage is not currently loaded

It seemed that the usb_storage was not loaded.

$ sudo lsmod | grep usb_storage
=> empty

I executed the following command.

$ sudo modprobe usb-storage quirks=1058:264f:u

The following dmesg command on another terminal showed the following output.

$ sudo dmesg --follow-new
[  378.935509] usbcore: registered new interface driver usb-storage

Then I tried to format the disk with BTRFS. Once I tried to format with exfat, and failed. I need to run the mkfs.btrfs -f option. Then I got the following error.

$ sudo cryptsetup luksUUID /dev/sda1
35b57833-b9f7-4f09-871a-483453831949

$ sudo cryptsetup luksOpen /dev/sda1 luks-35b57833-b9f7-4f09-871a-483453831949
Enter passphrase for /dev/sda1:

$ sudo mkfs.btrfs -L my-passport-ssd-2tb /dev/mapper/luks-35b57833-b9f7-4f09-871a-483453831949
btrfs-progs v6.11
See https://btrfs.readthedocs.io for more information.

ERROR: /dev/mapper/luks-35b57833-b9f7-4f09-871a-483453831949 appears to contain an existing filesystem (exfat)
ERROR: use the -f option to force overwrite of /dev/mapper/luks-35b57833-b9f7-4f09-871a-483453831949

$ sudo mkfs.btrfs -f -L my-passport-ssd-2tb /dev/mapper/luks-35b57833-b9f7-4f09-871a-483453831949
btrfs-progs v6.11
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/mapper/luks-35b57833-b9f7-4f09-871a-483453831949 (1.82TiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

ERROR: error during mkfs: Operation not permitted

The sudo dmesg --follow-new outputted the following result during the mkfs.btrfs.

[  923.007086] usb 2-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[  953.214751] usb 2-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[  988.923181] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[  994.555336] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[  994.763032] usb 2-1: device not accepting address 2, error -62
[ 1000.187277] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[ 1005.819187] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[ 1006.027146] usb 2-1: device not accepting address 2, error -62
[ 1011.451093] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[ 1017.083272] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[ 1017.291087] usb 2-1: device not accepting address 2, error -62
[ 1022.715035] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[ 1028.347033] xhci_hcd 0000:00:0d.0: Timeout while waiting for setup device command
[ 1028.554893] usb 2-1: device not accepting address 2, error -62
[ 1028.571761] usb 2-1: USB disconnect, device number 2
[ 1028.571833] sd 0:0:0:0: Device offlined - not ready after error recovery
[ 1028.572026] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK cmd_age=105s
[ 1028.572031] sd 0:0:0:0: [sda] tag#0 CDB: Write(10) 2a 00 e8 df 7b 09 00 05 98 00
[ 1028.572034] I/O error, dev sda, sector 3906960137 op 0x1:(WRITE) flags 0x800 phys_seg 1432 prio class 2
[ 1028.572052] Buffer I/O error on dev dm-1, logical block 3906925321, lost async page write
[ 1028.572058] Buffer I/O error on dev dm-1, logical block 3906925322, lost async page write
[ 1028.572062] Buffer I/O error on dev dm-1, logical block 3906925323, lost async page write
[ 1028.572065] Buffer I/O error on dev dm-1, logical block 3906925324, lost async page write
[ 1028.572068] Buffer I/O error on dev dm-1, logical block 3906925325, lost async page write
[ 1028.572072] Buffer I/O error on dev dm-1, logical block 3906925326, lost async page write
[ 1028.572075] Buffer I/O error on dev dm-1, logical block 3906925327, lost async page write
[ 1028.572094] Buffer I/O error on dev dm-1, logical block 3906925328, lost async page write
[ 1028.572098] Buffer I/O error on dev dm-1, logical block 3906925329, lost async page write
[ 1028.572103] Buffer I/O error on dev dm-1, logical block 3906925330, lost async page write

After the above error, I ran the following commands. There was no entry about the SSD. And the usb_storage was loaded with “2 uas”. Not sure why it is “2 uas” rather than “1 uas”.

$ sudo lsmod | grep usb_storage
usb_storage            90112  2 uas
$ lsusb -tv
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/12p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 007: Dev 002, If 0, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 007: Dev 002, If 1, Class=Video, Driver=uvcvideo, 480M
        ID 0bda:5634 Realtek Semiconductor Corp.
    |__ Port 009: Dev 003, If 0, Class=Vendor Specific Class, Driver=[none], 12M
        ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd.
    |__ Port 010: Dev 004, If 0, Class=Wireless, Driver=btusb, 12M
        ID 8087:0032 Intel Corp. AX210 Bluetooth
    |__ Port 010: Dev 004, If 1, Class=Wireless, Driver=btusb, 12M
        ID 8087:0032 Intel Corp. AX210 Bluetooth
/:  Bus 004.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub