[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scsi and windows boot problem

From: Szakacsits Szabolcs
Subject: Re: scsi and windows boot problem
Date: Wed, 21 Jul 2004 09:27:24 +0200 (MEST)

On 19 Jul 2004, Patrick J. LoPresti wrote:
> Szakacsits Szabolcs <address@hidden> writes:
> > Reproducing the problem is a no-brainer on any computer.
> Are you SURE about this?  

You, yourself, gave detailed, step by step instructions how to do it ;-)
But to be fair, in a different context :-)

> I ask because Andrew is not alone in being unable to reproduce the
> problem.

I dont expect Andrew to understand anything for a long time (he didnt even
understand much simpler things in the past). He was explicitely told what
he should do 8 months ago. He is finding all kind of excuses since then.
The problem isn't technical for a while but Andrew himself. The fix is
perhaps some hours work.

> I have already explained my current theory (search for "my current
> theory"):
>   http://groups.google.com/groups?selm=2dU05-3TT-5%40gated-at.bofh.it

I've read it earlier already. Your contribution in all these threads was
far the most productive. Some of your remarks explain things but
ironically they're irrelevant for fixing the bootability problem parted

You wrote a lot of correct things what I agree too but it seems you're
seeing the issue mostly from the point of view of your own problem.

You mentioned "the problem with NTFS ...". It's not an NTFS problem only.
It's a FAT32 problem too. Most people think it's an NTFS issue because in
the last 2-3 years Windows people migrated from Dos to NT. The kernel
HDIO_GETGEO also changed during this time so you couldn't really see this
problem in parted before with FAT only now with mostly NTFS.

You wrote about "the Windows bootloader". There isn't Windows bootloader.
There are many bootloaders. There are also many Windows bootloaders. The
boot process also depends on Windows configuration settings and other
factors if it should and if yes then how, when it should use BIOS or not.

When parted randomly overwrites the HS values in the partition table,
based on the kernel's meaningless HDIO_GETGEO values then it randomly
_might_ break different configurations, boot setups.

Parted shouldnt have ever changed the HS values. In other words "if its
not broken, dont fix it". Yet in other words "if you dont know what
certain values mean then dont touch them".

Whats hard to understand? Inconsistent or empty partition table? Those are
_different_ problems. Don't mix a simple partition modification with them.

Andrew wants to make a HS consistency check. Thats very nice but he doesnt
know what consistency means. He thought HDIO_GETGEO tells. He was always
wrong as Andries Brouwer, the guy who plays with HDIO_GETGEO and
basically the root cause for this serious problem, told him many times.

> > Anthony, parted uses a kernel function (HDIO_GETGEO ioctl) what it
> > should have _never_ used.
> Debatable, since that ioctl() exists in every version of Linux back to
> the 1.x days.  And there was no viable alternative until kernel 2.6.5
> or so, and there is still no viable alternative for 2.4.x.

There are many geometries. BIOS legacy, BIOS extended, CMOS, disk,
whatever. HDIO_GETGEO tried to be all of them at the same time.  It didnt
work because it's logically impossible since they are not always the same.

A decent parted maintainer would have noticed this in the last 5 years.
Andrew still dont get it and he is still quite lost and confused. Again,
this is not the only case when he has major difficulties to understand
simple things.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]