FAT32 vs FAT16

[robertapengelly]

I have two different images where the partition entry are exactly the same except the partition type:

    1) 80 04 01 00 0C 03 D1 C4 44 00 00 00 20 00 02 00
    2) 80 04 01 00 06 03 D1 C4 44 00 00 00 20 00 02 00

Arca (well lvmgui) accepts the first one without issues but says that the second one is corrupt.  Does anyone know why?  Or is it maybe a bug?

[Rich Walsh]

There's more to an OS/2 partition than just its partition table entry: there's also its entry in LVM's DLAT (Drive Letter Assignment Table). For primary partitions, this is stored in the last sector of the disk's first track. Using C/H/S notation 0/0/63 on most disks (i.e. LBA 0062).

This isn't something that's easily edited because the DLAT header contains a CRC for that sector - changing anything renders the CRC invalid. Instead, you may want to try copying this sector from one image to the other.

[robertapengelly]

I appreciate the reply, indeed I'm missing information but it doesn't exactly answer the question as to why lvmgui reports a partitions entry as corrupt if it's FAT16 and not when it's FAT32?

[Rich Walsh]

indeed I'm missing information but it doesn't exactly answer the question as to why lvmgui reports a partitions entry as corrupt if it's FAT16 and not when it's FAT32?

I didn't "exactly" answer your question because there are no valid answers to invalid questions.

You seem to be convinced that this is a FAT16/FAT32 problem. If it is, then changing the '06' to '0C' should fix it. Have you tried that? I'd be really, really amazed if it did because LVM doesn't care what filesystem is in use. It cares about whether the partition's start/end/size look valid and whether the corresponding DLAT info is present and valid. And from what you say, it isn't.

BTW... neither of the questions you posted provide any clue as to what the _real_ problem is or how your system came to be in its current state. Without context, it's awfully hard to provide a useful answer. For example, you say that you're "missing information" without identifying whether both images are missing this info or just one is (and if just one, which one). Stuff like this matters - and without it, it's just another case of "Garbage In, Garbage Out".

[robertapengelly]

Yes changing the 0x06 to 0x0C doesn't say that there's a corrupt partition table hence the original question.  Maybe I should have also mentioned that they were two different images so let me reclarify, a image mounted with Virtualbox with the following says the partition table is corrupt in lvmgui

    80 04 01 00 06 03 D1 C4 44 00 00 00 20 00 02 00

Whereas the following is accepted and lvmgui does complain

  80 04 01 00 0C 03 D1 C4 44 00 00 00 20 00 02 00

[kerravon]

Whereas the following is accepted and lvmgui does complain

  80 04 01 00 0C 03 D1 C4 44 00 00 00 20 00 02 00

DOESN'T complain.

You might like to attach the two VHD here, as they compress well, being empty.

This forum accepts attachments.

[kerravon]

You seem to be convinced that this is a FAT16/FAT32 problem. If it is, then changing the '06' to '0C' should fix it. Have you tried that? I'd be really, really amazed if it did because LVM doesn't care what filesystem is in use. It cares about whether the partition's start/end/size look valid and whether the corresponding DLAT info is present and valid. And from what you say, it isn't.

I think that's a very harsh behavior for lvm to do, if that's really expected.

It's very normal to import a disk from another site - that is not OS/2/LVM-aware, and it is wrong to say that the partition is corrupt. It's merely lacking LVM info - very normal and expected, and misleading to call it corrupt.

I believe the FAT32 behavior is correct - no complaints about the partition.

Also note that even though the FAT16 disk is reported as corrupt, it is accepted anyway.

[robertapengelly]

Right, not exactly the same images as I originally had but I've attached a zip with two images which should be identical except the partition type, mount them with Virtualbox and run lvmgui in Arca and you should have the same result as me which is it will complaint about the fat16.vhd but not the fat32.vhd.