Have you ever resized your USB stick FAT32 partition in Linux Gparted and then in it has broken something and turned it to RAW format in Windows? I saw this thing happen to me. I figured a way to fix it, so here I present the whole ordeal.
A bit of a background
I have carry around a SystemRescueCD on my USB stick. On the same disk I carry fresh images of Windows 7 / Windows 10 installation. If the need arises to test something on a clean system, I temporarily replace the regular SSD with my test SSD and drop in the image from my USB stick with SystemRescueCD. The problem is, the software Rufus I use to master the USB stick, it uses the whole disk as FAT32. I don’t want it to do it. I want to have on the first partition just the SystemRescueCD files and a couple of extra gigabytes for drivers, etc. I usually used the rest of the stick as non-journaled EXT4 partition. So, when I run this in Rufus on 32 GB stick:
I get this:
All data used as FAT32. Not good.
Initial look at unmodified FAT32 USB stick in Linux
To resize the partition I boot to Linux, then I launch Gparted. My Gparted version here is 0.33.0 with libparted 3.2 :
Some data of the stick is shown on right here:
The full USB stick device /dev/sdb is visible and also the first partition /dev/sdb1 has extensive data. Most importantly the picture tells 7 bytes from the beginning of the partition as:
0xEB 0x58 0x90 0x53 0x59 0x53 0x4C .
Gparted resizing causes errors
Lets do the actual resize:
Then we eject the stick (safely) and start looking at it in Windows. Bang! We instantly run into trouble. Windows asks if we want to format the stick now:
More clearly, if we launch Disk Management (diskmgmt.msc) again , we get this:
As you can see, the size has changed as it should, there is now empty space at the end of the stick. But. The filesystem of the partition is now RAW. It’s unusable in Windows.
Fix on Linux size
Now before fixing this, a warning:
THIS FIX CAN HELP PROBLEMS APPEARING AFTER FILESYSTEM RESIZE! IF THIS METHOD IS USED IN SOME OTHER USE CASE, IT MAY NOT WORK AND CAN EVEN CORRUPT DATA. YOU NEED TO KNOW WHAT YOU ARE DOING.
There. Lets look at how Linux side sees the situation of the stick now:
Size data has changed, but take a look at the beginning of /dev/sdb1 . Even the file -s command does recognize extensive partition/filesystem data anymore! And what is the root cause of our problems is that the first bytes of the partition have changed. They are now:
0xB0 0x02 0x00 0x4D 0x53 0x57 0x49
So how to actually fix this? We run following shell commands to rewrite 3 first bytes.
echo -n -e \\xEB\\x58\\x90 > /dev/sdb1
sync
The fix in place with device and partition information:
As a comparison to earlier, size is the same, but there is extensive partition/filesystem information available again. Also hexdump reports correct start bytes:
0xEB 0x58 0x90 0x4D 0x53 0x57 0x49
Trying it out in Windows works again just fine, we can see files without nagging:
And Disk Management is again happy:
Analysis of problem
The problem appears to be because of a bug in libparted, at least according to https://lists.gnu.org/archive/html/bug-parted/2016-04/msg00000.html and https://superuser.com/questions/1163031/gparted-fat32-formatted-usb-is-not-recognized-in-windows-10/1163832. I find it funny that we have a broken FAT32 resizer still in year 2019, 4 years after bug discovery.