Re: Dual Boot / Hal.dll
- From: John Hensley
- Date: Thu, 17 May 2007 20:10:16 -0400
On Thu, 17 May 2007 12:41:01 -0700, Monsterdog
<Monsterdog@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
John,
Thanks for the info about finding the signature. I'm basically going to
assume that the signature line is correct for now. I mistyped earlier.
Where I wrote rdisk I meant to write just disk. I also don't think it has to
do with windows update anymore.
What I meant to say:
The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
disk value of one, I thought disk should be zero almost all the time.
You are correct, the KB article says disk is always 0 for a drive
accessible via the ROMBIOS. Unfortunately it does specify what it
should when using Signature(). The example use a 1.
XP can't boot from a drive that isn't accessible by the ROMBIOS using
a multi() boot.ini string.
Doesn't the fact that 'map arc' gives me a multi() format line show that the
drive is accessible through the bios? I would have thought that that line
would work.
(This section became irrelevant after I re-read the documentation for
Signature() but I left it un because it might be interesting but don't
waste any time trying to doing any of the suggestions. The real
solution is down below)
The reason for this is that when 'map arc' runs it is going through
the normal disk driver which reads sectors from the disk directly
through the disk controller and gets the correct disk geometry
directly from the drive itself.
When NTLOADER runs it uses the ROMBIOS to read sectors and if the
ROMBIOS is not setup with the correct disk geometry everything past
the first cylinder might be useless because the disk layout is
incorrect.
If the geometry is correct but the ROMBIOS does not support > 1024
cylinders and the hal happens to be located someone on the disk past
the first 1024 cylinder it won't be access able.
The only way I know to test for this would be to boot from an MS-DOS
floppy, run debug and then enter some assembly code to query the
layout of the drive and see if it matches the real drive layout.
One more thing that could be an issue is if the large drive contains
special software like OnTrack in the first track that hooks the int
13h interface to provide the correct layout for the drive or
implements the int 13h large disk extensions. You could test for this
by swapping the mapping of the drives so that the problem drive is
seen as the first drive. The ROMBIOS may support this and if not you
could simple reverse the master slave order or change the cable if
each driver is on a separate cable.
If booting from the drive this way works it would confirm that OnTrack
type of software is installed on the drive.
I guess the purpose of the signature syntax is to overcome bios limitations?
Is that why it uses a disk(1) when the 'map arc' produced multi line uses
disk(0)?
I re-read the KB article about signature() one more time and saw
something else I missed. The signature() arc name is equivalent to the
scsi() arc name which means that you need to have the driver file
located in the root directory of the boot drive. You need to copy the
Ntbootdd.sys from the second drive to the first drive and use the
signature() arc format.
I knew about this requirement when using the scsi() arc name but I had
never seen anything about signature() arc names. Your reference to it
made me curious enough to start this exchange. Now everything almost
makes sense. The documentation says that for multi() the disk(0) means
to use the bios but for scis() the disk() value specifies the scsi
unit id. I'd bet that since under multi() the disk(0) means use the
ROMBIOS under Signature() the disk(1) means don't use the ROMBIOS. The
documentation is not clear about what should be used here but I'd
first try disk(1) and if that doesn't work make sure to use the number
that matches the unit the drive is on the controller (0 for master 1
for slave).
Let me know whether this works, which value you used for the disk()
value and whether the drive is a master or slave. This information
will most certainly be useful to me in the future.
BTW if it makes it easier you can email me directly using "john at
resqware dot com" after replacing the at and dot.
Regards,
John Hensley
www.resqware.com
.
- Follow-Ups:
- Re: Dual Boot / Hal.dll
- From: Monsterdog
- Re: Dual Boot / Hal.dll
- References:
- Re: Dual Boot / Hal.dll
- From: John Hensley
- Re: Dual Boot / Hal.dll
- From: John Hensley
- Re: Dual Boot / Hal.dll
- From: Monsterdog
- Re: Dual Boot / Hal.dll
- Prev by Date: Re: usb2 hardware but no usb2 function
- Next by Date: Re: cd-r and windows
- Previous by thread: Re: Dual Boot / Hal.dll
- Next by thread: Re: Dual Boot / Hal.dll
- Index(es):
Relevant Pages
|
