If the Linux kernel detects the presence of some disk manager
on an IDE disk, it will try to remap the disk in the same way
this disk manager would have done, so that Linux sees the same
disk partitioning as for example DOS with OnTrack or EZ-Drive.
However, NO remapping is done when a geometry was specified
on the command line - so a
`hd=
cyls,
heads,
secs' command line option
might well kill compatibility with a disk manager.
The remapping is done by trying 4, 8, 16, 32, 64, 128, 255 heads (keeping H*C constant) until either C <= 1024 or H = 255.
The details are as follows - subsection headers are the strings appearing in the corresponding boot messages. Here and everywhere else in this text partition types are given in hexadecimal.
EZ-Drive is detected by the fact that the first primary partition
has type 55. The geometry is remapped as described above,
and the partition table from sector 0 is discarded - instead
the partition table is read from sector 1. Disk block numbers
are not changed, but writes to sector 0 are redirected to sector 1.
This behaviour can be changed by recompiling the kernel with
#define FAKE_FDISK_FOR_EZDRIVE 0
in ide.c.
OnTrack DiskManager (on the first disk) is detected by the fact that the first primary partition has type 54. The geometry is remapped as described above and the entire disk is shifted by 63 sectors (so that the old sector 63 becomes sector 0). Afterwards a new MBR (with partition table) is read from the new sector 0. Of course this shift is to make room for the DDO - that is why there is no shift on other disks.
OnTrack DiskManager (on other disks) is detected by the fact that the first primary partition has type 51 or 53. The geometry is remapped as described above.
An older version of OnTrack DiskManager is detected not by partition type, but by signature. (Test whether the offset found in bytes 2 and 3 of the MBR is not more than 430, and the short found at this offset equals 0x55AA, and is followed by an odd byte.) Again the geometry is remapped as above.
Finally, there is a test that tries to deduce a translation
from the start
and end
values of the primary partitions:
If some partition has start and end cylinder less than 256,
and start and end sector number 1 and 63, respectively,
and end heads 31, 63 or 127, then, since it is customary
to end partitions on a cylinder boundary, and since moreover
the IDE interface uses at most 16 heads, it is conjectured
that a BIOS translation is active, and the geometry is
remapped to use 32, 64 or 128 heads, respectively.
(Maybe there is a flaw here, and genhd.c should not have
tested the high order two bits of the cylinder number?)
However, no remapping is done when the current idea of the
geometry already has 63 sectors per track and at least as
many heads (since this probably means that a remapping was
done already).