Re: Status of XP Dual Boot Problem -- a long comment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Jonathan Berry wrote:

I think it was somehow related to 2.6 kernel.
It was reported repeatedly during the test cycle but the actual
fix/workaround came after the release of core 2 if memory serves.

Would an attempt at an explanation of the problem help us get an answer to this?

Here is my attempt (long):

Modern ATA/IDE disks really can be considered to be addressed
by block number inside the disk.  (They have tracks and cylinders
and all that stuff, but the system outside of the disk is kept
totally insulated from the real tracks and cylinders.)

The first block of the disk has a table giving the starting
block number and number of blocks for all partitions.  That's
what most modern operating systems really use.  They make
read and write requests using the block number.

For a few legacy programs, an alternative is possible.  (This
sounds strange, but the motivation isn't necessary for this
explanation.)  A read or write request can be made by specifying
a Cylinder, Head, and Sector number to the BIOS subroutines on
the motherboard.  The BIOS translates this to a block number
using the BIOS geometry.  A geometry specifies the number of
heads per cylinder and number of sectors per track.  These numbers
are needed to figure out the block number to be read or written.

So again, a legacy application could specify a block by giving
a cylinder, head, sector number to the BIOS.  The BIOS translates
this to a block number using the BIOS geometry.  Then it translates
the block number to a different cylinder, head, sector number using
the "ATA/IDE interface geometry".  This is given to the disk which
uses this latter geometry to get a block number.  So there are TWO
geometries.

The partition table, in addition to giving the start and size of
partitions in block numbers ALSO gives the start and size of
partitions using cyl,head,sector under the BIOS GEOMETRY, and
also contains a table of the BIOS GEOMETRY.

There is a /proc pseudo-file that allows a program to access the
geometry, if it wishes.  Under the 2.4 kernel, the numbers there
were the BIOS geometry; under 2.6 kernel they are the ATA/IDE
interface geometry.

Anaconda, the Fedora installer, sometimes must update the
partition table.  (I don't know under what circumstances.)  It
probably uses one of the partition table utilities.  (I don't
know which; maybe parted?)  Apparently the utility works with
logical block numbers.  It then accesses /proc to get the
geometry values, puts those into the partition table and uses
them to compute the cyl,head,sector partition starts and puts
those in the partition table.

Fedora 1 install; works perfectly.

Fedora 2 install runs under 2.6 kernel and installs 2.6 kernel.
Resulting partition table has the wrong geometry!  It has the
ATA/IDE interface geometry instead of the BIOS geometry.  And
the partition boundaries in cyl,head,sector are computed with
the wrong geometry.  (They might not even be on a cylinder
boundary!  You will see mention of the attendant warning about
this by the partition editor in various posts.)

For running Linux, no worry!  It never uses the partition table
geometry nor the partition starts in cyl,head,sector.

For boot to Windows on a dual boot, sometimes, on some systems,
Windows would note the strange geometry and strange cyl,head,sector
partition starts in the partition table and refuse to boot.  A
shame, because Windows also apparently ignores them and uses
the block numbers when it is actually running.

The fixes were twofold:

If catching this before installation, then on both install
of Fedora 2 and when running Fedora 2 specify a Geometry
option on the "boot parameter line".  SPECIFY THE BIOS
GEOMETRY. This jammed the numbers you specified in the /proc
place and everything worked as on a Fedora 1/kernel 2.4
system.  That is the /proc supplied the BIOS geometry to
anything that asked, including the install partition editor.

If partition table was already messed up, various people gave
procedures to read the partition table, change the geometry
to BIOS gemoetry, recompute the partition starts in cyl,head,sector
using this geometry, AND NOT TOUCH THE PARTITION STARTS AND
LENGTHS IN BLOCKS which were correct already.  Then write the
fixed partition table.

There were also proposals to fix this for the future.  The most
reasonable proposal to me seemed to be twofold:
--an addition to /proc (a kernel patch) to provide the BIOS geometry
  as well as the ATA/IDE interface geometry
--a change to the partition editor used by anaconda to use the
  BIOS geometry /proc entry rather than the ATA/IDE geometry.

You could also see other possible changes, e.g. change the 2.6
kernel back to providing the BIOS geometry in the same place as
2.4 thus not requiring a change to the partition editor.

Now, what we need is for someone to look at the source code and
see if one of these schemes has been applied.  Sorry, I don't
yet have the background to know how to proceed with this last
step.


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux