[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