Solved. It was the init.xz file that was customised for our environment, The default was applied and seems to be working now.

@srcauley If you want to debug the next bit I can help with that too. I’m going to suspect its the nic driver, nic firmware, or raid/disk controller issue. If you setup a debug capture/deploy we can then investigate the errors.

ip a s
lspci -nn | grep -i net
lsblk
grep -i firm /var/syslog

Will get you started

@Ceregon said in Group Kernel Arguments not applied to Host after adding Host to Group while Full Registration:

I had the fear, that when we will have machines without software-raid that will make problems.

That setting just enables the possibility of software raid in the kernel, you still need to use the mdm utility to configure it.

@rodrigoantunes said in Different bios files for different network cards:

wouldn’t it be a dhcp server functionality rather than fog

FOG could do it with some programming, but its probably easier to do it on the dhcp server side. Its not super simple to do, but basically you would setup dhcp reservations or uniqueness based on the mac address of the target computer. When the dhcp server sees a known mac address then it sends out the alternate pxe boot loader. You would make the default pxe boot loader (like undionly.kpxe) be the default and then override it with reservation settings for the troubled computers. It can be done.

I find its strange that the undi driver doesn’t work on some computers but does on others. The undi specification has been around for 30 years. Most firmware has had time to work out the bugs.

@collins91 I don’t have an answer for you, but I can connect what you see to how FOG works.

With FOG, the FOS Engine (OS that gets loaded onto the target computer for capturing and deploying images) uses NFS to move disk information between the FOG server and target computer.

On the fog server there are two NFS shares.

/images that is shared as read only. That is where all of the captured image files end up. The read only attribute keeps the image files from being messed with (i.e. deleted) over the network once they are captured. /images/dev that is shared as read/write. That is where the files temporarily stored at while being captured.

So now you have the basis of the design.
At capture the FOS engine creates a temporary directory in /images/dev share as the mac name of the target computer for uniqueness.

Once the NFS upload is completed. The FOS engine connects to the FOG server using the ftp protocol using the fogproject user account and instructs the OS to move the file pointer for the image from the temp location on /images/dev/<mac_name> to /images/<image_name>. Since only the file pointers are updated this “move” happens very fast.

Then the target computer reboots.

Now to tie this back into what you are seeing, the process seems to be failing on the ftp login and use of the mv command. Your condition kind of tells me the problem is a file permission issue where the (linux user) fogproject doesn’t have the proper permissions needed to execute the mv command.

I would start there for trying to understand why its failed, for example lets say your dead link folder was created by root, and the fogproject user doesn’t have the rights to change a directory created by root. That would cause the process to fail as you outlined.

it was the hostinfo.php file. I copy and pasted from the link you provided into a new file after renaming the old one. Rebooted the fog server while nudging the edge of the case with a baseball bat, and it certainly wasn’t the bat. great solution. thank you!

@pilgrimage This problem is connected to your other post: https://forums.fogproject.org/topic/17255/about-dhcp-and-pxe-problem?_=1707994213348

Your issue is infrastructure and not a fog specific issue. DHCP works based on broadcast messages. These broadcast messages typically are not passed between subnets. On your subnet router there is a service that can be turned on to relay dhcp communications between subnets. I would also think this service is configured on your network because you have client computers on one subnet and servers on another.

Since you are using dnsmasq to provide the pxe boot information since your dhcp server can’t be changed, you need to update this dhcp-helper / dhcp relay agent on your network router to include your dnsmasq server in the list of dhcp servers this service notifies of a dhcp request. Once that is done your dnsmasq server will hear the dhcp request from the remote subnet and respond with the pxe boot information.

@nikith-reddy Is your machine defined to boot to pxe first? This is normally expected.

Is it never going to the OS? If so, you may need to check the boot options in the BIOS to see if it detects the hdd’s available OS’s.

If it is going to the OS, then i’m not really seeing the issue. If you don’t want FOG PXE to boot at all, then you’ll have to adjust the BIOS to tell it to not boot to PXE/UEFI Network Stack.

@RobertD said in PXE boot - HP Elitebook 650 G10 - No configuration methods succeeded ...:

We have been using ipxe.efi for all of our devices for years so I’m afraid to change all our DHCP scopes to use this loader for this one problematic model. Any suggestions?

Its great that you have a path to boot these system via the snp driver.

You didn’t mention if you updated iPXE to the latest release to see if the ipxe.efi boot loader works once again.

Let me (re)clarify in this thread the differences between ipxe.efi and the snpX.efi boot loaders.

ipxe.efi (uefi) and ipxe.kpxe (bios) contain all of the known drivers built into the boot loader, this makes the iPXE boot loader much larger in file size (in 1990 terms of file size) because it has to carry all known drivers onboard the boot loader. For older systems > 6 years those were the preferred boot loaders for iPXE

snp.efi, snponly.efi (uefi) and undionly.kpxe (bios) use the network adapters built in driver through the generic snp or undi interface. This boot loaders are much smaller than the ipxe.* versions since they only need to have one driver onboard (snp or undi). The undi driver (bios) has been around for 30 years and is the preferred and very stable network interface for bios computers and should always be the #1 choice. The uefi firmware has only been around for 12 years or so. The early version were very buggy so the snp driver did not work well. This is the reason why the fog developers recommended the ipxe.efi boot loader for uefi systems. In the last 6 years or so the snp and uefi firmware has matured to a level where the fog developers are recommending snp.efi or snponly.efi for all modern hardware. For bleeding edge hardware you have a better chance to get the snpX.efi bootloaders to work before the ipxe.efi bootloader, because the iPXE kernel developers will need to add the driver to the bootloader. Its just a timing issue.

Now you might ask what is the difference between the snp.efi and snponly.efi drivers. snponly.efi will only initialize a network interface from where it was loaded from. For example lets say you pxe booting a compute with 4 nics, and you pxe bootin from nic2. The iPXE boot loader would only init nic2 using the snponly.efi bootloader. In contract snp.efi would try to init all nic intefaces starting with 1, 2, 3, and then 4. The issue becomes if nic1 takes the boot loader someplace else other than to the FOG server, since the fog server is on nic2.

@alexpolytech94 The shrinking of the disk when using single disk resizable is a bit of black magic. Sometimes because of the actual data size or location of the data on the disk its not possible to shrink the volume down enough to make it fit on a disk that is 1/2 the size of the source disk. I won’t go into too much detail, but if you have a partition that is fixed in size that can’t shrink, but a partition just before it on the disk that can shrink, fog will shrink the one that can be shrunk but leaves the one that can’t be shrunk as it were. If you were to deploy that image to a computer with half the size that non shrunk partition would be technically beyond the last sector on the 1/2 size disk.

To put it another way, always build your mother image on the smallest disk possible, because it can expand to a larger target disk more often than shrink your image to fit on a smaller disk.

When I was building golden images I would build them on a VM with a 50GB hard drive (smaller than anything I would deploy it to) and then let FOG expand the disk to match the target disk size. That always worked.

@zaboxmaster Well we are going to need your assistance to help debug this. I can give you the steps needed to collect the information to help debug this.

Schedule a new deploy/capture task, but before you tick the schedule task button, tick the debug checkbox. Now schedule the task. PXE boot the target computer. After several screens of text you need to clear with the enter key, you will be dropped to the FOS Linux command prompt. This next 3 steps will help with remote debugging and for copying the results out to post here. Key in ip a s and collect the IP address of the target computer. Reset root’s password with passwd Give it a simple password such as hello This password will be reset at the next reboot. Now connect to the target computer using ssh, either ssh from linux or putty from a windows computer. Key in and post the results here of the following commands
uname -a
lsblk
lspci -nn
grep -i -e firm /var/log/syslog Keep the debugging session open for additional commands.

@professorb24 I have a tutorial on how to do this with Dell computers, but the concept is almost the same for other vendors. The key is to have the driver files in inf format so pnputil.exe can install them. Lenovo use to have drivers in .exe format and not .inf format. That made things a bit harder when I was trying to setup lenovo computers.

Looking at the script and it doesn’t appear to do anything. other than mount a wim image, but also be aware that the post install script runs withing a linux environment so it can’t directly interact with windows or the .wim file.

Your post install script should copy the drivers over to the target computer after the image is placed on the target computer. All that FOG can do is leave files behind for windows to find them during OOBE/WinSetup.