Re: workaround for BIOS / CHS stuff

[Andrew Clausen]

On Sat, Jun 26, 2004 at 10:54:01PM +0200, Szakacsits Szabolcs wrote:
> 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.

Well, a Microsoft operating system will always get it right.
So, if a Microsoft operating system wrote the BPB, then we can use it.

> 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
> "correct" geometry.

Ah, good point.  I didn't think about linux ntfs tools.

> > 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?

At this stage, yes.

> 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.

Well, if the HDIO_GETGEO is consistent with partition table, it's
consistent.  If it isn't, then Parted tries to figure out what is.

>  - 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.

This only happens after a resize.  Let me clarify how partition tables
work.  Each partition has its start and end values stored twice.  Once
in LBA form, and once in CHS form.  Parted always keep the LBA the
same (unless you resize).  It will update the CHS form to be consistent
with its view of the BIOS's CHS geometry.

>  - 2.6 kernels: they don't try to guess the BIOS geometry anymore.

You mean, they don't ask the BIOS anymore.  They used to.

> They report the disk geometry and usually this is not what parted expects.

You mean "usually wrong".

>    So the parted's faults became much more visible.

Parted's old semantics were the best possible semantics for 2.4.x, IMHO.

>  - 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
>    lately, etc).

Agreed, it's something we should look at when it matures.

> 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?

Yes.

> > 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".

Consistent means that if you compute the CHS start/end values for
a partition from the LBA values, then "everything matches".

> > 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.

Parted wasn't aggressive enough at checking consistency (it should have
checked all primary partitions, at least).  It is more aggressive now.

> > 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.

For 2.4?  I didn't notice this.  I thought these were all 2.6.

> I can't really see what parted really fixes "silently" on 2.4 kernels.

I'm not sure if there are any recent examples.  (It's surprisingly
hard to get evidence!)  At one stage, for example, Partition Magic
couldn't cope with inconsistent partition tables.  Parted fixed this,
and PM could then work.

I'm uncomfortable with the concept of an inconsistent partition table.

> 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.

You mean "asking the BIOS"?

Cheers,
Andrew