[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: workaround for BIOS / CHS stuff
Re: workaround for BIOS / CHS stuff
Sat, 26 Jun 2004 22:54:01 +0200 (MEST)
On Sat, 26 Jun 2004, Andrew Clausen wrote:
> Steffen Winterfeldt at suggested we use data contained in Microsoft file
> systems to determine the BIOS / CHS geometry, if there are any.
If CHS in the BPB's aren't "correct" then Win doesn't boot. Whether this
has anything to do with the CHS in the partition table or not, I don't
know but I suspect there is relation.
Of course there are cases when the above approach doesn't work, e.g. if it
has "incorrect" values (disk was moved, cloned, corrupted, etc). Ntfsck,
mkntfs, ntfsclone have the same problem as other tools that need the
logical geometry. Nobody knows how to get the right values to fix/set the
> Here's a summary of the new semantics:
> * read in the main partition table (i.e. don't look inside extended
> partitions yet)
> * check if the partition table is consistent with the BIOS geometry.
AFAIK you use HDIO_GETGEO to get the BIOS geometry, right? But that's
wrong. It never told the BIOS geometry. It never told what you thought it
tells. This is one of the fundamental problems with parted, AFAIS.
- 2.4 kernels: they tried to guess out the BIOS geometry and most of the
time they could. So parted most of the time works but not always. When
parted fails then
1) bootloaders can fail
2) partition start can be incorrectly shifted to a cyclinder
boundary based on the wrong CHS <--- this is much more serious
then 1) and nobody tried to fix this in parted.
- 2.6 kernels: they don't try to guess the BIOS geometry anymore. They
report the disk geometry and usually this is not what parted expects.
So the parted's faults became much more visible.
- EDD: apparently some 2.6 kernels has the "right" info but at the same
time it seems quite inmature (interface was planned to be changed
In short, I don't know any way to get the BIOS geometry in a reliable way
on all potential kernels. Although I've never looked for a solution, I've
also never met anybody who could point out a way to get this info reliable
on all kernels.
> * if it isn't, then first try looking in Microsoft file systems.
You mean the values in the BPB, right?
> If that works, quietly adopt the Microsoft geometry. If it doesn't
> work (because the FS is very broken, or there are no MS file systems),
> then the old technique of searching for a consistent geometry applies.
> If a consistent geometry is found, the old warning comes up explaining
> the situation.
I can't comment these, I don't know what was the "old way" and what you
mean under "consistent geometry".
> Note: as always, Parted will write the CHS values it believes are
> correct for every partition,
The real problem seems to be is that, there isn't a reliable way on Linux
to get the correct CHS. So not being conservative means playing lottery. A
lot of people lost already.
> rather than conservatively keep the partitions the same unless they
> change. I think this is a good strategy if Parted is good at
> detecting geometry, but a bad strategy if it gets it wrong badly.
> Before the 2.6.x issues, this seemed to work well, because it quietly
> fixed lots of problems :)
Not true. Parted breaks people's bootability and sometimes even the
partition layout on 2.4 kernels too. I've sent you URL's where these
Parted problems were analyzed, fixed, pointed out.
I can't really see what parted really fixes "silently" on 2.4 kernels. I
only see it breaks things there, too. But luckily not so often as on 2.6
kernels, thanks to the 2.4 kernels guessing the BIOS geometry.