luksFormat damaged my USB flash drive ?! or I did ?!

[avocatux]

What's up people of linux?!

I will be really grateful if someone can help me to figure out what hell happened with my usb flash drive, if it was my mistake or I can blame luksFomat and/or other things.

Maybe it is more related to a hardware problem. But I believe all the trouble initiated with cryptsetup luksFormat command.


I decided to encrypt my pretty new Kingston Datatraveler 3.0 64GB. When I plugged my 3.0 USB device in the 3.0 USB port, the 5.10.0-18-amd64 [5.10.140-1] x86_64 bits kernel, from linux MX-21.2.1_KDE_x64, logged the lines below.

Apr 13 17:53:08 mx kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 6 using xhci_hcd
Apr 13 17:53:08 mx kernel: usb 4-1: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.00
Apr 13 17:53:08 mx kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 13 17:53:08 mx kernel: usb 4-1: Product: DataTraveler 3.0
Apr 13 17:53:08 mx kernel: usb 4-1: Manufacturer: Kingston
Apr 13 17:53:08 mx kernel: usb 4-1: SerialNumber: E0D55EA58ABCE671E94A01BB
Apr 13 17:53:08 mx kernel: usb-storage 4-1:1.0: USB Mass Storage device detected
Apr 13 17:53:08 mx kernel: scsi host2: usb-storage 4-1:1.0
Apr 13 17:53:09 mx kernel: scsi 2:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
Apr 13 17:53:09 mx kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0
Apr 13 17:53:09 mx kernel: sd 2:0:0:0: [sda] 120933440 512-byte logical blocks: (61.9 GB/57.7 GiB)
Apr 13 17:53:09 mx kernel: sd 2:0:0:0: [sda] Write Protect is off
Apr 13 17:53:09 mx kernel: sd 2:0:0:0: [sda] Mode Sense: 2b 00 00 08
Apr 13 17:53:09 mx kernel: sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Apr 13 17:53:10 mx kernel: sda: sda1 sda2
Apr 13 17:53:10 mx kernel: sd 2:0:0:0: [sda] Attached SCSI removable disk

Before the encryption, I ran ...

dd if=/dev/zero of=/dev/sdX* status=progress

*(where X was the letter of my Kingston usb).

I made this decision because I used this device before to carry some personal data a few times. At this point this device was carrying a live distro.

I let dd run until it reached the position of 10GB because it was taking too much of my time. So, I stopped dd with ctrl+c combination. Until this point nothing weird was happening. The file manager kept showing my Kingston in the devices list.


Here is where the bad thing started to happen. After reading some linux sites and watched some youtube videos, I decided to encrypt my Kingston device with the following commands:

cryptsetup luksFormat -y -v /dev/sdX

... and I pressed the Enter key. The cursor went to the next line blinking, and stayed like this for the next 5 seconds or something. I thought cryptsetup was taking too much time just to ask me if I want to proceed. So, I pressed ctrl+c to stop. But nothing happened, the cursor kept blinking in the line below of the cryptsetup command. I decided to press the combination of ctrl+c two more times. After 3 seconds or something, cryptsetup showed the warning "this will overwrite the data on /dev/sdX irrevocably". I answered no because I was thinking in run the cryptsetup command again after all those ctrl+c and delays. From my enter to run the cryptsetup command, pressing ctrl+c 3 times, receiving the warning from the command and answering no, took no more than 10 seconds.

So, I pressed the arrow up key in the terminal to bring back the cryptsetup command. I pressed enter key and to my surprise I received the message: unknown or not found device on /dev/sdX. I tried again, but received the same answer. My Kingston disappeared from the filemanager too. I ran fdisk -l and lsblk and my Kingston (/dev/sdX) was not listed anywhere. I unplugged my usb flash drive and plugged it again. I looked again in all tools that I know and that I have installed, but my usb flash drive is gone!

I decided to take a look in the kern.log to see if the usb port was recognizing my device. Below is what the kernel logged when I plugged the Kingston again in the 3.0 USB port:

