@JGeear I don’t know if anything changed, just I wonder if someone was making an edit in the UI and accidentally changed the password in the UI. I’m having you start with where I know the system is getting the information. Make sure the username/password matches what is on that nodes /opt/fog/.fogsettings file. If they are the same, then I’d ask if you can use that same information and an FTP client to ensure at least connection is there. Then we can try to troubleshoot further.

I think this is an issue envolving this kind of nic hardware (Intel I226-V). I opened an issue (18125) where I have some appliances for pfsense, they have got four NICs with this kind of hardware, and we are not getting successfull to deploy an image because it’s not processing authentication, even typíng correct user and password.

Yes, you are right!
I can confirm that it is still functional.
Install clean Windows 11 + drivers + all the updates -> configure windows as you like it -> sysprep -> shutdown -> Image -> Deploy.

Although, I have searched the answer for the main question, to sysprep or not, for years!
What I mean, is that if you sysprep, some of the Windows settings and configuration will be wiped out during the sysprep, so you cannot configure image 100% ready and need some manual steps after the cloned pc (deployed) boots up.
Of course those manual configurations can be automated (by a script or some other way), but still, it would be nice that image can be setup without sysprepping if it is not needed anymore in Win10/11.

I have tested hundreds of PC-s in domain environment without sysprepping - they work flawlessly, no issues with Domain, WSUS or other things, but I am little bit worried, that if some issues arise, e.g some weird errors then I must reinstall all the deployed pc-s with sysprepped images…

Can somebody confirm?

Yes, I understand, that without sysprep, all the PC-s deployed from the same image will be using same SID, but is it bad somehow?
Can someone confirm that for Intune it is also OK?
Domain doesn’t care, WSUS either, but what else might break?

@Tom-Elliott @Tom-Elliott it’s not authentication issue. We don’t have problem when deploying images to other hosts, like PCs and minipcs with just one NiC. But over these Appliances with 4 Nics we got stuck in the authenticon screen even putting correct username and password. Look, we are trying to disable 3 nics in Bios but we can’t . We excluded them to Boot Order and left just the first, but even so, the error persists.1000110829.jpg - I found the issue 16746 about this problem, but it’s happening to us!

@Tom-Elliott

So I tested current release, and it seems you were able to fix it. It registers new hosts correctly now. However, you still have errors in sed used to enable USB_HCD_USBIO in iPXE compilation to fix non-working keyboard mentioned here: https://forums.fogproject.org/topic/17870/fog-ipxe-menu-no-input/

You have TAB in your sed, but it doesn’t work correctly. So lines number 80-82:

sed -i 's+//#define USB_HCD_USBIO+#define USB_HCD_USBIO+g' config/usb.h sed -i 's+//#undef USB_KEYBOARD+#define USB_KEYBOARD+g' config/usb.h sed -i 's+//#undef USB_EFI+#undef USB_EFI+g' config/usb.h

should be:

sed -i 's+//#define USB_HCD_USBIO+#define USB_HCD_USBIO+g' config/usb.h sed -i 's+#undef USB_KEYBOARD+#define USB_KEYBOARD+g' config/usb.h sed -i 's+#define USB_EFI+#undef USB_EFI+g' config/usb.h

TAB after define and undef makes difference and current iPXE release have different syntax. They have:

#define USB_EFI //#define USB_HCD_USBIO #undef USB_KEYBOARD

So we need to uncomment define USB_HCD_USBIO, switch undef USB_KEYBOARD to define and switch define USB_EFI to undef.

@astrugatch we have firewalld but you can make the adjustments… some ports have been changed from the initial setup due to network restrictions.

- name: FOG_Services short: FOG Server network rules description: >- For FOG Server to handle boot, image and various tasks on workstations sources: - SUBNET_IPS allow_icmp: - echo-request - echo-reply services: - ftp - http - mountd - nfs - rpc-bind - tftp ports: - { port: 20048, proto: tcp } # nfs - { port: 20048, proto: udp } # nfs - { port: "35350-36350", proto: udp } # tftp - { port: "49512-65532", proto: udp } # multicast

@pcnr I noticed this issue so many years a go. It may be issues refering undionly.kpxe file. You can find some solutions from this forum about this. In my case I did following:

Make a backup of /tftpboot/undionly.kpxe to undionly.kxpe.bak; Copied /tftpboot/undionly.kkpxe to undionly.kpxe.

So at next time, this stuck problem was solved.

I have solved my issue by changing the Host EFI Exit type:

REFIND_EFI for Windows images
SANBOOT for Ubuntu/Debian images

Xavier

Hello,
In my attempt to switch to HTTPS for the Fog server, I encountered the same issue of the keyboard being disabled in the iPXE menu. After several unsuccessful tests, I consulted Copilot. After reviewing all the scripts and .h files, it indicated that the issue stemmed from the size of the iPXE.efi file I was using. It was too large due to all the necessary modules for HTTPS, causing iPXE to deactivate the USB keyboard functionality during loading. Consequently, I opted for snponly.efi instead, and now the keyboard works perfectly.

I modified the script buildipxe.sh :

sed -i ‘s+#define USB_HCD_USBIO+//#define USB_HCD_USBIO+g’ config/usb.h
sed -i ‘s+#define USB_KEYBOARD+//#define USB_KEYBOARD+g’ config/usb.h
sed -i ‘s+//#define USB_EFI+#define USB_EFI+g’ config/usb.h

