0

I resized a FAT filesystem. Then the filesystem stopped working as a Windows 10 Recovery Drive. ("This may be due to a recent change in your hardware or software..."). And a running Windows is unable to open the filesystem, when it could before.

Resize tool: gparted-0.27.0-1.fc25.x86_64 (Fedora 25)

The resize was performed on a disk image file, copied from a USB drive as a backup. gparted was run on a loop device created from the image file using losetup -f -P. (Or later, Gnome Disks and "Attach Disk Image" from the... whatever you call the app-specific menu, in the top bar of gnome shell).

1

There is some defect in this gparted. Although Linux is able to mount the resulting filesystem (and the files compare identical to the original), file -s shows the following weirdness:

Before

/dev/loop0p1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 3310, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, sectors 15114240 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 14729, serial number 0x9a856b85, unlabeled

After

/dev/loop1p1: DOS/MBR boot sector; partition 2 : ID=0xb2, start-CHS (0x2f0,0,0), end-CHS (0x0,0,0), startsector 2944401408, 51 sectors; partition 4 : ID=0x65, start-CHS (0x0,0,0), end-CHS (0x163,118,41), startsector 1626349669, 2144852992 sectors

Clearly some part of the Windows 10 Recovery boot path accepts the weirdness - I guess the part where the EFI filesystem driver is used. Later code must use similar checks to a fully running Windows, and does not accept it.

In the case of a Windows 10 Recovery Drive for UEFI, this could be worked around simply by creating a smaller FAT filesystem and copying the files into it. (Yes, really :).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.