DOS ain't dead

Hello everyone,

while hacking on Ranish Partition Manager I discovered a strange behaviour of either FreeDOS FDISK or my BIOS, but my guess is FDISK. Perhaps one of you is able to reproduce that:

1) Create a primary partition of 2040 MB using LBA, gets rounded up to 2047 MB.
2) Let FDISK show the partition table: partition is 2047 MB in size
3) close FDISK
4) Open FDISK again and show the partition table: partition is 2055 MB in size
5) Reopen FDISK again with /x command line argument to turn off LBA support: disk is back to 2047 MB in size

Really strange. What is curious even more is that CHS and LBA values in MBR get out of sync. I noticed that because Ranish discovered a MBR inconsistency.

Diagnosis with WDE showed that in the process of editing via FDISK the end cylinder of the partition increased by one. At first it was CHS 260/254/63, after editing (adding a 8000MB extended partition) it was CHS 261/254/63 but LBA sector count remained the same.

Please see the following screenshots that document the behaviour, especially diag_02 and diag_05, which clearly show that the CHS values changed:

https://boeckmann.io/pub/diag_01.jpg
https://boeckmann.io/pub/diag_02.jpg
https://boeckmann.io/pub/diag_03.jpg
https://boeckmann.io/pub/diag_04.jpg
https://boeckmann.io/pub/diag_05.jpg
https://boeckmann.io/pub/diag_06.jpg

> Diagnosis with WDE showed that in the process of editing via FDISK the end
> cylinder of the partition increased by one. At first it was CHS 260/254/63,
> after editing (adding a 8000MB extended partition) it was CHS 261/254/63
> but LBA sector count remained the same.

Ok. I guess that FD Fdisk, when the Extended Partition is created, tries to set the start at a cylinder boundary AND want the starting sector number not to be "odd". To avoid "holes", it adjusts the upper limit of the partition that's located just before the newly created one.

Since the BPB is not affected and the upper limit is not decreased, there's not really any problem.

Adjusting the LBA values would probably be good, but the primary partition type is 0B ( FAT32 CHS ), so the LBA values are - correct me if I'm wrong - "informational" only.

---
MS-DOS forever!

The main problem seems to be independant from the creation of the extended partition. If I create the FAT32 partition FDISK says it is 2047 MB in size. After restarting FDISK it thinks the partition is 2055 MB in size. If I make any modifications, like setting the partition active, that modified partition size gets written to disk. That behaviour does not happen if FDISK is forced into CHS mode by giving the /x command line argument. So for me it seems anywhere in the LBA to CHS translation code of FDISK there may be an off-by-one error.

The second thing: The end CHS value of the extended partition, which is beyond the 8GB limit, seems to simply overflow. Is that common behaviour or should that better be set to 1023/255/63 to indicate an invalid entry?

In last year here on the forum was a large discussion about FDisk and it's bugs and it leaded to some updates to FreeDOS FDisk.
Maybe you can found something useful in that thread:
http://www.bttr-software.de/forum/board_entry.php?id=17440

---
DOS-u-akbar!

This is shown by kernel when booting up till FDT2211

Thanks to all for the feedback.

By skimming over the FDISK source code I think I found a possible location yielding an off-by-one error:

https://gitlab.com/FreeDOS/base/fdisk/-/blob/master/SOURCE/FDISK/FDISK/PDISKIO.C#L919


  pDrive->pri_part[index].end_cyl
           =Extract_Cylinder_From_LBA_Value(
           /* */
           (pDrive->pri_part[index].rel_sect
           +pDrive->pri_part[index].num_sect)...


I think that should be

  pDrive->pri_part[index].end_cyl
           =Extract_Cylinder_From_LBA_Value(
           /* */
           (pDrive->pri_part[index].rel_sect
           +pDrive->pri_part[index].num_sect - 1)...


Can anyone please double-check that?

> Thanks to all for the feedback.
>
> By skimming over the FDISK source code I think I found a possible location
> yielding an off-by-one error:
>
> https://gitlab.com/FreeDOS/base/fdisk/-/blob/master/SOURCE/FDISK/FDISK/PDISKIO.C#L919
>
>
> pDrive->pri_part[index].end_cyl
> =Extract_Cylinder_From_LBA_Value(
> /* */
> (pDrive->pri_part[index].rel_sect
> +pDrive->pri_part[index].num_sect)...
>
>
> I think that should be
>
> pDrive->pri_part[index].end_cyl
> =Extract_Cylinder_From_LBA_Value(
> /* */
> (pDrive->pri_part[index].rel_sect
> +pDrive->pri_part[index].num_sect - 1)...
>
>
> Can anyone please double-check that?

I think that a) is a plausible place and b) looks right.

I also think that all occurences of

xyz.end_cyl = Extract_Cylinder_From_LBA_Value()

should be checked. It's quite horrible software

> Hello everyone,
>
> while hacking on Ranish Partition Manager I discovered a strange behaviour
> of either FreeDOS FDISK or my BIOS, but my guess is FDISK. Perhaps one of
> you is able to reproduce that:

Question:
Are these anomalies happening while booted directly to DOS ?
(be it MsDos, FreeDos, DR-DOS etc...)

Or are you booted to some other OS and then using a DOS VM ?
(Windows, Linux, MAC etc... and then QEMU, dosbox, DOSBox-X etc...)

---
--
http://glennmcc.org/

> Are these anomalies happening while booted directly to DOS ?
Yes, under FreeDOS 1.3, FDisk Version 1.3.4 running directly on the hardware (a Pentium III System).

I think I found the error in the code and made some modifications to correct it. But the earliest I can test it is next week, when I am back at my office. If everything goes well I can make a pull request by the middle of next week.

> I also think that all occurences of
>
> xyz.end_cyl = Extract_Cylinder_From_LBA_Value()
>
> should be checked.

Totally agree with that

> Are these anomalies happening while booted directly to DOS ?

The error occurs if the following conditions are met:

1) LBA enabled BIOS
2) FDisk LBA support enabled
3) End sector lies on a cylinder boundary
4) Partition lies within the 8 GB limit

That bug should be independent of the underlying hardware / virtual machine.

I opened a bug report at https://gitlab.com/FreeDOS/base/fdisk/-/issues/6

In fact there seems to be a second bug when detecting the total cylinder count in LBA mode resulting in a reported disk size that is too large and partitions exceeding the end of disk.

https://gitlab.com/FreeDOS/base/fdisk/-/issues/7

> In fact there seems to be a second bug when detecting the total cylinder
> count in LBA mode resulting in a reported disk size that is too large and
> partitions exceeding the end of disk.
>
> https://gitlab.com/FreeDOS/base/fdisk/-/issues/7

there is one more thing, closer to label than to fdisk, but it says to me that fdisk reads only one entry of (seems there are written two entries) the hd label.

see:
https://gitlab.com/FreeDOS/issue-reporting/-/issues/31

just for information

willi