Hyper-V Gen 2

[mastacontrola]

(2017-05-26 10:59)mcb30 Wrote:  

(2017-05-25 17:40)mastacontrola Wrote:  We've determined the cause was introduced in:
https://github.com/ipxe/ipxe/commit/a0f6...d9663f5269

And made more difficult to patch with:
https://github.com/ipxe/ipxe/commit/276d...d5a93b20d6

By reverting the changes in these two commits, Gen 2 Hyper-V systems are able to boot.

I don't know if it's a big problem to correct for, or if simply reverting will be the best bet.

Those patches cannot simply be reverted. hv_map_hypercall() and hv_map_synic() are now used on the hv_unquiesce() path, and we rely on hv_map_hypercall() accepting a situation in which the guest OS ID MSR is already non-zero in order to recover from having our network connection dropped in the middle of an iSCSI boot: http://git.ipxe.org/ipxe.git/commitdiff/b91cc98.

How are you starting iPXE within your Gen 2 VM?

Michael

All we're doing is our normal boot processes. It works for Gen 1 Hyper-V (as far as I know) for UEFI/EFI booting on. We build the boot system fairly dynamically via a php script.

A task boot script would like like:

Code:

#!ipxe
set fog-ip 10.0.7.1
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 web=10.0.7.1/fog/ consoleblank=0 rootfstype=ext4 sshpasswd=somepasswordhere isdebug=yes ismajordebug=1 storage=10.0.7.1:/images/ storageip=10.0.7.1 mac=00:0c:29:24:4c:3d ftp=10.2.1.5 storage=10.2.1.5:/images/ storageip=10.2.1.5 osid=1 irqpoll hostname=winxptest chkdsk=0 img=winxpleg2 imgType=n imgPartitionType=all imgid=6 imgFormat=0 PIGZ_COMP=-6 adon=1 addomain="mastacontrola" adou="" aduser="HAHAHANOPE" adpass="somestringhere" hostearly=1 type=down isdebug=yes ismajordebug=1
imgfetch init_32.xz
boot

This will be the same for either UEFI/EFI or Legacy style boot. With the current ipxe binaries (as is) this will load iPXE just fine, but nothing actually lets the VM boot. Reverting these changes, while I understand there can be consequences, allows the VM to boot again. I think it's specifically related to the lost return -EBUSY, and the only reason I had to make the other mods was so the return wouldn't cause a problem during build time.