Apr 13 18:54:40 mx kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 7 using xhci_hcd
Apr 13 18:54:40 mx kernel: usb 4-1: New USB device found, idVendor=13fe, idProduct=5500, bcdDevice= 1.10
Apr 13 18:54:40 mx kernel: usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Apr 13 18:54:40 mx kernel: usb 4-1: Product: 2311 Boot ROM           
Apr 13 18:54:40 mx kernel: usb 4-1: Manufacturer: Phison                  
Apr 13 18:54:40 mx kernel: usb-storage 4-1:1.0: USB Mass Storage device detected
Apr 13 18:54:40 mx kernel: scsi host2: usb-storage 4-1:1.0
Apr 13 18:54:41 mx kernel: scsi 2:0:0:0: Direct-Access              2311 PRAM        1.00 PQ: 0 ANSI: 0 CCS
Apr 13 18:54:41 mx kernel: sd 2:0:0:0: Attached scsi generic sg0 type 0
Apr 13 18:54:41 mx kernel: sd 2:0:0:0: [sda] Attached SCSI removable disk

I unplugged my new Kingston and plugged my ten years old Kingston 2.0 in the same USB 3.0 port and it worked well. But my new Kingston seems to be damaged by something that I don't know what was. I plugged and unplugged my new Kingston more several times but got the same output log in the kernel. I am sure of the USB 3.0 port is working well because I tested others USB flash drivers, and also other pretty new USB 3.0 Kingston 64GB that is exactly the same model of the damaged one, because I bought two identical 64GB DTX Kingston in the store.

I searched in sys.log, kern.log and I guess in dmesg too, but there is nothing wrong between the lines of when I plugged my 3.0 Kingston was plugged and when I realized the problem and unplugged it to plug again.

My machine is (low end laptop):

product: 82MD (LENOVO_MT_82MD_BU_idea_FM_IdeaPad 3 15ITL6)
vendor: LENOVO
version: IdeaPad 3 15ITL6 
UEFI: LENOVO v: GGCN48WW 
Mobo: LENOVO model: LNVNB161216
width: 64 bits
capabilities: smbios-3.3.0 dmi-3.3.0 smp vsyscall32

System and kernel info:

Kernel: 5.10.0-18-amd64 [5.10.140-1] x86_64 bits: 64 compiler: gcc v: 10.2.1 
parameters: BOOT_IMAGE=/boot/vmlinuz-5.10.0-18-amd64 
root=UUID=<filter> ro quiet splash 
Desktop: KDE Plasma 5.20.5 wm: kwin_x11 vt: 7 dm: SDDM 
Distro: MX-21.2.1_KDE_x64 Wildflower September 18  2022 
base: Debian GNU/Linux 11 (bullseye)

... and the info of the USB 3.0 port used:

USB controller
product: Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller
vendor: Intel Corporation
physical id: 14
bus info: pci@0000:00:14.0
version: 20
width: 64 bits
clock: 33MHz
capabilities: pm msi xhci bus_master cap_list
configuration: driver=xhci_hcd latency=0
resources: irq:145 memory:54000000-5400ffff

Also, if I leave my damaged USB Kingston plugged in the USB port for some minutes, it will get warm. I tried to open in other computer and smartphone. The smartphone just detected something, and nothing more. All that situation happened yesterday.

Today I plugged the Kingston again on my computer and I am almost sure: the USB flash drive is completely dead Not even the kernel is detecting it plugged on the USB 3.0 port. Also, the USB drive doesn't get warm anymore.


That is it. I hope someone have any idea about this situation because I really don't want to damage other USB flash drivers, if it was really my fault.

 

[osprey]

avocatux, your post of an unfortunate result sounds like a tale of woe.

Here are some thoughts.

The first mistake I see was to interrupt the dd command.
It leaves the usb in an ambiguous state for some programs that may subsequently try and apply their software to read it. The usb is left in part zeroed out, but the rest may still have signatures not wiped. So, it's not unexpected that, as you write, "Here is where the bad thing started to happen."

Then you interrupted the "cryptsetup luksFormat -y -v /dev/sdX" process with cntl+c.
Then there were further cntl+c presses interrupting processing.
Then the usb disappeared altogether from the filesystem.

It seems that effectively all the interruptions will have interfered with the programs writing to the usb, making it ambiguous or unreadable by the programs subsequently invoked.

When, after the failures, the usb was replugged, you found the kernel still recognised the device at the hardware level. That was likely because the firmware in the usb was still intact which you have not shown to have been interfered with.

But, perhaps unexpectedly in the last plug-in of the usb, the kernel was not detecting it, so it seems dead. And that may actually be the case, since if the kernel cannot see it, nothing can be done with it in the operating system.

