[ipxe-devel] FATAL: int13_eltorito: call with AX=4d00. Please report

[Robin Smidsrød]

On 03.01.2013 15:27, Shao Miller wrote:
> On 1/3/2013 03:47, Robin Smidsrød wrote:
>> On 03.01.2013 03:08, Michael Brown wrote:
>>> On Thursday 03 Jan 2013 01:36:30 Shao Miller wrote:
>>>> Sorry, I wasn't paying close enough attention.  I actually don't fully
>>>> understand how int13_load_eltorito() can ever be expected to work
>>>> without iPXE already driving the optical disc drive using, for example,
>>>> an ATAPI driver. :)
>>>
>>> The code in int13_load_eltorito() is intended to allow iPXE to boot
>>> from one
>>> of its own SAN drives.  The fact that "sanboot --drive XX" can be
>>> (ab)used to
>>> boot from a local disk is just an unofficial side benefit.
>>>
>>> One possible hackish workaround for this particular scenario would be
>>> to SAN-
>>> boot from an ISO which matches the local CD-ROM.  The SAN boot would
>>> provide
>>> access via INT 13, and the loaded OS would find the (identical) local
>>> CD-ROM
>>> after starting the kernel.
>>
>> Interesting. I tried it out, and it failed also, but with a twist. First
>> of all I had to hook the iscsi volume as drive 0x81 (0x80 just wouldn't
>> do) and the DVD as drive 0x80. If I didn't do that I just got an error
>> message that the BCD was unreadable (0xc000000e). When I booted the
>> installer as drive 0x80 (with the DVD also in the local CDROM) it went
>> quite a lot further, and then it failed with 0xc00000e9 (unexpected I/O
>> error). I'm starting to wonder if it actually has problems reading the
>> data either from the web server or the local drive. Anyone seen this
>> before? My Apache configuration is the same as the one that has always
>> worked for other netbooting.
>>
> 
> Was 0xC00000E9 on a black screen with grey text (as in, BootMgr)?  Or
> was it a "Blue Screen of Death"?  If the former, it doesn't get as far
> as executing the NT OS kernel.  If that's the case, it'd be interesting
> to know what the cause of the failure is...  Perhaps DEBUG=int13 or some
> such could reveal something.

They were both grey text on black background. When I built with
DEBUG=int13 I didn't get any additional error messages on my console,
and not in syslog, which makes me wonder if the build actually uses
debugging. The strange thing is that the Windows 7 installer now
actually booted up all the way (and didn't show any iSCSI disks). Is it
possible this could be a race condition or something which adding
debugging made go away?

>>> Unless I'm missing something, it's probably a better idea to just use
>>> wimboot.
>>
>> I was actually trying (again) to boot Windows 7 off iSCSI, and I was
>> testing things out in VirtualBox. I was using wimboot, and my iscsi
>> volume never showed up in diskpart,
> 
> This seems like such a common problem...  For iSCSI, it'd be good to use
> Microsoft's tools to find out if the iBFT is present.  If it is, then
> it'd also be good to find out "how much" the device is present: Is there
> an iSCSI controller device (in Device Manager, for example), does it
> have the SAN disk as a child node, is the disk interface exposed (to
> Disk Management, for example).

Do you know about some kind of documentation from MS that tells you how
to do this kind of debugging inside WinPE, or do we have to do it all
manually, that is, build our own tools?

> Sometimes it's a network-settings-related obstacle (the whole "explicit
> route" thing, for example), sometimes it's NIC-driver-related, but the
> most mysterious case (in my opinion) is where everything looks like it
> really should be working (disk interface present, explicit route
> present, iSCSI traffic observed to flow when DDing to the disk interface
> from Windows), but just the DISKPART and Windows installer seem to
> malfunction/complain.  I believe Andrew Bobulsky might have some
> suggestions about that most mysterious case.  Andrew?

-- Robin