[Info-mtools] Wrong default "physical drive id" produced by Mformat on hard disk

[Nutchanon Wetchasit]

Dear Mtools maintainer,

I'm not a new Mtools user, but I have recently come to use Mtools'
Mformat utility to create a FAT32 partition that is aimed for Microsoft OS
(Windows XP) installation/booting uses. This volume is designed to have
certain "freaky" characteristics: FAT32 but sub-2 GiB size, single FAT copy,
with FAT size several-folds larger than what's required,
as well as various partially-conflicting alignment requirements
which standard format tools won't allow me to make,
not even third-party `mkdosfs`...

But Mformat did, by the following parameters:

> mformat -i /dev/sda1 -h 255 -s 63 -H 63 -F -v XPREV_SP3 -d 1 -c 32 -L 3593 ::

Mformat created that volume as I nitpicked without a hitch,
and with correct structure. When it got used for actual
Windows XP installation (set not to reformat anything),
the first-stage installer (i.e. the installer boot disc)
happily copied files to this volume.

However, when this stage rebooted to enter the second-stage installer
which resides on the volume itself... the boot process would end
right after BIOS POST screen, with the following error:

> Disk error
> Press any key to restart

The process was then retried with various other Mformat parameters combo,
including a more conventional one (2 FATs with automatic FAT size);
but the boot errors were still the same. Note that this
was not a geometry mismatch, since I actually nitpicked every relevant
settings from hidden sectors (matching with partition's LBA start),
to sectors-per-track and heads count (matching the geometry seen
from the target machine's BIOS).

In a last-ditch attempt to debug it, the installer was set to reformat
(but not repartition) the volume itself; and in that attempt,
the system could boot to the second installer stage properly...

Then the installation was aborted for a purpose of disk contents inspection.
When I compared Minfo output of this installer-formatted partition
against Mformat-formatted one; among the lines in unified diff output,
I spotted this:

> -physical drive id: 0x80
> +physical drive id: 0x0

^ The first line was from Windows installer-formatted partition,
  while the second line was from Mformat-formatted partition

I know full well how this field was used when the volume in question
was a boot volume (i.e. int13h drive number to use for accessing the disk);
so it not being 0x80 "first hard disk" made it a prime suspect.

I have double-checked relevant Info section and Unix manual page,
and it become apparent that Mformat did not seem to provide
any command line option to set this field manually either.

After the suspect is revealed, the process was restarted from scratch
from partitioning (with the exact same parameters as the first experiment),
and formatting with Mformat (using the exact parameters specified above).
But instead of putting the volume into use with Windows installer
right away, I manually patched this int13h disk number field
(unsigned byte at offset 0x40 of FAT32 boot sector and its backup)
to a correct 0x80 "first hard disk" value using a makeshift hex editor:

> # dd if=/dev/sda1 bs=512 count=1 of=bootsect.orig
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied, 0.000427954 s, 1.2 MB/s
> # xxd -g 1 -c 1 -p bootsect.orig | sed -s '65{s/^.*$/80/;b}' | xxd -r -p > 
> bootsect.new
> # diff -u0 <(od -A x -t x1 bootsect.orig) <(od -A x -t x1 bootsect.new)
> --- /dev/fd/63  2023-02-23 13:14:56.010006712 +0000
> +++ /dev/fd/62  2023-02-23 13:14:56.010006712 +0000
> @@ -5 +5 @@
> -000040 00 00 29 3c 16 13 28 58 50 52 45 56 5f 53 50 33
> +000040 80 00 29 3c 16 13 28 58 50 52 45 56 5f 53 50 33
> # dd if=bootsect.new of=/dev/sda1 bs=512 count=1
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied, 0.00260626 s, 196 kB/s
> # dd if=bootsect.new of=/dev/sda1 bs=512 seek=6 count=1
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied, 0.00263636 s, 194 kB/s
> # 

>From this point, Minfo now displayed the correct 0x80 value
of "physical drive id" field on the volume.

When Windows XP installer (set to not reformat anything) started
with this manually-patched volume, all stages of the installer completed;
and the resulting Windows system booted properly.

The starting `fdisk` log, Minfo output of freshly-Mformat'd partition,
and Minfo output of the same partition after manual hex patching
are attached to this email as a reference. (Note that the partition
had not been set as active in `fdisk` itself, but Windows installer
set it to active as a part of its installation process anyway)

-----

The issue is, Mformat does not seem to put a sane default 0x80 value
in this "physical drive id" field even that it did seem to correctly guess
that the volume is on a hard disk as opposed to floppy-like media
(if a correct 0xF8 "fixed disk" media descriptor byte produced
should be any indication).

It should have done so, and doing so would save quite a lot of headaches;
as well as elevating Mformat from "another formatting tool suitable
just for FAT data partition" to "a rescue tool capable
of preparing bootable drive" in the hand of power user
who know what he is doing.

(Note that this problem is not specific to FAT32; disk-based FAT12 and FAT16
volumes produced by Mformat also have this problem as well.)

Ideally, a dedicated Mformat command line option should also be added [1]
to allow a user to rig this field to a value he see fit, in case Mformat
guessed it wrong; which I'd imagine it would when operating on image file
intended for Zip disk for example.

Please investigate and fix.

Regards,
Nutchanon Wetchasit

-----

Disk capacity: 58605120 LBA sectors (512 bytes/sector) ~ 27.9 GiB
BIOS-provided int13h C/H/S access geometry: 3648/255/63
Partitioner: util-linux 2.20.1 `fdisk` (Knoppix)
Partition (MBR scheme): sole partition, primary, type 0xC "FAT32 LBA"
                        at LBA 63, sized 3678822 sectors (~1.8 GiB),
                        C/H/S (0/1/1) -> (228/63/254)
Mtools: Mtools 4.0.42 (source), with no system-wide configuration file
Shell: GNU Bash 4.2.36(1)-release (Knoppix)
System Mtools, Fdisk, and Bash ran on: Knoppix GNU/Linux 7.0.5 (32-bit)
System booting off the volume: Microsoft Windows XP SP3 Professional


[1] I'm not too sure what name to suggest for this new option.
    I was originally about to suggest `-b` (Bios disk number);
    but Mformat's section in Texinfo manual already said that MS-DOS
    `format` had `/b` option (for quite a long time [2]),
    which Mformat doesn't implement-- so using `-b` might be misleading.
    `-B` is also already used.
    
    Maybe `-D` (bios Disk number) is a more suitable candidate.
    As for the radix of option's argument, it could probably use
    the same rule as the existing `-m` (Media descriptor) option. [3]

[2] `/b` option of MS-DOS `format` had effect up to MS-DOS 7.0.
    MS-DOS 7.01 and the rest of 7.x turned it into a dummy no-effect option.
    MS-DOS 8.x removed this option. According to
    <https://msfn.org/board/topic/154648-dos-format-b-and-label/>

[3] A loophole in the documentation of `-m` option of this Mformat version
    (in both Texinfo and Unix manual page) is that it doesn't seem to say
    which number base (decimal, hexadecimal, prefix-select, suffix-select)
    that user is supposed to specify the value in.
    
    It seems to accept decimal number by default; but heuristically switch
    to hexadecimal when it found letter in the range of `a`-`f`
    and/or `A`-`F` in the value.
    
    C-style radix prefix seems to be accepted as well:
    "0" prefix (not "0o" prefix and not "o" suffix) for octal,
    and "0x" prefix (not "h" suffix) for hexadecimal; which of course
    no prefix/suffix available for explicitly denoting decimal
    ("0d" prefix and and "d" suffix triggered heuristic switch
    to hexadecimal), binary is not accepted ("0b" prefix and "b" suffix
    would trigger heuristic switch to hexadecimal).

fdisk.txt
Description: Text document

minfo-prepatch.txt
Description: Text document

minfo-postpatch.txt
Description: Text document