Re: workaround for BIOS / CHS stuff

[Szakacsits Szabolcs]

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

And probably about other imaging (dd, partimage, mondo, etc), recovery,
etc, etc. tools. When they either just blindly copy old data or use the
broken kernel ioctl then the values can be incorrect.

If the partitions aren't boot partitions then this doesn't really matter
unless parted relies on the information and creates broken partition
tables.

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

So you basically get some random values (on all kernels) then making
decisions, asking questions from users based on that. Non-sense.

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

Not really. Broken parted (all of them out there curently) running on any
kernel (minimum 2.4, 2.6, etc) reporting the wrong, but same geometry will
be still inconsistent. The partition table stay still broken (aka, e.g.
you can't fix what parted broke). You're using broken tools, functions to
get a wrong result and you believe it's right. It's is not right of
course.

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

I helped many people to recovery their partition tables after parted broke
them several different ways. On all kernel versions. 

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

When I tried to resize an NTFS by parted it didn't allow me. At least
QTParted and SUSE's YAST can do it and sometimes parted shifts the
partition start (when it got the geometry wrong thus adjusted it to
cylinder boundary). Of cource this breaks the filesystem, because the
start position mustn't be changed during repartitioning the partition.

SUSE uses just parted, QTParted uses libparted for the partition table
manipulation.

You say, they are broken.

They say, parted is broken.

What's the truth then? 

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

Yes, used to. But because it wasn't reliable (see the destroyed partition
tables by parted running on 2.4 kernels), kernel even stopped guessing. 

> > They report the disk geometry and usually this is not what parted expects.
> 
> You mean "usually wrong".

Yes. Most often the number of logical heads are 240 or 255. But 2.6
kernels report often 16 in the problematic cases. Parted rewrites the
partition table with incorrect CHS, adjust to the wrong, imaginary
cylinder boundary thus the partition is gone, or in a better case it's
only unbootable.
 
> >    So the parted's faults became much more visible.
> 
> Parted's old semantics were the best possible semantics for 2.4.x, IMHO.

Although I've never used parted but based on users' feedbacks and
investigations of the parted damaged partition tables, my experience is
that parted was never a reliable partitioning tool. 

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

No. Parted is broken on 2.4 too and probably on all other kernels as well.
It's just not so visible like on 2.6.

One of the explanations why parted damages partition tables on 2.4
kernels,

   http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/4682.html

One example with recovery when parted damaged a partition table on 2.4
kernel,

   http://qtparted.sourceforge.net/forums/viewtopic.php?t=144

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

So 
    1) you're uncomfortable with the concept of an inconsistent partition
       table.

    2) kernel can't get the needed logical CHS in a reliable way to fill
       the needed entries in the partition table

still parted rewrites the CHS in the partition table based on info from an
unreliable source and being uncomfortable what it means.

Does fdisk do this? No.

Do Microsoft's fixmbr, fixboot, Windows reinstall do this? No.

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

Probably.

        Szaka