However, at this point, in an effort to see if the usb can be seen by an operating system, I would try and determine that by plugging it into different computers, and/or trying to see if it is detected after booting up a live disk (live usb, or live cd, or live dvd), or, try and see if it is detected after booting a rescue disk and plugging it in. That's three tests. The rescue disks may or may not have more adequate tools both for recognising and reformatting than common live disks of distros. If any of these other approaches detect and recognise the usb disk, then you could format it there and then in those systems.

One needs to be clear about the process for encrypting the disk, for which I found this page useful: https://linuxhint.com/encrypt-data-usb-linux/. YMMV.

 

[sphen]

I like @osprey's post above. I would like to amplify osprey's suggestion by adding: When you are "plugging it into different computers", I suggest that in addition to computers running Linux, you try Mac and/or Windows computers if they are available.

 

[avocatux]

I appreciate both tips. But my Kingston usb flash drive is dead. I already plugged in two different computers (windows 10 and linux) and also in different smartphones (old and new models), and nothing happen. I did not tried yet using a rescue disk, I will try. But I believe I will have not luck.

In the same day after the problems, the kernel was recognizing my kingston in (very strange) way as I posted in my message before. Also, I noticed my Kingston getting really hot (touching the body of flash drive) while plugged in the USB port. The day after, the usb flash drive was dead not being recognized in any way.

I can understand the kernel saying: "you managed wrongly your device and I cannot recognize it in the right way, but I can still recognize something like an storage mass in the USB port".

What I cannot understand is why and how dd, cryptsetup and/or me destroyed physically the usb flash drive, turning it completely dead and preventing it to be recognize (even in the wrong way) for any kind of computer.

I was thinking in encrypt other usb flash drive and also my entire computer reinstalling linux with luks encryption enabled. I have an old 1GB 2.0 usb flash drive and I will use it to try again (without dd) to see what happen.

 

[sphen]

Contact Kingston. They may replace the USB drive under warranty or for customer goodwill.

 

[Deleted member 108694]

Yep when you interrupted the process you turned your thumb drive into a boat anchor - I use Gnome Disk Utility to format my drive and add LUKS Encryption if needed

Making the long story short, if our LUKS header gets damaged, all data is gone. To prevent this from happening, we need to create a header backup. This can be done by issuing the following command:

sudo cryptsetup luksHeaderBackup <device> --header-backup-file <file>

Where <device> is a LUKS volume disk and <file> is a name of a header backup file to be created. In this case the LUKS is on an external HD at sdb1

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/sdb1-header-backup

The file is now in the /root folder which is hidden and you need root access to get to it from there you can move it to anywhere else like to a thumb drive if you choose

In case of disaster where our LUKS header gets broken, you can restore it by issuing the following command:

sudo cryptsetup luksHeaderRestore <device> --header-backup-file <file>

WARNING: LUKS header restoration procedure will replace all key-slots, therefore only the passphrases from the backup will work afterwards!

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/sdb1-header-backup

Usually when something goes wrong with LUKS it is the header that gets corrupted

Note: It is often recommended to backup the headers securely, i.e. on a encrypted drive. However, “I put mine on /boot, as this is an unencrypted partition, and the file is small (2MiB).
There’s no great security loss in this – anyone with physical access (or root access) to your device can simply dump the header anyway so it don't matter. If you’re really worried though, save it somewhere safe, or print it out, and store it somewhere else“.

 

[JeremyBrayan]

Here are a few possibilities that could have contributed to the problem:

1. Interrupted encryption process: When you pressed Ctrl+C to stop the cryptsetup luksFormat command, it's possible that the process was interrupted in an inconsistent state. This could have led to data corruption or damage to the file system on the USB drive.
2. Hardware failure: It's also possible that the USB flash drive experienced a hardware failure coincidentally around the same time you were performing the encryption process. Hardware failures can occur due to various reasons, including manufacturing defects, physical damage, or electrical issues.
3. Incompatibility or driver issue: There could be an incompatibility or driver issue between your USB flash drive and the operating system or kernel you're using. This can sometimes cause devices to become unresponsive or unrecognized.
4. Power or voltage issues: USB drives require a stable power supply to function properly. If there are power or voltage fluctuations in the USB port or the system, it could potentially cause damage to the drive.