Posts made by Paulman9

@Sebastian-Roth Not saying this isn’t related to the issue I had previously, however, the issues I had caused the image to stall at ipxe initializing devices. Sounds like @holydonut is making it past that to stall at init.xz. This a bootfile issue? @holydonut are you sure you are uefi network booting other machines to fog?

@Sebastian-Roth Sorry, I completely forgot about this. Just updated to latest kernel on my server and tested on 1803, worked perfect. Thanks for the update.

@sebastian-roth I suppose this is what I am looking for then?

Non working machine stalled here

@sebastian-roth Here is the output from a working vm:

I’m no programmer so you’re way over my head here haha Output seemed the same as before on the non-working one

@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.

@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.

@lukebarone Here is the one I built from source that is working for us
https://drive.google.com/file/d/1_HRH87klCVQ46raZDAeB8kwCdto0z8MR/view?usp=sharing

@sudburr Yes, as George said, we are building images on windows 10 (now 1709). We don’t currently have a server running server 2016 so I am unsure if it would behave any differently. I assume if server 2016 is not already affected by the same issue, it will be soon, but this could be helpful to some to know for sure.

@george1421 We are BIOS booting these, I didn’t think secure boot should have a hand in it, but it sure doesn’t work with these switches, and strangely I believe the UEFI image works fine with a gen 2 1709 vm (at least with secure boot off.) We don’t use fog for our UEFI images yet so I’ve only tested it once. Only security related option I see in a gen 1 vm is for key storage drives, and we aren’t using that. Anyway, if there is anything you would like me to test for this, just let me know. Otherwise, it seems we are good to go.

Edit: Rebooted to verify, Secure boot is off on the host I was testing on

After going though the differences one by one, I have narrowed it down to three switches that will cause the hang in hyper-v.
#define DOWNLOAD_PROTO_HTTPS
#define IMAGE_TRUST_CMD
#define CERT_CMD
Comment out those lines from the general.h (I used the files from dev-branch on GitHub, if they differ from master, then that might cause additional issues, didn’t check) and the current build (47849) of ipxe works in hyper-v. Would probably fix older versions too, but I don’t see any reason to downgrade as everything is working so far. Unsure how these are even affecting hyper-v at such an early state, but all I know is mine works with no other changes than that. Hope this helps someone make sense of this issue, or at least get around this if they are affected. Again, thanks for everyone’s help with this.

@sebastian-roth I appreciate your help, and that does answer my question. For the record, though, the problem remains. Building from source using the fog provided (GitHub dev-branch pulled) console.h, general.h, and settings.h gives the same failure in hyper-v. Building from source, and only including ipxescript (not replacing the 3 files above) results in a undionly.kpxe that does work past initializing devices in hyper-v. I’m going through each option now to try to narrow it down as it seems now something in the config is what is tripping up hyper-v.

Edit: Modified the default ipxe general.h file to include param_cmd, and changed nothing else. Completed downloading an image to my vm on hyper-v. Unsure what I broke in the process, as there are a lot of switches I’m missing, but I can confirm this works on my setup.

@george1421 Strangely enough, it seems making an image in standard mode on rom-o-matic, results in a much smaller image than creating in advanced mode (even if you change nothing.) Space disparity aside, creating in standard mode as you did boots on hyper-v, however you cannot configure the fog needed options. Creating in advanced mode (at least using no combination of options I chose, even default) results in failure on hyper-v. Any idea what is different between these two modes?

@george1421 I’m not positive, but I think I’m using the one pulled from Github right now. I assumed this to be the most reliable one as, well, I didn’t make it. I don’t think hyper-v gets far enough to show that

Though, On a working machine, it shows iPXE 1.0.0+ (47849).

@george1421 Sorry to dig this back up, however, I am confused as to what you did differently on the one you built to make it get past this point. I have rebuilt undionly.kpxe several times, from source (instructions used), from rom-o-matic site (using instructions on same page), even grabbed the one off GitHub on dev-branch supposedly updated by Tom less than a week ago. Most of the ones I’ve made work, but fail at the exact same point as before. Is there a step I am missing to get the latest ipxe version? I apologize if this is my ignorance, I just am at a loss to understand what is different about this one. Thanks for your help.

@george1421 Your’s worked past the iPXE initializing devices yet stalled after on “params: command not found” then loops. I tried to rebuild again including params using rom-o-matic site you linked but the one I made freezes again at the same spot(ipxe init) as before, then some warning about using a legacy nic wrapper, but I’ve never done this before and could be missing something simple.

@george1421 Thank you for clarifying for the kernel, I wasn’t sure at what point it was relevant, but tried it anyway. I created a gen 1 vm (legacy.) I actually used a machine I was testing with that I know for sure was working before the 1709 update (same vm, same config,) created another from scratch to ensure nothing went wrong with it and same result. Had another user on another machine try and he gets the same result. We tried a third machine still on 1703 and it works perfectly. There are no error messages, the machine simply gets to “iPxE initializing devices…” and sits there. It loads up 100% usage on one cpu core and sits there. I’ve left the machine for at least 3 days without it progressing.

We are having the same issue on an old beta (1.4.0 I think) 7545. We were looking to upgrade FOG to latest yet according to op this issue persists. It seems to happen on all machines running hyper-v (the host) on windows 10 1709 for us. 1703 works as expected. We have not found a kernel that changed this behavior either. Any hints or a solution would be greatly appreciated.

I tried updating to trunk 4821 and ended up on 6321. I dunno what I’m doing or how the trunk subversions work exactly, but multicast works now. Thanks guys.

Same issue with brand new setup on Debian 8.3, svn 6287. Any ideas? Everything works except multicasting.