@ahaeder A final setting - you have to set Bios exit type = GRUB (not the default SANBOOT) or the boot hangs at ‘Booting from SAN device’.

@ahaeder This did work, by the way, so I have a successful way to use FOG to image and deploy Wyse 5060 thin clients. They need to be in Legacy mode in the bios, boot to undionly.kpxe, the Win10 image you install has to be on a flash drive formatted with an MBR (not GPT partition), and you need to make sure there are no GPT partitions on the hard drive before you install Windows. Then everything works.

I want to close the loop on this in case other folks run into this. Although the Wyse 5060 thin client supports UEFI mode, it looks like it’s buggy enough that none of the pxe files included with Fog will boot it. Legacy mode works however, so that’s what I’m going with. I actually did a test on each file in /tftpboot and here are the results:

So I’m going with undionly.kpxe.

The other issue I’ve had is that once I did a Win 10 IoT install on a legacy-booted 5060, the fog capture process would fail, saying I needed to run fixparts. In the ‘capture - debug’ shell, the fixparts command wasn’t available, and I ended up accidentally nuking my Win10 boot partition. Oh well.

I’m retrying this again. I have a flash drive that’s MBR (not GPT) formatted with the Win10 IOT installer. I made sure the 5060 is in legacy mode, and when I started the install I hit Shift-F10 to drop to a cmd prompt and used these commands to ensure there were no linger gpt partitions on this disk:

diskpart
list disk
select disk 0
clean
convert mbr
exit

and I went ahead with the install. When windows updates finish, I’m going to attempt to capture the image and see if it works.

For anyone else struggling with this, I finally figured it out. FYI this is not a fog issue, it’s a Windows secureboot UEFI issue.

Once I image a machine, I need to make sure secure boot is disabled, boot windows, and run these commands from an elevated command prompt:

mountvol s: /s
del s:*.* /f /s /q
bcdboot %systemroot% /s S:

That will rebuild the EFI partition files.

I did this, rebooted to the bios, re-enabled secureboot, and Windows successfully booted. Hooray.

My only issue now is that I can’t do unattended reimaging with secureboot enabled. If I push my golden image back to this system with secureboot enabled, Windows will fail to boot again until I make it rebuild the EFI partition files. What’s so weird to me is that I don’t have this problem on Wyse 5070 thin clients - I can leave secureboot enabled all day, reimage a system, and Windows boots just fine. But these Dell Optiplex 3000s sure don’t like it.

Stock ipxe.efi from boot.ipxe.org did the same thing. I’m going to chalk this up to bad firmware on the 5060 and just use legacy mode. Thanks for the feedback.

FOGProject version 1.6.0-beta.5136 running on Ubuntu 26.04.1 LTS and php 8.5.4.

I am working with Dell Optiplex 3000 thin clients. I have successfully done the following with secureboot disabled (UEFI enabled):

• Manually created a golden image of Windows 10 IoT, ran sysprep
• Booted to FOG PXE and done a complete inventory
• Captured the hard drive image to my fog server
• Deployed the image to a different Optiplex 3000
• Successfully booted that 2nd system. Even joined my windows domain, after changing the hostname

Where I run into problems is with secureboot. I successfully followed the instructions to get MOK.der accepted by the clients (did it manually from the pxe boot menu), so now I can enabled secureboot in the bios and the fog menu options work (inventory, debug, deploy image). However, when I attempt to boot the imaged WIndows 10 IoT after secureboot is enabled, I get an error.

If I let the system boot normally from pxe, I get the fog menu, which select ‘boot from hard drive’ after 3 seconds. It tries to SAN boot the partitions on the drive, and each one says “Verification failed: Security Policy Violation”. If I attempt to boot directly to the hard drive, the Dell bios immediately goes into testing mode because it can’t find a partition it can boot from.

I know this is 100% a secureboot problem because as soon as I disable secureboot in the bios Windows boots up and everything is happy.
On the original Optiplex that I created the golden image on (I installed Win10 IoT from a usb flash drive) I am able to perform the entire install while secureboot is enabled. So I know that secureboot can work with Windows on these thin clients.

But for some reason I can’t get it to work after fog deploys a good image to one.

What am I not understanding about the secureboot process? I even went into the bios, select ‘custom keys’ and reset all the keys to the defaults. I also tried running “bcdboot C:\Windows /s S: /f UEFI” post-image deploy, with secureboot disabled, trying to get windows to recreate the uefi partition. Turned secureboot back on, still didn’t work.

