@atlas When it comes to opensource, the only wrong answer is one that doesn’t work. Well done!

Another hackish way would be to instead of changing the programming, you could enter a fake/but valid entry in the /etc/hosts table to point the dns entry to your internal server. This way you can use fog native code when version next comes out. But again if it worked for you it was the right answer.

Never mind, I renamed the file /opt/fog/.fogsettings and runned the installer again with ssl enabled. It’s working just fine.
Probem solved, this topic can be closed. 👍

@fadi you can try re-running the installer.

I don’t know why you have /images2 and /images2/dev, but re-running the installer should re-associate the missing directories, permissions,ant .mnt file (I cannot remember the full name of the tester file sorry)

@flodo First let me say I don’t know Ansible, I know of it but that is about it. So I always force my way through things.

But with imaging there are two approaches to take.

Leave bread crumbs (deploy time configuration info) behind for the target OS to pick up with its internal setup program to consume. In the MS Windows realm that might be mounting the C drive and updating the unattend.xml file with deployment time settings like computer name, calculated target OU, timezone, etc.

Using a FOG postinstall script to mount the root partition on the target computer and use a bash script to make system changes like set the hostname in /etc/hostname and other parameters that the target system will need at first boot. If you can script it with bash you can probably update it in the target linux OS. When you are done, you would unmount the mounted partition and then let FOG finish with the deployment and reboot the target computer. I have an example of how to do this for windows, it can easily be translated to linux.

If you wanted to go the ansible route, then you need to identify what you need on the FOS Linux OS and then we/you will need to include that plus the ansible code when FOS Linux is compiled. It is not as hard as it sounds. You need to find the dependencies needed for ansible and then update the buildroot configuration to included the dependencies. FWIW: the FOS engine does have ssh server installed, but with only one user root. So to login remotely to the FOS Linux engine you need to give root a password then you can connect remotely to FOS Linux over ssh.

@ian77 That is strange that the storage variable points to /images2 and yet /images gets mapped.

Now understand on the FOS linux side it will be /images/dev, but what its mapped to should be /images2/dev.

So you are in debug capture mode. What you will do is confirm that the storage variable is pointing to you /images2/dev directory.

The first step is list manually try to mount the directory to see if nfs is working correct…

Please post the output of /etc/exportfs, the fsid variable needs to be different between the /images and /images2 paths if they are the same you will get exactly what you are seeing. It placing the files in the wrong directory.

/images should have fsid of 0
/images/dev fsid 1
/images2 fsid 2
/images2/dev fsid 3

once we sort out the fsid I’ll continue with debugging instructions.

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.