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
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
