Re: scsi and windows boot problem

[Patrick J. LoPresti]

Szakacsits Szabolcs <address@hidden> writes:

> Reproducing the problem is a no-brainer on any computer.

Are you SURE about this?  I ask because Andrew is not alone in being
unable to reproduce the problem.  For example:

  https://www.redhat.com/archives/anaconda-devel-list/2004-June/msg00080.html

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

That is, I suspect this problem only afflicts machines with "smart"
BIOSes that adapt their behavior to the partition table.  On these
machines, changed partition table => changed legacy BIOS geometry =>
mismatch between legacy geometry and Windows BPB => boot failure.

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

But the ioctl() certainly leaves much to be desired.  What Parted
needs are command-line switches to let the user force the geometry.
(By "user", think installation systems like Anaconda, not end users.
Remember that installation systems make up 99.9% of Parted's users.)

> The HDIO_GETGEO values are the same for SCSI in 2.6 kernels than
> earlier.

True.  In addition the H/S values are almost (?) always 255/63 for
SCSI devices.

> It's also possible that either one or more of these are true,
> 
>    - since less people use SCSI thus this problem is less visible

Maybe, but I doubt it.

>    - booting from SCSI doesn't need the geometries (usually) so it was
>      never (usually) a problem on SCSI

Definitely not.  The Windows boot loader uses the BIOS, which makes no
distinction between IDE and SCSI devices.

>    - HDIO_GETGEO always returned the parted expected value, so it
>    always worked

Yes.

 - Pat