@jatosaj I think I would approach this by having FOG as your PXE boot source. This will use iPXE as your boot loader. iPXE is a very powerful boot loader as compare to syslinux (pelinux). Both are capable of doing what you want, just you’ll have an easier time managing this setup from FOG.

The idea is to pxe boot into the FOG menu, then have FOG chain (load) the aikenwb environment.

Understand I’m just spitballing this configuration. But within the fog UI under FOG Configuration there is an iPXE menu manager. You will create a new iPXE menu using these settings.

Menu Item: os.chainaikenwb
Description: Boot AikenWorkbench
Parameters:
iseq ${platform} pcbios && set bootfname “bios/pxelinux.0” ||
iseq ${platform} efi && set bootfname “grub/bootx64.efi” ||
chain -ar tftp://192.168.2.1/${bootfname}
boot || goto MENU
Menu Show with: All Hosts

If AikenWorkbench requires the dhcp settings to contain the exact values we will need to get a bit more creative with the FOG menu.
(this one I have about 60% confidence I created the menu correctly)

Menu Item: os.chainaikenwb
Description: Boot AikenWorkbench
Parameters:
set next-server 192.168.2.1

iseq ${platform} efi && goto is_awb_efi || goto is_awb_bios

:is_awb_efi
set bootfile “grub/bootx64.efi”
goto awb_boot

:is_awb_bios
set bootfile “bios/pxelinux.0”

:awb_boot
set filename ${bootfile}
set net0.dhcp/filename ${bootfile}
set proxydhcp/filename ${bootfile}
chain -ar tftp://${next-server }/${bootfile}
boot || goto MENU
Menu Show with: All Hosts

Even if I missed on the menu, using FOG and iPXE is the easiest answer to get what you need. You CAN do it with FOG. For full disclosure you can also create a menu in syslinux to chain load into iPXE too. So if you have a way to create customer menues in AikenWB you can pxe boot into AikenWB and then chain to fog, but you’ll lose out in some of the boot features of FOG.

@diogo-seabra As for the picture, I think we need to clearly define your network.

dnsmasq works by using broadcast messages. So that means dnsmasq will only work on the local subnet. If your pxe booting computers are on a different subnet then you will need to add the fog server’s IP address to the list in the dhcp relay service on your router.

Also if you have dhcp snooping enabled on your network switches, that may also cause dnsmasq to not respond properly.

@diogo-seabra Just to be clear you WILL need to have this as the last line in your configuration for dnsmasq.

dhcp-range=<fog_server_IP>,proxy

Where you replace <fog_server_IP> with the IP address of your fog server.

@diogo-seabra said in Dnsmasq on your FOG server:

At DHCP main not needed configure the option 66 and 67, right?

Correct. We use dnsmasq for those dhcp servers that setting dhcp options 66 and 67 are impossible. Such as when an external company manages your dhcp infrastructure.

@diogo-seabra said in Dnsmasq on your FOG server:

dhcp-range=192.168.10.0,proxy,255.255.255.0
dhcp-range=172.30.20.0,proxy,255.255.255.0

These should not be necessary. In this configuration dnsmasq is only in proxy-dhcp mode. It will not hand out IP addresses, that is the responsibility of your main dhcp server. DNSMASQ in this mode will only send out a proxy dhcp OFFER packet telling the target computer after it gets its IP address contact the proxy dhcp server for additional information.

As for your main dhcp server, its not necessary to set dhcp option 66, because the proxy dhcp server (dnsmasq) will override that setting.

PXE-E16 no valid offer received

This means the pxe booting client didn’t either receive an IP address or the DHCP Discovery from the target computer didn’t make it to the dnsmasq server because it didn’t respond.

So I have to ask you if you have a microsoft dhcp server, why do you feel the need to run dnsmasq? (this is a specific and intentional question). Microsoft dhcp server can do everything (almost) that a dnsmasq server can do.

@BrightPipe said in FOG not saving images in the directory:

EDIT---- Running the installer again seems to have fixed the issue. Thanks.

Good deal because that was going to me my next request. I’m glad you have it sorted out.

@BrightPipe When FOS Linux captures an image it will do that as root on FOS Linux. The issue we need to see is not specifically the owner permission but the group permission. From command line if you change into /images/dev and then issues ls -la * what is the group ownership of that 408… directory.

What actually happens here is FOS Linux connects to the FOG server over ftp as the fogproject user that is also a member of the fogproject group. That file we need to move is owned by root, but hopefully the group is fogproject so the fogproject user can move the file.

One way to test this permission issue is to (from the fog server cli) connect to the fog server using ftp. The user ID is fogproject and the password for fogproject is found in a hidden file /opt/fog/.fogsettings Use that to log into the fog server over ftp then issue the following commands.

cd /images/dev
mv 408d5caa1a89 /images

If you have the proper permissions on that directory then the directory should move to /images.

If the permissions are messed up (as in you mapped the /images directory over to a new disk to add more space) just rerun the fog installer, that will fix the permissions on the /image and /image/dev directory.

