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

[Shao Miller]

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.

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

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?

- Shao Miller