Hello Robin, Shao, (Some snipping being done)
On Fri, Jan 4, 2013 at 7:28 AM, Robin Smidsrød <[email protected]> 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 > [email protected] > https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel _______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
