ipxe not booting 2nd stage of windows 7 install correclty -- please help!

[trigger]

Hi Guys,

I am tearing my hair out trying to figure out what's going on! If someone is able to help i would be most grateful!

I have a ITX client that is to run windows 7, booting from a synology nas using iscsi.

Originally i had it with a 1GB IDE DOM, which had ipxe loaded, this allowed me to boot and get the iscsi then go into windows setup via a USB cd room (with windows 7 SP1 x32bit) in it, it will then install windows on the 25gb iscsi drive wich it detects. Now it also detects the 1GB DOM and the DOM is the first drive (this is what i thought the problem was originally). Then after its installed its files and needs to reboot to go into the 2nd stage of the install, when it reboots it gets to the windows starting logo and goes no futher. On the Synology i can see it connect to the iscsi and then after about 20secs, its not connected any more (but the windows start-up logo/screen is still pulsating away, forever).

So i heard that iscsi doesn't like working when its not the first drive, so i removed the 1GB DOM and am chainloading from the realtek adaptor into ipxe and have reinstalled and set it up the same again... but its still doing the same thing - any ideas?

Thanks,
Trig

[robinsmidsrod]

Most likely you have the same problem most other people have with Windows and iSCSI, that your router is not routing packets back to the local network, and the Windows iSCSI initiator (client) has a bug that it doesn't talk directly to the iSCSI target server, but always go via the default gateway.

You can avoid this problem by using the command set netX/gateway 0.0.0.0 just before the sanhook/sanboot command in your iPXE script.

Alternatively you have your iSCSI target service setup to only allow a certain initiator IQN, and when you start Windows it'll take over and use another initiator IQN than iPXE. If you try to do a packet capture (http://ipxe.org/howto/pcap) you'll probably see a failed iSCSI login with the Windows-based initator IQN. Adding the Windows initiator IQN to the iSCSI target's access list should probably solve that problem (if it is indeed your problem).