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

Shao Miller sha0.miller at gmail.com
Thu Jan 3 01:36:30 UTC 2013


On 1/2/2013 19:36, Michael Brown wrote:
> On Wednesday 02 Jan 2013 23:52:00 Shao Miller wrote:
>> D'oh.  I guess issuing our own INT 0x13, AH=0x4C would be too ugly?
>
> I don't see how it can work.  INT 13,4c requires a filled-in specification
> packet, which is what INT 13,4b01 is supposed to return.  Since INT 13,4b01 is
> returning failure on all drive numbers, I don't know where we would get the
> information to pass to INT 13,4c.

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

If "Initiate Disk Emulation" hasn't yet been engaged, then might there 
not even _be_ an INT 0x13-accessible optical disc drive?  Isn't it sheer 
luck if the BIOS has provided such access prior to examining if the disk 
has floppy, HDD, or no emulation?  I thought the drive number assignment 
wasn't guaranteed to happen until BIOS used its internal driver to 
examine the ISO9660 and populate the specification packet.

Until paying closer attention to what was in this thread, I assumed that 
iPXE was doing a simple BIOS fall-back.  That was a mistake!

For what it's worth, GRUB4DOS and Smart Boot Manager have an ATAPI 
driver and can do the sort of thing BIOS does, but it seems kind of 
out-of-scope for iPXE. :)

If I'm right and there's no guarantee of any INT 0x13-accessible optical 
disc drive and it's sheer luck, then maybe we could test our luck from 
populating as much of the spec. packet as possible using lower INT 0x13 
reads and manually processing the El Torito info?  Maybe the packet size 
and drive number would even be sufficient.  Heheh.

- Shao Miller



More information about the ipxe-devel mailing list