[ipxe-devel] Windows 2016 and ipxe boot
Hello, I've been testing Windows 2016 Server and ipxe. I can get it working on a Xen setup, but have trouble getting it to work on Hyper-V (the server is 2012R2). ipxe successfully loads bootmgr but it seems that bootmgr has trouble loading winload.exe to continue the boot. I receive an error from bootmgr that it failed to read the disk. Enabling debug output in ipxe shows a disconnect with: iSCSI 0xf0134 closed: Connection timed out (http://ipxe.org/4c0a6035) INT13 drive 80 went away: Connection timed out (http://ipxe.org/4c0a6035) INT13 drive 80 extended I/O failed: Connection timed out ( http://ipxe.org/4c0a6035) INT13,42 (80) failed with status 04 Debugging the load process the problem seems to happen when bootmgr transitions to 64bit. Also a little before it happens there are quite a few remaps: INT13,15 (81) remapped to (80) INT13,41 (81) remapped to (80) INT13,48 (81) remapped to (80) INT13,08 (81) remapped to (80) INT13,42 (81) remapped to (80) INT13,42 (81) remapped to (80) INT13,42 (81) remapped to (80). As the transition from 32-bit to 64-bit is a bit hard to debug, and I'm not so sure I've understood the remap code I wanted to ask if someone here had a clue before diving in both directions. Thanks, Eytan ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
[ipxe-devel] Ipxe and booting of Win2016 on HyperV guest
Hello, I've been having issues using ipxe to boot Windows 2016 on a HyperV guest (have managed booting Windows 2016 on other platforms). I started debugging the various issues: 1. The first issue is that the Windows 2016 winload.exe wants to look for a security related registry hive on the system partition. The code to do this recognizes that is running on a VM and therefore tries to initialize the VMBUS to use the disk via VMBUS (and not via INT13) -- this causes winload to take over ipxe's VMBUS connection. But afterwards it reverts back to INT13's that try to use the network interface which uses the VMBUS connection and hence winload fails. I've created a very ugly workaround that just fails winload's takeover attempt but I will need to find a better solution. 2. Afterward winload completes successfully but the kernel gets deadlocked, first when trying to query the IDE controller (but since I'm using a sanboot I can disable them) but then when trying to use the VMBUS to use the Network Adapter. I've managed running the same test using the Legacy Network Adapter meaning iPXE doesn't use the vmbus at all -- and everything works as expected. As I'm not so familiar with the iPXE/vmbus code I was wondering if anyone has any information that can help. Can it be that to solve (2) iPXE has a way to do better cleanup of the vmbus (it seems that the code checks for certain protocol versions etc.) -- also any ideas to solve (1) -- except for the sabotage that I currently have or code in iPXE to re-take control of the interrupts? Thanks, Eytan ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
Re: [ipxe-devel] Problem with ipxe on Xen 4.4
Hi, Sorry for the delay, Managed to test it locally too and it seems to fix the problem, Thanks Too! E On Thu, Dec 28, 2017 at 2:16 PM, Michael Brown <mc...@ipxe.org> wrote: > On 26/12/17 12:47, Michael Brown wrote: > >> On 25/12/17 11:20, Eytan Heidingsfeld wrote: >> >>> I retried with DEBUG=xenbus and saw that xenbus_probe_type failed for >>> the device: device/suspend/event-channel (I think because it doesn't have a >>> backend key - it is empty). As this device isn't critical for the usage of >>> netfront I just commented out the error in xenbus_probe_type for one device >>> and now it works fine. >>> >>> Is there any reason failing to probe the type of one device should fail >>> the whole probe of the xenbus? >>> >>> I can formalize a patch the prints a warning with DBG and allows it to >>> continue but I was wondering if there was any downside to that? >>> >> >> Does the attached (untested) patch fix the problem? This patch skips >> probing any device type for which we don't have a driver anyway. >> > > I checked that this patch did not cause a regression, and have pushed it as > > http://git.ipxe.org/ipxe.git/commitdiff/e4461f6 > > Thanks! > > Michael > ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
[ipxe-devel] Problem with ipxe on Xen 4.4
Hello, When trying to use ipxe on Xen 4.4 it was always using the emulated NIC (realtek) and not the netfront driver. I retried with DEBUG=xenbus and saw that xenbus_probe_type failed for the device: device/suspend/event-channel (I think because it doesn't have a backend key - it is empty). As this device isn't critical for the usage of netfront I just commented out the error in xenbus_probe_type for one device and now it works fine. Is there any reason failing to probe the type of one device should fail the whole probe of the xenbus? I can formalize a patch the prints a warning with DBG and allows it to continue but I was wondering if there was any downside to that? Eytan ___ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
