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

[Steve Cross]

Robin, I WAS able to make it install (or at least I got about half way
through the install when I turned it off because I was installing from
network over WiFi (my stupid fault) and it was taking hours and I
finally said screw it and went to bed lol. I remember that I had to
use the 64 bit WinPE 3.0 from the AIK (I couldn't make the 32 bit
version load, it froze every time right before the WinPE wallpaper
would appear - I assume some weird quirk with VirtualBox because it
works fine on physical machines). If I remember correctly, I did a
sanboot to iscsi and then when that failed I had it continue on to
load the PE. I only had it set to sanboot for testing purposes, and
instead now I'd use sanhook and then load the PE.

I never had any luck with loading the Windows 7 disc (physically in
drive) after iPXE loaded in VirtualBox. I tried to exit out of iPXE
and let BIOS continue booting - failed with INT error message. I tried
with sanboot with any combination of drive number that I found online,
and it would always error out with some message or another.

I would definitely say, if you have a physical box that you can try it
on, it really does work much better. I fought for days trying to get
it to install to VirtualBox for the first time. It only took a couple
hours of tweaking the WinPE to get it to install to a physical box the
first time. I have since installed it to two other physical boxes for
testing purposes and it worked great.

Also, I did not have any of these problems with VMWare. I'm not a big
fan of VMWare myself, but for the iPXE testing it actually worked much
better than VirtualBox did. If you can't spare a physical box, I
encourage you to give it a shot in VMWare (assuming that you are just
trying this out for proof of concept before rolling out to physical
boxes).

-Steve

On Thu, Jan 3, 2013 at 4:03 AM, Shao Miller <sha0.miller at gmail.com> wrote:
> On 1/2/2013 21: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.
>>
>
> Aha.  That explains it.
>
>
>> 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.
>>
>
> Or maybe a boot from a "full" (4.7 GiB or whatever a DVD holds) ipxe.iso
> could work, followed by a physical optical disc swap?  Maybe not, as I guess
> all the El Torito info might be cached from the former.  But reads might at
> least work. :)
>
>
>> Unless I'm missing something, it's probably a better idea to just use
>> wimboot.
>
>
> Off-topic, but speaking of wimboot, someone at the reboot.pro forums
> reported iPXE -> PXELINUX 5.00 -> vesamenu.c32 -> linux.c32 -> wimboot
> wasn't working, so I'd like to look into that.  It could be a false alarm,
> though.
>
>
> http://reboot.pro/topic/17947-bcd-error-wimboot-out-of-memory-cant-allocate-memory-for-socket-structure/
>
> - Shao Miller
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel