@george1421 Thanks a lot, it works !
Have a nice day and thank you again !

@kamburta I am not sure this is the right topic to be trying to bring back from the dead. There has been quite a lot (almost entirely) that’s changed about FOG since 2014.

Registering nodes ot the master is, now, automated during the installation process of a new storage node.

@mashina hd isn’t a “true” kernel argument, and as such isn’t built as an environment variable at load up. As the OS loads, the getHardDisk function will get called and make its best guess to what drive to use.

If you want the specific disk of a host to be /dev/nvme1n1, then you should set it on the host under kernel device (or if it’s always global, set fdrive=/dev/nvme1n1 on the extra args instead of hd=/dev/nvme1n1)

@professorb24 Here is a wiki page on the fog client install and setup: https://docs.fogproject.org/en/latest/installation/client/install-fog-client/

The unattend.xml file is a windows thing. There are many resources on the internet that discusses its setup: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/update-windows-settings-and-scripts-create-your-own-answer-file-sxs?view=windows-11

The unattend.xml file is an auto answer file used by the windows setup program to preanswer all of the questions that the installer might ask during installation. There are even answer file generators on the internet that you can answer a few simple questions and it will create the answer file in the proper format like this one: https://www.windowsafg.com/win10x86_x64_uefi.html (I would be careful entering your actual license key on a internet web page, just edit the answer file when you get it by hand to include your key).

I also have some tutorials on fog post install scripts. This one has code snippets at the bottom of the post that discuss the unattend.xml file and how to potentially update the file with the script. https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script The way the forum works read the first post and then scroll to the end to read the second and third posts in the series.

Thanks for clarifying it.
The default bzImage kernel already had the network drivers needed for my setup (onboard Realtek NIC). I checked the WoL status of the ethernet adapter with ethtool. It showed:

Supports Wake-on: pumbg Wake-on: d

So WoL was supported, but disabled.
Then I followed this guide to enable WoL on boot: https://wiki.archlinux.org/title/Wake-on-LAN
I created the /etc/udev/rules.d/81-wol.rules file in init.xz and init_32.xz, and added this rule:

ACTION=="add", SUBSYSTEM=="net", ATTR{address}!="00:00:00:00:00:00", RUN+="/usr/sbin/ethtool -s $name wol g"

I use ATTR{address} instead of NAME, so this rule would apply to any network interface (except loopback), regardless of the interface name.
With this rule in place I can wake up computers after a shutdown task (deploy with shutdown or capture with shutdown).

TLDR; I only needed to add an udev rule to the pre-built init.xz and init_32.xz (https://github.com/FOGProject/fos/releases/latest) to enable WoL.

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