Installation of Win7 to iSCSI target on Skull Canyon NUC problem

Installation of Win7 to iSCSI target on Skull Canyon NUC problem - Printable Version

+- iPXE discussion forum (https://forum.ipxe.org)
+-- Forum: iPXE user forums (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: Installation of Win7 to iSCSI target on Skull Canyon NUC problem (/showthread.php?tid=9312)

Installation of Win7 to iSCSI target on Skull Canyon NUC problem - digitalis99 - 2017-04-17 19:03

First off, I know this may be a bit of a stretch for this forum, but I think I've narrowed my problems down to either iPXE itself or what I'm asking it to do. Here's my scenario:

I need to complete an installation of Windows 7 to an iSCSI target using an Intel Skull Canyon NUC, specifically a NUC6i7KYK model. I've successfully used iPXE in the past on a variety of hardware to do Windows 7 installs, but this NUC is giving me odd problems. Since it has only USB3 ports, I have to slipstream some drivers and updates into the Windows 7 install media so keyboard and mouse can work, as well as having access to the install media, since I've attached that via USB. This works if I leave the whole iPXE/iSCSI thing out of the loop. I can install Windows 7 to a local NVMe drive no problem. I mention this because the hardware platform is "newer" than the software I'm trying to install to it, and I know that information is relevant.

The problem comes in when I try to install Win7 to a sanhooked iSCSI target. My iPXE script is pretty simple:

Code:

dhcp

set keep-san 1

sanhook --drive 0x81 iscsi:<IPaddress>::::<iqn>

exit

Without the "--drive 0x81" spec, the bootup halts shortly after exiting iPXE with 6 letters displayed. I don't recall what those are right now (maybe "SLRBMG", or something like that), but I don't think it's too important as the install proceeds with the drive spec in place.

With the script in place as I've written above, the target is mapped by iPXE and the Windows install begins normally (off of a USB drive or USB-attached optical drive). The "Starting Windows" screen displays for about a minute, with the Windows logo pulsing. After that minute, the screen flashes and then the monitor goes to "no signal". The NUC is still running, but doesn't not respond to any mouse or keyboard input. It has to be hard powered down by holding the power button for a few seconds.

Obviously, something is different with the iPXE/iSCSI setup that is causing the install to fail at that point, but I can't figure out what it could be. Since an install from the same media to a local drive on the NUC works, I don't think it's driver-related issues.

I'm sure I need to provide more information for anyone to troubleshoot, so let me know what pieces are missing. Thanks for any and all time spent thinking about this.

RE: Installation of Win7 to iSCSI target on Skull Canyon NUC problem - mcb30 - 2017-04-18 11:36

(2017-04-17 19:03)digitalis99 Wrote:

Code:

dhcp set keep-san 1 sanhook --drive 0x81 iscsi:<IPaddress>::::<iqn> exit

Performing an installation via sanhook and then exiting back to the BIOS is not really expected to work. We have absolutely no control over what the BIOS does once we exit. For example, we have seen BIOSes that reset the number of INT13 drives, and BIOSes that zero random portions of base memory.

Try booting the Windows installer over the network instead. This avoids exiting back to the BIOS and so bypasses the uncontrolled behaviour. You can find instructions at http://ipxe.org/howto/winpe#installing_to_an_iscsi_target.

Michael

RE: Installation of Win7 to iSCSI target on Skull Canyon NUC problem - digitalis99 - 2017-04-21 17:29

Cool. I guess I've been lucky with the past several hardware platforms that I've done this on. The WinPE method looked confusing the first time I read through it, but I'm pretty familiar with WinPE as well...so I'll spend some time and see if I can make it work.

Thanks!

RE: Installation of Win7 to iSCSI target on Skull Canyon NUC problem - digitalis99 - 2017-04-22 00:38

So, I've made some progress on this approach. I have a Win10PE SE build that I'm trying to boot over HTTP. The initial initrd files all load, and wimboot starts. Then, wimboot throws this error:

Quote:Directory entry "PXE" not found
Emulating drive 0x80
Fatal: no bootmgr.exe
Press any key to continue

I searched the forums for a few key words, but I either get almost every post or none at all. Any idea what I should try next?

RE: Installation of Win7 to iSCSI target on Skull Canyon NUC problem - robinsmidsrod - 2017-04-24 08:42

digitalis99: I think this means that wimboot is unable to find bootmgr.exe inside the boot.wim you provided. If you can unpack it and provide it explicitly. Alternatively, your boot.wim might have a new directory layout which is not supported by wimboot. Are you using the latest published version of wimboot?

Wimboot can be hard to understand, as the Windows boot process is quite complicated. Hopefully you can figure out which part fails by reading this document: http://ipxe.org/appnote/wimboot_architecture

You might want to try with WinPE from an older version of Windows. Just use same architecture, 32 or 64-bit as the OS version you're installing. I think the version of WinPE I've had most success with is v4 (I think, it's the one analogous to Win7).

RE: Installation of Win7 to iSCSI target on Skull Canyon NUC problem - digitalis99 - 2017-04-25 19:22

(2017-04-24 08:42)robinsmidsrod Wrote: ...
Wimboot can be hard to understand, as the Windows boot process is quite complicated. Hopefully you can figure out which part fails by reading this document: http://ipxe.org/appnote/wimboot_architecture
...

Thanks for the pointer to that page. I hadn't seen that yet. Yes, I am running the latest wimboot version.

The reason for this issue became clearer after reading the wimboot page a few times. Turns out that bootmgr.exe couldn't be found because the only spot that wimboot looks for it is in \Windows\Boot\PXE\bootmgr.exe of the supplied .wim. Win10PE SE doesn't put that file there...in fact, there is no "PXE" directory at all...hence the exact error message I got.

The easiest fix was to simply point wimboot directly to bootmgr.exe via another line in the boot script:

Code:

imgfetch --name bootmgr.exe bootmgr.exe bootmgr.exe

This, of course, requires a copy of bootmgr.exe to reside in the same directory as your scripts. I implemented this change, and my custom Win10PE SE build booted right up!

Thanks for the pointers, guys.

After finally getting my Win10PESE image to boot successfully, I added in a sanhook line to attach to an iSCSI target so I could complete a Windows install to the target. After adding the sanhook command, I'm right back to where I was before...with Windows either turning off the monitor after initial boot or simply rebooting for an unstated reason. I've tried different --drive parameters, in hopes of them not colliding with what the Win10 boot image is setting up.

So...I'm right back to where I started after all the nonsense. My two ipxe scripts are...

Install.ipxe:

Code:

#!ipxe

prompt -k 0x197e -t 2000 Press F12 to install Windows... || exit

sanhook --drive 0x82 iscsi:172.16.5.13::::iqn.2008-08.com.microsoft:w7temp

chain boot.ipxe

boot.ipxe:

Code:

#!ipxe

cpuid --ext 29

kernel wimboot

initrd Boot/bcd                     BCD

initrd Boot/boot.sdi                boot.sdi

initrd sources/boot.wim             boot.wim

imgfetch --name bootmgr.exe bootmgr.exe bootmgr.exe

boot

Again, this boots successfully if I remove the "sanhook..." line from install.ipxe. I've tried the default --drive 0x80, as well as 0x81, 0x82, and 0x84. Any new ideas to try?