Inconsistent fat id and and media type not checked in fsck.fat

[ghost]

Grub and some UEFI loaders will not recognise a FAT 32 file system if the media descriptor in the BIOS parameters does not match the least significant 8bits of the fat id in entry 0 (zero) of the file allocation table. However fsck.fat does not warn of this as a potential error. Should fsck be making this check?

[pali]

It is checked by fsck.fat and there is even (unit) test that fsck.fat can repair media type descriptor in first cluster in file allocation table.

If fsck.fat is not able to repair this inconsistency for some of your filesystems, please provide image of such filesystem so I can look at it and investigate it.

[ghost]

I've put a copy of the image here:

https://www.dropbox.com/s/u0kysbkvawyhqe2/fat32.image.bz2?dl=0

this is the output from fsck on fedora 34

fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "amst.fat"
Media byte 0xf8 (hard disk)
512 bytes per logical sector
512 bytes per cluster
4 reserved sectors
First FAT starts at byte 2048 (sector 4)
1 FATs, 32 bit entries
2095104 bytes per FAT (= 4092 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 2097152 (sector 4096)
520192 data clusters (266338304 bytes)
63 sectors/track, 255 heads
2048 hidden sectors
524288 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdf1: 1 files, 1/520192 clusters

EDIT: file reuploaded to github: fat32.image.gz

[pali]

Thank you! Now I see where is the issue. fsck.fat code checks that first fat cluster contains valid media type description. But it does not check if this media type descriptor is same as one stored in boot sector. In case media type is invalid, fsck.fat can copy/repair it from boot sector. Seems that all reports for media type was about invalid media type (which implies also that was different from boot sector).

So if there is already requirement not only for validity of media type descriptor but also that it is same, then this type of repair in fsck.fat is something really useful.

If I find some time I can try to prepare patches for it (unless somebody is not faster).