First post, by LSS10999
I noticed a very odd partitioning problem that manifests with MS-DOS and maybe a few others.
It feels like some kind of inconsistency with the partition table that's causing a second primary partition on one of the disks not correctly recognized while in MS-DOS. However, the partition in question is recognized correctly in FreeDOS, PC-DOS 7.1 and even NT 3.51 (with UniATA). More modern systems like Windows XP/7 and Linux do not have any issue with it, either.
The partition in question was originally a logical one, but later on I decided to convert it to primary using DiskGenius (which could do it) from a WinPE environment, as it turned out NT 3.51 doesn't understand LBA extended partitions, even with the UniATA driver.
After conversion, everything looked good until I go back to MS-DOS 7.1 only to find out it could not read the partition anymore. Interestingly, I could somehow format it using FreeDOS' FORMAT from MS-DOS, though at first the partition would not be given a label even though I specified one (I could, however, put up its label via LABEL command). This is where the inconsistency begins. After formatting the disk from MS-DOS (given a different serial number), my other OSes still see the original filesystem of that partition along with the original serial number... and even fsck is not reporting any error when I checked the partition in question.
On the other hand, while FreeDOS' FDISK saw everything correctly, MS-DOS' FDISK showed garbled data when displaying disk information, especially when it comes to the disk on which the partition problem manifests. Perhaps it's also due to the FDISK being too dated and not able to handle too large disks, as it was reporting a wrong and apparently too small total size for the disk in question.
Feeling confused, I tried clearing the partition table several times and recreated the partitions many times over but the condition persists, even though I did every step as expected. Later on I altered the size of the two partitions on that disk, making the first one smaller and the second one larger, and I found out, to my horrors, that FreeDOS' FORMAT, when run from MS-DOS, actually formatted the first partition using the original size (before I resized). This means to MS-DOS the disk layout has always been the very initial state, before I converted the second partition from logical to primary, as well as my subsequent resizing of the two partitions.
(NOTE: If I format the partition from DOS first, the partitions would still appear unformatted to other OSes until I format it there also, and formatting the partition there would not break the state that MS-DOS could already see. Files copied to the disk on one of the states would not be visible to the other. I haven't tested copying different files to both states as there's a great chance this would lead to corruptions.)
The first partition can always be correctly accessed from any OS including MS-DOS, even after being formatted with the wrong size (GParted would give out an exclamation mark in this case). It's the second partition that couldn't be correctly accessed in MS-DOS and is having the discrepancies between MS-DOS and other OSes.
I did some further tests with other DOS variants than FreeDOS and PC-DOS 7.1 using boot disks, and looks like this issue also manifests in those, albeit the behavior varies.
EDR-DOS: Divide Error when accessing the partition in question.
ROM-DOS 7.1: Boot fails halfway with a "Divide by zero" error possibly related to the partition in question considering the similar error message from EDR-DOS when accessing it.
PTS-DOS 32: Error when accessing the partition in question. Additionally, drive letter assignment order is different here.
I'm not sure about the cause of the issue, but on this particular system, it appears there are some issues with the location offsets when creating partitions with legacy utilities, or with modern utilities (and MiB alignment).
- When creating partitions using GParted with MiB alignment, it leaves about ~1MB free space on the very beginning of the disk (that can somehow be seen by WinXP), and this empty space would somehow prevent most of the boot sectors (especially NTLDR) from working correctly. For DOS, usually doing another SYS would temporarily fix it, but not that easy for others. Not sure if this is an issue with my board's BIOS, or is an intended behavior...
- Legacy utilities like Norton PartitionMagic could correctly create the partitions without the aforementioned free space. However, it apparently lacked the ability to format very large FAT32 partitions so I have to do it elsewhere. Also, it only appears to work when the disk's partition table is empty. After I created the partitions (not formatting them here), if I boot to PartitionMagic again right after reboot (without doing anything else), I would get a partition table error #110 on the disk in question (I'm not very versed with that program's error codes, however).
In the end I gave up using MS-DOS 7.1 since it's too dangerous to use with the system in this state. I decided to use PC-DOS 7.1 as that one correctly sees my partitions, while also boot to FreeDOS kernels via GRUB4DOS.
