Re: workaround for BIOS / CHS stuff

[Patrick J. LoPresti]

Andrew Clausen <address@hidden> writes:

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

There certainly can be a relationship.  I have seen systems where the
BIOS geometry CHANGES between boots based on the geometry used in the
partition table.

I believe this is the source of many problems with Parted + 2.6
kernels + dual-boot.  The sequence of events is:

  1) Windows gets installed on blank drive using original BIOS
     geometry (X/255/63).  BPB contains this geometry.

  2) User installs FC2 or Suse 9.1 or whatever.  Parted queries kernel
     to get LBA geometry (Y/16/63).  Parted rewrites partition table
     to use this geometry.

  3) User reboots, BIOS probes partition table and adapts to new
     geometry.  Windows boot loader uses geometry in BPB to construct
     calls to BIOS.  Whoops, Windows cannot boot.

And yes, I can confirm that some BIOSes do this.

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

Unless the disk has just been moved between machines, in which case
you risk breaking everything.

Parted needs a mechanism to let me FORCE the geometry it uses.  Every
other partitioning tool has this, usually via command-line switch.

I hate "smart" software.  No matter how smart it is, I am still
smarter.  Please give me a way to tell the tool what to do.

> > AFAIK you use HDIO_GETGEO to get the BIOS geometry, right?
> 
> At this stage, yes.

At present, this is the only way I have to pass the geometry to
Parted.  I feed values to /proc/ide/hda/settings, run Parted once to
blow away the partition table, then run it again to actually partition
(thus bypassing the guesswork).

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

The interface is stable as of 2.6.7.  The fields are named
/sys/firmware/edd/int13_dev80/{legacy_max_cylinder,legacy_max_head,legacy_sectors_per_track}.
This is a 100% reliable way to determine the correct geometry to use.
A backport to the 2.4 kernels is in progress.  The only problem is
mapping between BIOS device numbers (dev80) and Linux devices...

It is true that there is no reliable way to get the geometry on all
possible kernels.  But it is also irrelevant, because Parted should
not be worrying about this at all.  Parted needs an interface to let
people specify the geometry.  Then distribution makers, who know
exactly what kernel they are using, can do whatever magic they want to
deduce the geometry and then pass that information to Parted.

Having such guesswork in Parted itself is a design error, if you are
designing a system in which Parted is merely one component.

 - Pat
   http://unattended.sourceforge.net/