I just came across this by accident and wondered if this was ever solved. Reading through it and the related iPXE forum post (link) it seems like this was caused and fixed by Microsoft. So if you have this issue, update and you should be fine.

@Paulman9 Ok, so it’s definitely not the rootcert code causing the hang. Just keep going like this with all the other files. Try adding debug to ipxe/src/crypto/rbg.c next I’d suggest and pxe/src/interface/efi/efi_timer.c is a good candidate for an issue as well!! Just don’t forget to add those to the make ... DEBUG= command too when compiling.

@Paulman9 Great to see you got it working and figured a way to get the pictures. Sorry for the sleep compile issue. I forgot to tell you need to add the unistd header at the top (e.g. line 29) for that to work.

Now the next step is to figure out which startup functions are called and where it hangs. Unfortunately there does not seem to be an easy way to get the function names from the pointers. So you need to add debug code to each of the startup functions by hand - sorry!
Here is a list of all eleven startup functions in iPXE (found running find ipxe/src/ -type f -exec grep "\.startup =" {} /dev/null \;):

Now compile the binary with make ... DEBUG=init,rootcert and try it out. Follow the same schema for all the other startup functions. The first parameter is just a color code, can be any hex number really. So you can use 0x1 for the first, 0x2 for the second if you like it colorful.

Note that you have the calling startup function 0x... printout first and then your newly added output when it enters the particular startup routine. So I suspect it to halt after one of your newly added printouts. From there you can add more printouts throughout that function and those being called. Let me know what you find or if you get stuck at some point.

PS: I’ve done those debugging steps a couple of times when trying to find out why iPXE would hang on some particular hardware. Usually I’d just compile the binary and give it to users for testing. So this is the first time I hand over the knowledge on how to debug iPXE init code and I am grateful @Paulman9 is keen to follow this. @Wayne-Workman mind adding that to the wiki as well?

@sebastian-roth Finally got it to work. Unsure if something is wrong on my side but I had to delete the sleep line to get it to compile properly. As a result, my images are dim since I had to pause the VMs to get screenshots.
Working:
No-worky:

@lukebarone Found on the wiki. Only difference here is open general.h after downloading and change #define to #undefine for these lines:
#define DOWNLOAD_PROTO_HTTPS
#define IMAGE_TRUST_CMD
#define CERT_CMD
These lines aren’t consecutive in the file so you’ll have to look for each.

@Paulman9 Thanks for letting me know! Good to hear you already posted this in the iPXE forums. Too bad that it didn’t get more attention but I guess there are more important issues to fix from their point of view.

If you are keen to get into debugging this I can give you a bit of advice. I am sure you’d have noticed the debug output if it were there. Just to give you an idea of how iPXE debug output looks like - it’s in color!!!

To find startup issues I usually start by adding my own debug output code. For that edit src/core/init.c, find function startup (around line 65) and modify to make it read like this:

Recompile with make ... DEBUG=init and run that binary first on a working VM - the sleep will give you enough time to take a picture of the function pointers printed on the console. Then run the same binary on a non-working VM and take a picture too. Please post both pictures and I am sure I can help you find out which initialization code is hanging.

Not saying that we’ll definitely find a fix but possibly we can come up with some more information for the iPXE devs to work with.

@sebastian-roth Sorry I must have missed your last comment originally. Compiling with any one of those three lines (even just the https line) causes it to fail. I didn’t see any difference using the debug command to compile it. Honestly, not sure what I should be looking for with that though.

Also, I did submit this to the ipxe forums, who responded that this was a Microsoft issue. While I did also submit this in the feedback app in windows 10, I’m not holding my breath for Microsoft to do anything about this.

Is there any update on this? Or are we waiting on the iPXE crew to fix it?

Thanks for bringing that back up on screen. If I remember correctly I had only reported the rom-o-matic issue so far.

About the actual HyperV iPXE crypto code issue - I don’t think this has been reported anywhere yet. @Paulman9 I think you know the most about which options exactly play a role here. Did you get to compile a debug enabled binary and look into the code as I suggested (make ... DEBUG=https)?

@lukebarone@Paulman9 I have the same issue with Hyper V and Windows 10 1709. What is the process to get the updated undionly.kpxe downloaded and installed on the Fog server running Ubuntu from the google drive link?