Re: 2.6.x partition breakage and dual booting

[Patrick J. LoPresti]

Andries Brouwer <Andries.Brouwer@xxxxxx> writes:

> (i) Hardware:

[snip]

> SCSI disks never had this geometry nonsense.

Not in hardware, no.  But they very much have a geometry in the BIOS.
So do RAID controllers.  And all of this matters for a dual boot
system.

> All kinds of translation schemes were invented to give the BIOS
> interface a geometry different from that used at the ATA
> interface. The user chooses a translation scheme in the BIOS setup.
> The geometry is now unrelated to the disk, but is known to the BIOS.

But you better not change it, because it shows up in the partition
table.  And if the partition table geometry does not match the BIOS,
Windows will not boot.  (Perhaps there is a way to convince the
Windows boot loader to use LBA mode and ignore the partition table
geometry completely.  But I have not found it.)

> Various BIOS calls exist that report on various versions of the
> geometry.

"Various"?  I know of two, the legacy INT13 interface and the extended
INT13 interface.  Are there others?

> The fdisk aspect has also disappeared - after this geometry business
> had become infinitely complicated, nobody any longer tried to
> understand geometry, but just inferred from the partition table
> what geometry was used by the program that last wrote it.

Which is a terrible idea, because it does not work at all on blank
disks and it gives the wrong answer if you move a disk between
machines.  I may have mentioned this before.

> It didnt always work, but often it worked. (And only on i386 of
> course.)  Examples of failure: The code we had only asked the BIOS
> for info on the first two disks.

Today, right now, the kernel invokes both the legacy and the extended
INT13 interfaces for all disks which are visible to the BIOS.  The EDD
module makes all of these data available.

> Linux no longer makes any attempt to invent a geometry.
> If someone needs a geometry, he is responsible himself
> for choosing one of the many concepts of geometry, and
> determining a value. What most software does is looking
> at the partition table, and that works.

No, that does not work.  Not all the time, anyway.  And when it fails,
the failure is ugly.

> Maybe parted has not yet been updated to do this,
> that is why I conjectured that Fedora problems might be
> due to the use of parted.

Actually, Parted DOES infer geometry from the partition table.
Perhaps Disk Druid does not use Parted, or perhaps it uses distinct
invocations of Parted to 1) erase the old partition table and 2)
replace it with a new one?

> Was this a loss? I don't think so, but there is at least
> one use of the old situation that fails today:
> the installation of Windows systems from Linux media
> on a completely blank disk.

Actually, *any* attempt to install Windows after installing Linux will
run into this problem.

This is really very simple.  If you move a disk from a machine with a
different BIOS and you preserve the partition table geometry, you will
NEVER be able to install Windows on the drive.  If you partition a
blank drive and use the wrong geometry, you will NEVER be able to
install Windows on the drive.

The correct solution is to use the legacy INT13 geometry when
partitioning the disk, regardless of what you already find there.
(For partition table purposes, the cylinder count is irrelevant; only
"heads" and "sectors" matter.)

Yes, this means you have to map between BIOS disk numbers and Linux
devices, which may require heuristics.  But those heuristics can be
improved over time, whereas relying on the existing partition table
will always be just plain wrong.

 - Pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/