@cookc I can’t speak specifically to Win11 deployment since I’ve left that space, but I’ve seen reports that the setupcomplete.cmd file doesn’t run in Win11 if you are using OEM media. VLK media appears to still run this file, but not OEM. I think that is regardless of the actual key you are using. Its the media (DVD Image) that seems to be causing this issue. But again I need to clarify that I don’t deploy windows products now so I have no first hand experience.

You maybe able to get around this by using the autoadmin login and the first run commands in the unattend.xml file.

I had to explain the process for another reason here: https://forums.fogproject.org/post/157075

@mchristo said in Problem PCX Boot HP 17x104fg:

As far as i investigated, the lapto has a NIC of the Realtek+RTL8102/8103/8136 Family.

Just for clarification, when you see the FOG iPXE menu then the pxe booting is done and iPXE has taken over control of your PC. When you select a FOG iPXE menu item, iPXE transfer control over to FOS Linux (bzImage+init.xz). So your problem is within FOS Linux.

This is a pretty old 10/100 nic, so I would think FOS Linux would know about it. I’ve never hear that family of nic’s before so I can’t be for sure that linux supports it.

If this computer has windows on it go into the device manager, and select that nic. Get the hardware ID of that nic, it will be in the form of vend_id=8086&device_id=1cfd that was a totally made up number. I need the 2 groups of hex codes to match the linux driver ID.

I can’t seem to find a HP 17-x104fg but I can find a 17-x104ng laptop with a 7th gen intel chip. I’m suspecting the realtek nic family you mentioned is not installed in this laptop. There is no reason to install a 10/100 nic along side a 7th gen intel processor. Lets get the nic hardware ID so we can properly ID that nic.

@RAThomas said in UEFI is not booting with Windows DHCP:

The solution for my case was to add this to the client port configuration on my Cisco switch:

Yep, if you are not using port-fast, fast-ftp, mstp, or rstp (or whatever your switch mfg calls it) standard spanning tree takes 27 seconds to start forwarding packets. This timer restarts every time the network link winks, like as the PC starts, iPXE starts up, and then FOS linux starts. FOS linux boots so fast (< 16 seconds), its already given up trying to get an IP address before the ports starts to forward traffic.

@BrightPipe OK what is happening here is, the FOS engine has uploaded the image to /images/dev/<mac_address> using NFS. Then the FOS engine connects to the fog server using FTP as the fogproject user. Then it issues a mv (move) command from /images/dev/<mac_address> to /images/<image_name> directory.

So you are saying there is a directory name in /images that matches <image_name> but the files stay in /images/dev directory? If yes then it appears that the fogproject user doesn’t have rights to ‘move’ the files out of /images/dev , but it does have rights to create the directory in /images.

That gives me a clue that the fogproject user doesn’t have permissions to /images/dev/<mac_address> directory.

@diogo-seabra said in Inject drivers via Fog:

To use the unattend.xml can we follow this steps

This is kind of an open ended question so I’m not sure how to answer within context.

The fog.updateunattend script is intended to update the unattend.xml script at deployment time, like system name, OU to bind to, etc.

If you want to use the unattend.xml script to “do things” post deployment, that is not connected to the fog.updateattend script.

