older CHS interface. This works around stupid BIOSs who report that
int13 extensions are present and functional, but fail when you actually
use them. Like Adaptec SCSI BIOSs.
For the bootselector, there was no space to get the CHS info from
the BIOS. Instead, use a flag that can be set by fdisk. fdisk will
set it if one of the partitions on the disk is out of CHS reach
for this disk/BIOS, so that the bootselector will use int13 extensions.
This isn't so bad, because it needs to be configured via fdisk anyway.
Change the mbr manualpage to reflect some shorter error messages.
effect (i386 only of course). Also change one branch in the
bootselector code to an explicit 16 bit one, and check both
the boot menu and partition tables to see if the partition
requested by the user should be booted. This check just in case,
should the bootselector menu and partition table get out of sync
somehow. (mmm, bytesqueezing)
Update information about partition types - add missing types, insert
"reserved" for IDs which are marked as "officially reserved" in other
lists.
Sources of information:
-"How it Works -- Partition Tables" by Hale Landis <hlandis@ibm.net>
-Ralph Brown's interrupt list
-i no longer implies -u, -i now does not use the entire first track
because some BIOSes refuse to boot from a partition in the first track.
-s renamed to -S, new -s for non-interactive setting of a partition's
id, offset and size. Updated documentation to match.
translated geometry of the disk. This code will only change the
disk geometry if it can find a geometry which is consistent with
all partition entries, so it's very conservative about choosing
a new disk geometry. Under some circumstances, it will choose a
number of cylinders which is a little lower than it needs to be,
but this code is enough so that you can create new partitions
with the correct physical addresses.
The right solution to this problem is to have the boot loader
communicate the BIOS geometry of each disk to the kernel, in a
manner similar to the symbol table, and then provide a kernel
interface to get at that information. I'm unfortunately not
really qualified to make such a change, and I want something
that works better than the status quo.
