Re: a (late) question concerning the CHS disaster ...

[Sven Luther]

On Fri, Dec 03, 2004 at 04:07:42PM -0500, Patrick J. LoPresti wrote:
> Sven Luther <address@hidden> writes:
> 
> > > If you later install Windows, you will encounter problems.  This is
> > > why I took an interest in this stuff in the first place (see
> > > http://unattended.sourceforge.net/).
> > 
> > Bah, ...
> 
> Yeah, "it's Windows's fault".  But Microsoft is not exactly responsive
> to bug reports, and some of us have to live with their products, doing
> what we can to ease the pain.

/me is happy i use a plateform where i am now per default the one setting the
firmware/partition table standard :)

> > >   1) Move disk between machines
> > > 
> > >   2) parted /dev/hda
> > > 
> > >   3) mklabel msdos
> > 
> > You erased the whole disk, so anything you have done in the previous
> > machine is forgotten and you don't need to care about it.
> 
> Right, the problem is that the new machine's BIOS might use a
> different geometry than the old machine.

So what ? parted or whatever tool is used for partitioning sets the new
geometry accordying to what the new BIOS needs.

> > >   4) mkpart ...
> > > 
> > > What geometry will/should Parted use?
> > 
> > Anything parted thinks is sane. Preferably something windows will be
> > happy with, if we can find such a geometry, but as such a geometry
> > seems to be non-deterministic in general ...
> 
> Actually, it is completely deterministic and rather straightforward.
> The geometry returned by the legacy INT13/AH=08 BIOS interface always
> works for booting Windows.

So, why we don't use it ? 

> The only hard part is accessing that geometry from a protected mode
> OS.  The Linux EDD module makes it accessible, but you have to figure
> out which BIOS drive number corresponds to the disk you are
> partitioning.  This is easy in the common case of one or two drives,
> but it gets tricky fast with many drives on many interfaces.

So, non-deterministic in general ? 

> > > My code is in Perl, invoking the parted binary with the "-s" switch.
> > > I read /sys/firmware/edd/int13_dev80/legacy_* to figure out the
> > > geometry to use.  I write to /proc/ide/hda/settings to convince the
> > > kernel to return that geometry for HDIO_GETGEO.  I wipe the partition
> > > table in a separate step so that Parted will actually use that
> > > geometry instead of guessing.
> > 
> > I don't understand, there is this nice libparted library, so why in
> > hell are you calling the parted binary directly?
> 
> Because my code is in Perl?

So what ? 

> > I believe there is even a perl binding for libparted.
> 
> Interesting.  If it is current for Parted 1.6.19 and reasonably
> well-maintained, I will consider it...

$ apt-cache show   libparted-swig-perl
Package: libparted-swig-perl
Priority: extra
Section: perl
Installed-Size: 336
Maintainer: Yann Dirson <address@hidden>
Architecture: powerpc
Source: parted-swig
Version: 0.1.20020731-2
Depends: libc6 (>= 2.3.2.ds1-4), libparted1.6-0 (>= 1.6.0), perl (>= 5.8.4-1),
perlapi-5.8.4
Filename:
pool/main/p/parted-swig/libparted-swig-perl_0.1.20020731-2_powerpc.deb
Size: 76080
MD5sum: c8281cb6d21151e40785005bf096759c
Description: Perl5 bindings for libparted
 A perl5 library to read and modify partition tables, resize
 partitions, etc., using GNU libparted as a backend, and built using
 SWIG.
 .
 This is alpha software, this wrapper really lacks testing.

Well, i have no idea about perl, nor what SWIG is, and the 'alpha software'
part is not all that encouraging, but it exists. I guess it is 1.6.11 based at
least in debian, but the changes to adapt to 1.6.x (x>=12) are rather trivial.
Anyway, i have asked Yann for a 1.6.19 version to be uploaded to
debian/experimental together with the 1.6.19 packages there. The copyright
file says : 

  This package was debianized by Yann Dirson <address@hidden>, who is
  also upstream author.

So, Yann is also upstream author, and you are free to help out in its
maintenance or something for your software, i suppose.

> > > And it works.  But it is so messy...  And the Linux folks are
> > > threatening to remove HDIO_GETGEO.
> > 
> > Yeah, well, nothing i can do about this ...
> 
> I apologize if I sounded like I was yelling at you.

No, just, well, that is the kind of decision we somewhat have to live with. In
my opinion we could just as well get ride of windows and that would be that,
but as you said this is no solution.

Me wonders if lilo/grub or other boot-loaders, could not be made to understand
the new geometry, and convert it to a bios/windows friendly one, after all the
boot loader live at the right place for that ...

Friendly,

Sven Luther