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

[Andrew Bobulsky]

Hello Robin, Shao,

(Some snipping being done)

On Fri, Jan 4, 2013 at 7:28 AM, Robin Smidsrød <robin at smidsrod.no> wrote:
>
> 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:
> >>  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?


I really wish I knew why that particular problem happens; the
black/white/gray error messages are from BOOTMGR.  The Windows Boot
Manager has always had some kind of issue booting from an iPXE SAN
device that isn't mapped as disk 0x80.  Given that, your success
booting the disk as drive 0x80 isn't at all surprising, but the fact
that you got some kind of error at all really is.  I don't have too
much to add to this other than my curiosity, though ;-)

>
> >>> 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,


I checked into this, and came up with some interesting results using:

- WinPE 3.0 (x64) from the MS WAIK (with wimboot)
- ipxe.pxe (09cc), chainloaded from vbox iPXE
- 100 GB iSCSI disk sanhook'ed as 0x80 (no local disk)

The VM booted up as expected.  No problems.  DISKPART showed a 100 GB
disk, and Windows Setup showed and installed to the disk.  The
"Expanding Files" step was excruciatingly slow... probably because of
the forced routing thing.

Next, the same as above, only instead with the BOOT.WIM from the
Sources folder off of a Windows 7 RTM installation media (to properly
replicate Robin's setup):

WinPE loads up with wimboot in an uneventful fashion.  This time, I
run diskpart and see no disks attached.  "ipconfig" shows no IP
address, so I manually run "wpeinit" and after a few seconds, the
iSCSI disk is attached.  As it turns out, in the BOOT.WIM present on
the Windows 7 installation media, "wpeinit"--which starts up
networking support--doesn't appear to actually run until you click
"Install Now" on the Windows Setup dialog.  Were you still unable to
see the disk after that point?

>
> > 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?


Tool building... sort of.  My best efforts at Google-Fu on this matter
don't appear to show a checked/debug build of WinPE or WAIK.
Suggestions range from swapping out the kernel booted by WinPE with
the one from a checked build of Windows, and editing the BCD of WinPE
to use it.  However, since the goal here is to snoop on the iSCSI
Initiator more than anything else, the best option seems to be to get
the checked build of Windows 7, extract the driver for the iSCSI
initiator, and slip it in to the WinPE.  If anyone is aware of a
method to get a hold of a checked/debug version of the iSCSI initiator
without requiring access to MSDN, I'd be happy to write a script for
this.

The rest of the puzzle is to simply attach the Windows debugger to the
VM, and configure the WinPE BCD appropriately, of course.

>
> > 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?


My super power is to show up late!  Huzzah! :P

The only thing I can further add is regarding the problem of booting
against the local installation media.  Virtualbox doesn't like exiting
the PXE ROM and continuing on, and it also looks to bug out when iPXE
tries to invoke the local disk via the "sanboot --drive" command.
So... I slipped GRUB4DOS into the mix and got that to work _very_
well:

#!ipxe
sanhook iscsi:drew-san.drew.local::::iqn.2013-01.local.drew.drew-san:vbox
set filename ${boot-url}/grub4dos/grub.exe
chain ${filename} --config-file="cdrom --init;map --hook;root
(cd0);chainloader (cd0);boot"

Installation proceeded quite nicely, too! :)

Cheers all around, and best regards!

-Andrew Bobulsky

>
> -- Robin
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel