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

@mbghost I’m still leaning towards init.xz corruption. Its very strange that on a fresh fog sever it works on day one and then the next its no good.

Just for clarification its all and every Toshiba all in ones but other models work just fine? Its only this specific model.

What I’m thinking at the moment is that bzImage transfers fine and its around 8MB in size. The kernel also boots fine because its getting to the point where it attempts to connect to the root file system.

init.xz is a zstd compressed image. Its compressed size is around 350MB. Both images are very small in size. Something is happening to the init.xz image to where bzImage is not able to mount it and the kernel panics.

This image persists across multiple deployments and multiple installs of FOG server. It also crosses different init.xz and bzImage kernels.

FOS linux does boot 1 out of 12 attempts.

So where could the problem hide?

1. The FOG server hardware if that was a consistent deployment throughout the server rebuilds. (test try building fog server on a desktop/laptop computer to rule out fog server infrastructure)
2. Something with the network between the fog server and the target computer. (move target computer as physically close to fog server as possible and test deployments eliminating all of the existing networking between fog server and target computer)
3. Something with the target computer. (if you have been testing with the same computer throughout these tests use a different computer. Its possible there is a ram issue with this computer)

Right now there isn’t a clear picture on the cause. I can say this IS unique and I’ve haven’t seen this before with FOG.

Something else you might do is in the fog settings, set the log level to 7. I think the default is 4. 7 is verbose and the kernel might spit out more information to why its not happy with the init.xz file. Like decompression failed.

@mbghost This error message baffles me. If its happening where I think its happening its not a pxe boot issue. This error happens after you pick an iPXE menu item or if you tell a computer to image.

So you can probably rule out ipxe.efi/snp.efi here.

This error message is generated with FOS linux is booting. The kernel has booted and when it goes to connect to init.xz the format of init.xz is corrupt for some reason.

What version of FOG are you running
What version of “the kernel” are you running?
What version of init.xz are you running (get this from a bios computer that boots. the version of the init will be under the fog logo)

What computer is this happening on (make and model)?
Is it all uefi systems or only from one manufacture?
How much ram does this computer have?
Are you seeing both bzImage and init.xz get transferred completely to the target machine. This will be visible just after you pick an item on the FOG iPXE menu.

To me this error is telling me something is wrong with init.xz or for some reason bzImage is not the right kernel for init.xz

@mbghost said in Unable to Get IP Address After PXE Menu on Physical PC (FOG Project on ESXi):

ESXi server → Cisco Switch → Client.

So just to be clear pxe boot the vm on esxi works no prob, but physical host does not.

Lets test this, on the target computer, put one of those cheap unmanaged switches (like the $20 monoprice ones) between the pxe booting computer and the building network switch. Now try to pxe boot. If it works then get with your networking group and make sure the switch ports are configured for portfast, because its spanning tree causing you some troubles. Understand this is an educated guess based on what you’ve posted.

Just for some background on this, standard spanning tree takes 27 seconds to start forwarding traffic. FOS Linux boots in under 15 seconds, so its already given up trying to get an IP address by the time spanning tree starts forwarding data.

@uzee FOG doesn’t change or really step into the target system during deployment. You CAN do this if you write a post install script that will get called once the target image is deployed to the target computer. In the case of a linux computer you could potentially set the target computer’s name here by updating the /etc/hostname file or anything else you can do with a bash script. The FOG Client can also be configured to make changes to the target computer or install applications based on instructions from the fog server. Its really identifying what you want to do and how much automation you want to script. Its all possible with FOG and a little creativity on your end. Since you already know Ubuntu (linux) bending FOG to what you want will be easier than coming strictly from a MS Windows background.

@uzee Your approach to this (imaging) really depends on your short term and long term goals.

If imaging these machines are just a one time time (like if you were a PC reseller) then there is a process I call load and go. where you pxe boot one time into the FOG iPXE menu and then issue a Deploy Image from the FOG iPXE menu. This will deploy the target image to the target computer one time and then the FOG server will forget about the computer. Again you would use this method if you were going to stuff an OS onto some hardware and then never see that target computer again.

The other method is the traditional registration, assign an image and then schedule an image deployment. In this case the FOG server will register and know about the target computer in the future. You have to remember though that you register the target computer once and then can deploy many times. Future remote imaging will be possible because you register the target computer with FOG. FOG also gives you the ability to manage the computers in the future if you install the FOG Client.

Now with this registration and then booting. The registration process must be hands on, but imaging can be touch less or at least low touch. Some people will have the target computer configured so that it always pxe boots. In this case the target computer will always pxe boot through the fog ipxe menu. The default action if you don’t touch the computer will be to boot the OS off the hard drive. This boot through the iPXE menu, will also check to see if the fog server has any tasks assigned for the target computer. If there is a task assigned (like reimage the computer) then instead of booting through to the local hard drive, it will boot into imaging. If you couple that with the fog client install on the target coputer’s host OS. When you schedule a deployment to the computer, the fog client will then reboot the computer and then the bios is configured to boot through the fog menu, the target computer will be reimaged without requiring a tech to touch the computer. You would use this process to maybe reset a computer lab between classes, where you can wipe the target computer and then reload the OS on 30 computers in 10 minutes.

The interrupt the booting process twice, is actually pressing F12 to get into the firmware’s boot menu to pick PXE booting. You are not changing the forever boot order, you are just picking one time pxe boot. Yes you will have to do that twice, but this way the default boot is always the hard drive.

@Ryxn I checked and that nic has been in the linux kernel for several years.

And secondly when you checked for missing firmware the kernel wasn’t complaining about missing something.

Its a good thing you were able to get the error while in debug mode. Because that was going to be the next quest for you. To get the system when its behaving badly.

So when you get it into debug mode and its complaining about no nic lets do the following.

ip a s should show if the network interface has an ip address, I’m going to suspect no because it complained about it earlier in the boot process.

lspci -k -nn | more Look through this list until you find the entry. The number in the square brackets will be what you posted earlier. [8086&1502]. See if the nic is visible to the kernel. AND if it is it should mention what kernel driver its using. I’ll give you a for example using my laptop.

0000:00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (
13) I219-V [8086:15fc] (rev 20)
	Subsystem: Dell Ethernet Connection (13) I219-V [1028:0a22]
	Kernel driver in use: e1000e
	Kernel modules: e1000e

lastly if everything looks good, kernel sees the nic, there is a kernel driver assigned. Lets see if time fixes your problem.

When you ran the ip a s command it listed all of the network interfaces and if it has IP addresses. You will need to know the interface name for your network adapter. It may be something like eno1 or ens192, or something else. Get that device name.

Now run this command /sbin/udhcpc -i $iface --now replacing the whole word $iface with the device name listed from the ip command. This will tell the network adapter to again poll for an IP address from your dhcp server. If it picks up an IP address this time, then time does solve your problem and you will need to look into your network configuration and make sure that port-fast or fast-stp is enabled on your network port.

@ProfessorFow OK what I want you to do is on the master node, go into the storage group where this remote node is. Look at this remote node. There should be a ftp user ID and password listed there (said from memory). Use those credentials to connect like you did with the ftp CLI from the master node to the remote node. See if you can login using ftp to the remote node. Then issue a ls command, Its not important what the answer is as long as it gives you an answer and not an error.

If you can’t login using those credentials then on the remote storage node look at the /opt/fog directory. There is a hidden file called .fogsettings. issue the command cat /opt/fog/.fogsettings In that file should be the password for the account used when the fog server was installed. Make sure they match what is on the master node.

There is something with ftp that is not working correctly, that is why the replication is not happening.

@ProfessorFow The FOG replicator uses ftp to transfer files to the storage node. Make sure ftp is not being blocked between the master server and the remote storage node. You might test by on the master node, issue `ftp <remote_server_ip> if you are not prompted to enter a login then FTP is being blocked.