Floris, I'm a little late reading this email, but you say that you are having issues with Windows iSCSI on the Intel NUC series. I am curious which exact NUC model you are using. I ask because I have three here at my house all running completely diskless iSCSI and have been for nearly two years without issue. Perhaps I could provide some assistance. I apologize if you already provided this information, I managed to lose all emails prior to this one.
Steve *Steve Cross* [email protected] On Thu, Oct 30, 2014 at 11:31 AM, Floris Bos <[email protected]> wrote: > On 10/30/2014 02:02 PM, Michael Brown wrote: > >> >> - iPXE communcation seems to end with an iSCSI read response, iPXE ACKs >>> nicely >>> - then there is this long wait on Windows startup (waiting for disks?), >>> and during that there are some TCP retransmissions of an iSCSI NOP >>> command trying to keep the connection warm from SAN to virtualbox. >>> - straight after that Windows takes over, there is some DHCP/ARP traffic >>> (not shown below), a LLMNR request for wpad, and a new iSCSI login. >>> >>> <snip> >>> >>> - Seems the iSCSI read response is retransmitted lacking the last ACK. >>> Those packets may arrive when Windows is about to take over. >>> - Windows does not seem to do any iSCSI communication >>> >> >> Fantastic debugging work. Could you possibly copies post the two >> captures (either as attached raw .pcap files, or uploaded to >> https://appliance.cloudshark.org/upload/ ? >> >> > https://www.cloudshark.org/captures/a781ff622adc > https://www.cloudshark.org/captures/0968b06118f5 > > > Note that some communication is missing. > E.g. traffic between the virtualbox VM where Windows is being installed > (192.168.178.4), and the virtualbox VM that plays for DHCP/installation > server (192.168.178.100), doesn't touch the host system and therefore isn't > in this capture. > > > The iBFT is not created until you attempt to boot from the SAN target. >>>> >>> >> My mistake; the iBFT is actually created at the moment of the "sanhook" >> command, which would give time for any warning message to be displayed. >> The architectural issue is then that iPXE has no mechanism in place for >> displaying non-fatal error messages. We could make int13_describe() return >> an error, but this would then prevent the SAN device from being hooked. We >> could hack a printf() into int13.c, but that kind of crossover between >> mechanism and policy is the kind of ugliness that I've worked hard for over >> a decade to eliminate from this codebase. >> >> Since it's a fairly pathological system in which the memory above 512kB >> is all used by the time iPXE starts up, and since it's definitely not the >> cause of the problem you're experiencing, I don't propose to do anything >> about it now. >> > > Did had that issue on other systems, and still think not getting any > warning and it mysterically failing is very annoying. > Affects the Intel NUC series, and doubt I'm the only one that tried to use > those in diskless setups. > > > Yours sincerely, > > Floris Bos > > _______________________________________________ > 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