For reference here is my windows 7 unattend.xml (I know, but the file really hasn’t changed much between win7 and win11.
https://forums.fogproject.org/post/112435

The interesting sections of the file are this:

            <AutoLogon>
                <Password>
                    <Value>**REMOVED BY ME**</Value>
                    <PlainText>false</PlainText>
                </Password>
                <Enabled>true</Enabled>
                <Username>**REMOVED BY ME**</Username>
                <Domain>**REMOVED BY ME**</Domain>
                <LogonCount>1</LogonCount>
            </AutoLogon>

This sets it up for the administrator account to auto login once. Doing this allows the next important section to run.

            <FirstLogonCommands>
                <SynchronousCommand wcm:action="add">
                    <Description>Move to OU</Description>
                    <Order>1</Order>
                    <CommandLine>cscript.exe /B c:\windows\buildscripts\SetOUTo.vbs "some_new_ou"</CommandLine>
                    <RequiresUserInput>false</RequiresUserInput>
                </SynchronousCommand>
                <SynchronousCommand wcm:action="add">
                    <Order>2</Order>
                    <Description>Activate Windows</Description>
                    <RequiresUserInput>false</RequiresUserInput>
                    <CommandLine>cscript /B C:\windows\system32\_slmgr.vbs /ato</CommandLine>
                </SynchronousCommand>
                <SynchronousCommand wcm:action="add">
                    <Order>3</Order>
                    <CommandLine>shutdown.exe -r -t 30 /c "The computer will RESTART in 30 seconds"</CommandLine>
                    <Description>Reboot at end</Description>
                    <RequiresUserInput>false</RequiresUserInput>
                </SynchronousCommand>
            </FirstLogonCommands>

While this section doesn’t speak directly to running the pnputil.exe command, you could add it to the list of steps pretty easy, possibly in the first section with “description move to ou”. The auto login command allows this section to run once the desktop is configured. The last step of the first run section tells windows to reboot after executing everything else. The concept will be the same or you, run the pnputil command with the proper switches and then the last step will be to reboot loading the proper drivers at restart.

@Mdearmas I think I would start with your router. Look up the model and how to enable directed broadcasts, also look to see if there is any helper services that can be turned on to forward WOL packets to the target LAN. Your issue isn’t with FOG, but rather its a network infrastructure issue.

@george1421 I was pretty close with my limited knowledge of this.

google-fu: router forward wol broadcast to different subnet

AI response
To forward Wake-on-LAN (WOL) broadcast packets across different subnets, you’ll generally need to configure your router to forward these packets, as they don’t inherently route like standard IP packets. This often involves enabling directed broadcasts or using a WOL proxy agent.
Here’s a breakdown of the process and some common methods:

1. Understanding the Challenge:

   WOL relies on a “magic packet” sent at the Ethernet layer, not the IP layer.
   Routers primarily handle IP traffic and don’t typically forward broadcast packets across subnets by default.

2. Methods for Forwarding WOL Packets:

   Subnet Directed Broadcasts:
   Configure the router to forward broadcast packets to a specific subnet.

This involves using the broadcast address of the target subnet (e.g., 192.168.1.255 for 192.168.1.0/24).
The router at the destination subnet needs to be configured to recognize and forward the WOL packet as a true broadcast.
This method allows you to target multiple subnets.

WOL Proxy Agent:

A WOL proxy agent acts as an intermediary, receiving WOL requests on one subnet and rebroadcasting them as a directed broadcast on the target subnet. 

This is often used for WOL over the internet or when directed broadcasts are not desired.

Using a Router with WOL Support:

Some routers, like those from CommScope, have native support for forwarding WOL packets. 

You may need to configure specific settings, like forwarding UDP port 9 (or 7) and using helper addresses.

3. Example Configuration (using Subnet Directed Broadcasts):

   Identify the Target Subnet: Determine the IP address range of the subnet you want to wake up.

Find the Broadcast Address: Calculate the broadcast address for that subnet (e.g., for 192.168.1.0/24, it’s 192.168.1.255).
Configure the Router:

Enable directed broadcasts (often under "ip forward-protocol udp"). 

Configure a helper address on the router’s interface facing the WOL server, pointing to the target subnet’s broadcast address.
Ensure UDP port 9 (or 7) is included in the forwarding rules.

Send the WOL Packet: Send the magic packet to the target subnet’s broadcast address.

@Mdearmas This is only at the fringe of my knowledge, but WOL is a L2 protocol that won’t traverse routers until you have a helper service (like dhcp relay is for dhcp) that will forward directed broadcasts across your router. I understand why it works but not sure how to get your router to forward directed broadcasts to the intended target vlan.

@diogo-seabra

post taken from this thread: https://www.elevenforum.com/t/automated-windows-11-installation-with-post-installation-script.28219/

"The normal sequence for Windows Post-Setup:

• Exit specialize pass, and run OOBE​
• Run C:\Windows\Setup\Scripts\SetupComplete.cmd, except when Windows finds an OEM license key and it’s skipped entirely​
• Begin user provisioning for the first logon user​
• Run RunOnce or Run registry tasks​

SetupComplete.cmd would be ideal for you, it’s right after OOBE but before any user profiles are provisioned. But the problem is Windows deliberately skips SetupComplete when it detects an OEM setup."

There are several ways to do the injection the most correct place is the setupcomplete.cmd file. But if you have an OEM licensed install that file is skipped.

The other option is to add the driver injection (only one call to pnputil is really needed in my experience) is if/when you use the unattend.xml file. There is a first run section where you can call applications at first login, but you must couple that step with autoadminlogin function, so as soon as OOBE finishes autoadminlogin logs in the administrator account once to run the firstrun section of the unattend.xml file. This way is a bit more complicated to setup. If you can get the setupcomplete.cmd file to run its much easier of a setup

@cwhitmore https://www.youtube.com/watch?v=eJcd4c7wU3o might get you started.

Are you having issues or just want to understand what you can do.

@Aaexy said in Deploying FOG in a Secure‑Boot‑Mandated UEFI Environment:

Secure Boot policy Must remain enabled at all times; only Microsoft‑signed keys are in the firmware (no option to enrol custom keys).

If this is the case there is nothing you can do with FOG. You will need to get the ipxe kernel (ipxe.efi / snp.efi) and bzImage signed with the microsoft keys so they can boot in your environment. While this pains me to say, you would probably be better off with a different imaging solution than FOG.

@mbghost said in UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0:

I disabled Snooping

If that was dhcp snooping I can see where it might be causing a problem. If that’s igmp snooping then for multicasting you want that enabled.

@mbghost said in UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0:

But when I try to create an image from the FOG web console and capture image, it breaks everything. I get the same error on all device

Mind including the error you are seeing? It would be helpful to include a screen shot or picture of the error so we can see the context of the error too.

@mbghost If the network test doesn’t work then lets focus in on that toshiba all in one. Lets identify the hardware components since it seems to be the focus of the problem. First do the easy stuff.