May I propose a change in the console.h : Could you set the keyboard map to “dynamic” instead of “us” ? That way we can easily set our language in default.ipxe

//#define KEYBOARD_MAP us // Default US keyboard map
#define KEYBOARD_MAP dynamic // Runtime selectable keyboard map

@Greg-Plamondon I’m going to try delving into this but I’ve been very busy with other things and just haven’t gotten around.

I do appreciate the patience and assistance.

The changes you were doing that fixed the problem, please implement them again and you should be back to functional

Once that is done, do you mind doing a diff between that file and the relevant file in the git repository side:

Files I think you changed were under: <path>/<to>/<installer>/packages/service/<servicename>/<servicefile>

I’m not seeing any issues on my test systems.

not really sure why it isn’t working either.

I believe you were editing the files in /opt/fog/service/<servicename>/<servicefile>

So you would do:

diff -u <path>/<to>/<installer>/packages/service/<servicename>/<servicefile> /opt/fog/service/<servicename>/<servicefile>

Okay - So what killled this installation was the fact a 1.5.9 csv load was imported into my 1.5.10.1698 FOG - this killed a bunch of features and I eded up having to reinstall.

@Tom-Elliott apologies for the delay but here is what I see in the error log when this occurs:

For context the 'Client IP Detected as <IP ADDRESS> is a small modification to the Subnet Groups plugin which I log the IP of the client checking in, this is working as intended.

The ‘PHP Fatal error’ is what I only see when we have the chain loading error.

I can confirm this is working on: 1.5.10.1734 as I have rolled back any sites to this version and have seen no issues.

[Mon Feb 23 15:07:55.208763 2026] [proxy_fcgi:error] [pid 501804] [client 10.9.209.159:33595] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496' [Mon Feb 23 15:08:27.815241 2026] [proxy_fcgi:error] [pid 501806] [client 10.9.209.159:1025] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496' [Mon Feb 23 15:09:00.456158 2026] [proxy_fcgi:error] [pid 501802] [client 10.9.209.159:1555] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496' [Mon Feb 23 15:09:33.088040 2026] [proxy_fcgi:error] [pid 501802] [client 10.9.209.159:6935] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496' [Mon Feb 23 15:10:05.672334 2026] [proxy_fcgi:error] [pid 501803] [client 10.9.209.159:16900] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496' [Mon Feb 23 15:10:38.336356 2026] [proxy_fcgi:error] [pid 571479] [client 10.9.209.159:43335] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496' [Mon Feb 23 15:11:10.976801 2026] [proxy_fcgi:error] [pid 501803] [client 10.9.209.159:36391] AH01071: Got error 'PHP message: SubnetGroup Hook: Client IP Detected as 10.9.209.159; PHP message: PHP Fatal error: Uncaught ValueError: min(): Argument #1 ($value) must contain at least one element in /var/www/fog/lib/fog/image.class.php:496\nStack trace:\n#0 /var/www/fog/lib/fog/image.class.php(496): min()\n#1 /var/www/fog/lib/fog/image.class.php(389): Image->getPrimaryGroup()\n#2 /var/www/fog/lib/fog/bootmenu.class.php(1472): Image->getStorageGroup()\n#3 /var/www/fog/lib/fog/bootmenu.class.php(469): BootMenu->getTasking()\n#4 /var/www/fog/service/ipxe/boot.php(52): BootMenu->__construct()\n#5 {main}\n thrown in /var/www/fog/lib/fog/image.class.php on line 496'```

@rodluz 0f341e2a-1996-4ec7-91ac-4269fe20a31c-image.png

I’ve updated the iPXE on my proxmox server, still hangs on this message. Other VMs work fine, as they did with the older iPXE version.

@dimoura

Hello!

Do you have Secure Boot enabled?

I worked with this Dell Machine about 6 months ago and don’t have it with me now.

So here it goes.

Ensure secure boot is disabled. You will need to re-enable it for Windows 11 to work., You need to ensure your SATA mode setting is set to “AHCI”. - If you have “RAID” selected (which was the default from the Dell Machines I tried) it will not work. If you have legacy IPv4 PXE booting that would work best, newer computers no longer have a legacy PXE boot, but use UFEI IPv4 PXE booting. Check if that is enabled.

Otherwise, check what bzImage files you are using. The bzImage files have the linux kernel drivers which I think I used the latest stable ones I could find. These are placed in /var./www/html/fog/service/ipxe

There are 4 files in there which need to be there
bzImage
bzImage32
init.zx
init_32.zx

Or others depending on what CPU architecture your machines use. These are available on the following URL
https://github.com/FOGProject/fos/releases

I found that some work better than others as the FOG project is maintaining their FOS releases and adding computers. It is possible that one you are using simply does not have the drivers for the PC you are using. I would back up these files before updating these to ensure your older machines can PXE when updating your FOS (fog OS).

Matt

I have just discovered that somehow all the MACs are changing sometime after the final successful DHCP lease.
My DHCP server is set to only answer to specific MACs, so if I add in the “new” one, it works.
No idea how this is happening, I’ve never seen MACs just suddenly change like this.
It sucks that now I have another MAC per server to deal with, but at least it’s working.

I’m also interested in knowing if a solution exists.

@rodluz yes, directly from 1.5.10.1754 to 1.5.10.1763 when I saw the prompt in the FOG gui that I’m not using the latest version - it was up to date before.

in 1.5.10.1754 recapture didn’t added up, just updated the image size to the latest one.