Argh! exFAT USB stick

[stamasd]

I have a Lexar 128GB USB stick, formatted exFAT out of the box. I have been trying to repartition it and format it ext4 so I can use it to transfer large files between Linux machines.

 

I don't know what dirty tricks Lexar used to partition and format it, but the partition table is really screwed up. Moreover, I can't change it. If I delete the fictitious partitions on the stick in cfdisk, write a new partition to the stick, exit and try to read the stick again it fails. I have to physically disconnect and reconnect it, and then the original partition table is back.

It looks like I'm getting some cache errors when trying to write the partition table:

[  417.015912] sd 6:0:0:0: [sdb] Synchronizing SCSI cache
[  417.015960] sd 6:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK

I've looked for a solution but haven't really found anything. The stick itself works when attached to a Windows machine. I'm attaching a screenshot of the partition table, and the output of dmesg.

Did anyone have success partitioning and formatting one of these in Linux?

[danielisko]

maybe use `sudo dd if=/dev/zero of=/dev/sdb status=progress` to completely erase your lexar then use `sudo cfdisk -z /dev/sdb` NOTE: That -z parameter uses zeroed mbr table.

Or if even doesn't work (i mean dd command), use `sudo shred -f -v -z /dev/sdb` then above cfdisk command.

[klipkyle]

This is a wild guess, but I wonder if the stick is GPT-formatted.  If the stick is GPT-formatted, then there are two backup partition tables (one near the start of the disk and another near the end) that can sometimes get restored automatically.

If this is the case, then sgdisk should be able to wipe out both the MBR and GPT labels:

sgdisk -Z /dev/sdb

According to sgdisk(8):

       -Z, --zap-all
              Zap (destroy) the GPT and MBR data structures and  then  exit.
              This  option  works  much  like -z, but as it wipes the MBR as
              well as the GPT, it's more suitable if you want to repartition
              a  disk  after using this option, and completely unsuitable if
              you've already repartitioned the disk.

 

[stamasd]

Hm, interesting. Gdisk says it's a MBR volume, not GPT. It also complains of overlapping partitions... like cfdisk does. Doesn't find any other partition schemes either, which is normal. Dirty tricks, I tell ya.

 

However,  sgdisk -Z /dev/sdb worked at destroying all partitioning tables on the disk and I was able to partition it and format the usual way. I now have a /dev/sdb1 of 128GB formatted ext4, exactly what I wanted.

 

Thank you!

[klipkyle]

12 hours ago, stamasd said:

Gdisk says it's a MBR volume, not GPT. It also complains of overlapping partitions...

That's very strange, doubly so considering that sgdisk was able to clear it out.

Glad it worked though.

[stamasd]

Small update, it seems that this USB stick is not very adequate for my purpose. It does not handle large files well. I tested it with a few files, between 5 and 8GB. They appear to copy well, but the stick's activity LED continues to flash as if stuff still happens (and it doesn't stop for a long time: I waited at one point for 1h and it still continued to do it). This activity continues even if I unmount the drive. No error message is generated, and if I try to mount the stick again it gives me a device busy error. If I physically remove the stick after unmounting and then plug it back in and mount it, the files copied over are damaged.

Looks like I'll have to look elsewhere for a large file transfer medium.

[klipkyle]

11 hours ago, stamasd said:

Small update, it seems that this USB stick is not very adequate for my purpose. It does not handle large files well. I tested it with a few files, between 5 and 8GB. They appear to copy well, but the stick's activity LED continues to flash as if stuff still happens (and it doesn't stop for a long time: I waited at one point for 1h and it still continued to do it). This activity continues even if I unmount the drive. No error message is generated, and if I try to mount the stick again it gives me a device busy error. If I physically remove the stick after unmounting and then plug it back in and mount it, the files copied over are damaged.

Looks like I'll have to look elsewhere for a large file transfer medium.

Maybe this drive has some bad blocks.  If you are writing a large file that takes a substantial amount of the drive's capacity, the chances of hitting that block increase, even with wear-leveling.

Unfortunately, I don't think there is much you can do because wear-leveling almost guarantees that you will write to different blocks each time you write, so there isn't an easy way to isolate that bad block.  Thankfully, USB drives are relatively cheap nowadays.

[stamasd]

I don't think that's the case. The USB stick is almost new, and it has only had a few MB of files written to it once. Also even 8GB is not a significant part of the drive's capacity of 128GB. For testing I only wrote one file at a time, and I did a total of 5-6 tests. Wear leveling should not come into play unless Lexar is totally off their game.

Regardless like you said there isn't much I can do. I'll go back to using external enclosures. A small stick that fits in a pocket would have been a nice upgrade. Or maybe try a stick that's below 64GB.