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.
