Fog menus painfully slow if host computer is running Windows 11
-
At first, I thought it was my Fog server, but I spun up my old one, updated everything, and ran into the same problem. So I built a new Ubuntu VM, added Webmin for ISC-DHCP, and added a clean version of Fog, but still the same.
If I PXE into the server with any other OS - Win10, Linux, no OS (blank drive) everything responds perfectly, however, if the host connecting via PXE has Win11 on it, the whole system bogs down to where it is almost impossible to use. To test further, I pulled out an older laptop with Windows 10 (L13 Yoga from two years ago), it loaded fine and FOG was behaving normally, pushed Windows 11 and then reconnected it to FOG, and the system ground to a halt. I unboxed a brand-new laptop (also Lenovo L13 Yoga) that came from the factory with Windows 11 and the system slowed down to a crawl. I added Windows 10 to the brand-new machine and FOG behaved normally again.
Does FOG simply not play well with Windows 11? Or am I missing something stupid? Three FOG servers that work with every machine that isn’t Windows 11, but fail with any machine that is.
-
@EuroEnglish I’m finding it hard to believe that there is a connection of having win11 on the computer that is causing this behavior. When the fog menus are being displayed, we are running iPXE boot loader. This in a way is an OS by itself. The OS on the target computer is not even known about at this point in the booting process.
The only thing I can think is that the format or disk structure is now allowing iPXE to fully initialize correctly.
Could you make this test for us? If you have 2 computers of the same model (make sure that bit locker is disabled on both systems) and secure boot is disabled.). One with win11 and one with win10. Verify they both behave the same way as you mentioned above.
On the win11 computer remove the hard drive/nvme drive. Boot into the FOG iPXE menu. Does it still have the slow speed?
Move the hard drive from the win10 computer to the win11 computer. Does the system act slow or normal? -
@EuroEnglish I have not experienced this issue at all as I’ve upgraded machines to windows 11. I even have a few L13 yogas, and they aren’t doing this.
What version of Fog are you running?
What version of ipxe your fog is running? (The version displays when booting to pxe like
iPxe 1.2.1
or something like that)Also, are you saying it’s slow in the actual fog pxe menu or getting into the pxe menu? Sounds like that actual menu yeah? Like you’ve booted to fog via pxe and see the menu, when trying to select an option on a registered host it freezes up?
What kind of adapter are you using to get the L13 to boot to pxe? USB-C? The special lenovo proprietary adapter?
Do you have mac address pass-thru enabled in the bios?
What version of the FOS kernel/init are you using. You can find this in the Fog GUI under configuration I believe, if you have a recent enough version.
-
@JJ-Fullmer We are running the FOG alpha-branch version 1.5.10.29 (it was the most recent at the time of installation), I upgraded to this as we were having the same problem on 1.5.9 and 1.5.10 regular. It is the Fog menu that grinds to a halt when deploying an image, it takes 3 to 4 minutes to switch to deploy and then enter a username/password, after that, the image pushes normally. We don’t register hosts, we simply PXE boot and deploy whichever image we need.
The L13s use USB-C Ethernet adapters, the same ones are used no matter what machine, current OS, or deployed OS choice. MAC address pass-thru is not enabled. We have the BIOS preconfigured by Lenovo, including all security passwords and boot options (The only thing they missed was disabling secure boot, so we manually turn that off)
FOG kernel is DefaultMeember FOG Version 1.5.10.29, not sure what Initrd version we are using, but it wasn’t changed from stock installation on any of the FOG servers. iPXE is 1.21.1+
-
@george1421 I will take care of that, but it might be tomorrow. We just handed out 150 laptops a couple of days ago, but due to the FOG issues we were forced to hand the machines out without all the software and modifications required, now we are busy trying to make GPO and Intune changes to make the modifications we couldn’t push as an image. As soon as we are caught up I will disassemble one of the laptops to remove the drive and test again.
Like I said though, I did take a perfectly good Windows 10 machine, FOG menus were responding well, pushed Windows 11 to it, then put it back onto the FOG server - The menus were unusable. The only change was the OS, BIOS was untouched. Bitlocker wasn’t on before and isn’t on in the image on the server. We created a new image for the new FOG server and are seeing the same results.
I am perplexed as you are, how FOG menus are being manipulated by the OS I have no idea, but I will run the requested tests and let you know. Removing the drive will be an interesting test to see what might be going on.
-
@EuroEnglish Sorry I’ve been away on vacation on and off the last week.
I will try to recreate this on my setup but I am running Fog 1.6 (you can try it out too by checking out the ‘working-1.6’ branch instead of the dev branch).
And I am using a newer kernel and init. Once of the features of the newest kernel and init is support mac address pass-thru properly, but if you’re not actually registering the hosts, this won’t make much difference, it could still give you some benefit though.We have a spare L13 or L390 laptop and such so I will test having it have win 11 loaded and being unregistered and see what happens.
-
@EuroEnglish I haven’t been able to recreate the issue. I would suggest maybe trying an update to the kernel and init, if you’re on the latest dev-branch version there should be a July 5th dated bzImage and Init available from the fog configuration kernel update and init update menus.
The only other things I can think of might be your Windows 11 partition layout being non standard or something? It should all be booted into RAM at that point though, so that doesn’t make much sense, but it’s possible that the efi partition is too small or something, that’s just a hairbrained theory though. Other thing could be a custom background image? Maybe it stops liking the size of it?Hopefully trying the newer kernel just solves the problem though.