I’m running out of things to troubleshoot here, and I’m hoping some folks with more experience in secureboot have some ideas for me. Thank you!

@Tom-Elliott Thank you so much for the reply. The image I’m trying to boot was created on a UEFI system, so of course it’s failing, why did I not think of that. I’m going to do a fresh install under legacy mode on this 5090 (I’m using Windows 10 IoT) and create a new golden image, rather than pushing a 5070 image and updating the drivers. I’ll report back. Thanks again

@ahaeder I’m still fighting this 5060 but I’ve made progress. When the bios is in Legacy mode (not UEFI) I got it to boot undionly.kkpxe and get to the fog pxe menu. I was even able to deploy an image to it successfully. The problem now is that although the pxe boot menu shows up, it can’t transition from there to booting off the hard drive. The default SANBOOT hangs at:

Booting from SAN device 0x00
Boot from SAN device 0x00 failed: Input/output error (https://ipxe.org/1d852039)
Booting from SAN device 0x80

The other options I have in the fog server for this system under Host BIOS exit type are:

SANBOOT
GRUB
GRUB_FIRST_HDD
GRUB_FIRST_CDROM
GRUB_FIRST_FOUND_WINDOWS
REFIND_EFI
EXIT

None of them work. They either immediately reboot, hang or just leave me at a grub prompt.

I can boot directly off the newly imaged hard drive, but I can’t transition from pxe boot menu -> hard drive boot.

FOG version 1.6.0-beta.5136, https enabled
PXE works great with Wyse 5070 thin clients and Dell Optiplex 3000 thin clients.

Tried my first 5060 today.

Wyse 5060, BIOS 1.0J (2018-11-06), UEFI boot, Secure Boot disabled. PXE acquires DHCP, downloads EFI binary and autoexec.ipxe. Even an autoexec.ipxe containing only:

#!ipxe
echo HELLO
sleep 30

causes an immediate reboot. No requests for default.ipxe, boot.php, bzImage, or init.xz ever reach the FOG server. Same FOG server works perfectly with Wyse 5070 and Dell OptiPlex systems.

I’ve tried handing out all the different *.efi devices in my /tftpboot dir, all do the same thing. I know this is a really old system, it’s just weird that it’s just rebooting so early in the ipxe process.

Has anyone seen this before? THanks

FYI for anyone else running into this issue - I believe the problem was that I didn’t erase the /tftpboot images when I switched from http to https. I’m not really sure why that would matter, but when I did that, then re-ran the server reinstall and selected https, the images got but back in /tftpboot and my hosts didn’t see the mac error anymore.

My title is wrong, should have been “no viable macs to use after switching to https”

Running Version 1.6.0-beta.5136 on ubuntu 26.04.1 LTS (apache 2.4.66-2 and php8.5-fpm).

I had everything working fine in http. I then reran the server installer to switch to https. As soon as I did that, when I would try to register (either quick or full) a new host from the pxe menu, I’d get the error “no viable macs to use”. This happened on 2 different architectures, each system only having a single ethernet port on the motherboard.

PXE boot was still happening over http, but I had (successfully) switched the server over to https. I nuked the .fogsettings file, re-ran the install script, selected http only and now everything works again.

I’m running FOG 1.6.0-beta.5115 on Ubuntu 26.04.1 with apache2.4.66-2 and php8.5.4-0 (mod_php, not php-fpm).

I’m just getting this setup in my environment, and I’ve successfully imaged and deployed a few thin clients (Dell Optiplex 3000 and Wyze 5070) with Windows 10 IoT images. I have a powershell script that runs after imaging that completed the setup in my environment. Specifically, this script changes the hostname and joins my AD. All of this works fine.

The problem I have is that the hostname in FOG doesn’t update when I update the hostname on windows. The Windows hostname baked into the Wyze 5070 image is ‘wyze1-5070’. That hostname gets registered with Fog after the initial imaging, because the image has fogclient on it. I then run the powershell script which changes the name and reboots, but fog still refers to it as wyze1-5070.

Is there any automatic way to have the fog hostname updated to match the windows hostname? I have the ‘Hostname Changer’ service setting enabled by default, but I think that’s for fog pushing hostname changes to the client, not the other way around.

Thank you