9. Consequences
What does all of this mean? For Linux users only one thing:
that they must make sure that LILO and fdisk use the right
geometry where `right' is defined for fdisk as the geometry
used by the other operating systems on the same disk, and for
LILO as the geometry that will enable successful interaction
with the BIOS at boot time. (Usually these two coincide.)
How does fdisk know about the geometry?
There are three sources of information. First, if the user has specified
the geometry interactively or on the command line, then we take
the user input. Second, if it is possible to guess the geometry used
from the partition table, then we use that. Third, when nothing else
is available, fdisk asks the kernel, using the HDIO_GETGEO ioctl.
How does LILO know about the geometry?
It asks the kernel, using the HDIO_GETGEO ioctl.
But the user can override the geometry using the `disk=' option
in /etc/lilo.conf (see lilo.conf(5)).
One may also give the linear option to LILO, and it will store
LBA addresses instead of CHS addresses in its map file,
and find out of the geometry to use at boot time (by using
INT 13 Function 8 to ask for the drive geometry).
How does the kernel know what to answer?
Well, first of all, the user may have specified an explicit geometry
with a `hda=cyls,heads,secs'
kernel command line option (see bootparam(7)), perhaps by hand, or by
asking the boot loader to supply such an option to the kernel.
For example, one can tell LILO to supply such an option by adding
an `append = "hda=cyls,heads,secs"'
line in /etc/lilo.conf (see lilo.conf(5)).
And otherwise the kernel will guess, possibly using values
obtained from the BIOS or the hardware.
Note that values guessed by the kernel are very unreliable. The kernel does not have a good way of finding out what values the BIOS uses, or indeed whether the disk is known to the BIOS at all.
It is possible (since Linux 2.1.79) to change the kernel's ideas
about the geometry by using the /proc filesystem.
For example
# sfdisk -g /dev/hdc
/dev/hdc: 4441 cylinders, 255 heads, 63 sectors/track
# cd /proc/ide/ide1/hdc
# echo bios_cyl:17418 bios_head:128 bios_sect:32 > settings
# sfdisk -g /dev/hdc
/dev/hdc: 17418 cylinders, 128 heads, 32 sectors/track
#
Since Linux 2.6.5 the kernel will (when compiled with CONFIG_EDD)
ask the BIOS for legacy_cylinders, legacy_heads, legacy_sectors
using INT 13/AH=08h. The values obtained are made available in
/sys/firmware/edd/int13_dev{80,81,82,83}/legacy_*.
In 2.6.5 the files were legacy_{cylinders,heads,sectors}
(with contents in hex, e.g. 0xfe for 254), but those names are
confusing, and in 2.6.7 they were changed to legacy_max_cylinder,
legacy_max_head, legacy_sectors_per_track
(with contents in decimal).
A geometry like C/H/S=1000/255/63 is found here as 999, 254, 63.
# insmod edd.ko
# cd /sys/firmware/edd/int13_dev83
# cat legacy_max_head
254
# cat sectors
120064896
#
/dev/hdf.
How does the BIOS know about the geometry? The user may have specified it in the CMOS setup. Or the geometry is read from the disk, and possibly translated as specified in the setup. In the case of SCSI disks, where no geometry exists, the geometry that the BIOS has to invent can often be specified by jumpers or setup options. (For example, Adaptec controllers have the possibility to choose between the usual H=64, S=32 and the `extended translation' H=255, S=63.) Sometimes the BIOS reads the partition table to see with what geometry the disk was last partitioned - it will assume that a valid partition table is present when the 55aa signature is present. This is good, in that it allows moving disks to a different machine. But having the BIOS behaviour depend on the disk contents also causes strange problems. (For example, it has been reported that a 2.5 GB disk was seen as having 528 MB because the BIOS read the partition table and concluded that it should use untranslated CHS. Another effect is found in the report that unpartitioned disks were slower than partitioned ones, because the BIOS tested 32-bit mode by reading the MBR and seeing whether it correctly got the 55aa signature.)
How does the disk know about the geometry? Well, the manufacturer invents a geometry that multiplies out to approximately the right capacity. Many disks have jumpers that change the reported geometry, in order to avoid BIOS bugs. For example, all IBM disks allow the user to choose between 15 and 16 heads, and many manufacturers add jumpers to make the disk seem smaller than 2.1 GB or 33.8 GB. See also below. Sometimes there are utilities that change the disk firmware.
9.1 Computing LILO parameters
Sometimes it is useful to force a certain geometry
by adding `hda=cyls,heads,secs'
on the kernel command line. Almost always one wants secs=63,
and the purpose of adding this is to specify heads.
(Reasonable values today are heads=16 and heads=255.)
What should one specify for cyls? Precisely that number
that will give the right total capacity of C*H*S sectors.
For example, for a drive with 71346240 sectors (36529274880 bytes)
one would compute C as 71346240/(255*63)=4441 (for example using
the program bc), and give boot parameter hdc=4441,255,63.
How does one know the right total capacity? For example,
# hdparm -g /dev/hdc | grep sectors
geometry = 4441/255/63, sectors = 71346240, start = 0
# hdparm -i /dev/hdc | grep LBAsects
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=71346240
# dmesg | grep hde
hde: Maxtor 93652U8, ATA DISK drive
hde: 71346240 sectors (36529 MB) w/2048KiB Cache, CHS=70780/16/63
hde: hde1 hde2 hde3 < hde5 > hde4
hde2: <bsd: hde6 hde7 hde8 hde9 >
SCSI device sda: 17755792 512-byte hdwr sectors (9091 MB)
Next Previous Contents