Ok so I now have a second system with the EXACT same issue. I purchased a Dell Precision 7875 which has 2 on-board nics. I updated our dhcp server to issue an IP address for one of the two NICs. With the system connected to that interface I PXE booted the system. The first stage of the fog shows as it notices the system is not registered and asking whether I would like to register the system. Yet once I say do full registration that’s it it will not proceed further.

So similar to the issue that I’ve raised prior with multiple NICs and @george1421 suggested I PXE booted the system again but went into DEBUG mode. Well as it appears the unused MAC address is now showing up on the interface that I had configured to connect to the network. Seeing that I did not assign an IP address to the second mac address the system would not proceed any further. The odd thing is that BOTH interfaces show up having the same mac address. It seems that there’s an issue with the FOS with newer Dell systems with multiple NICs.

If I disable one of the two NICs in the BIOS, and do the re-imaging process everything works fine…

Really looking for a fix for this…

Cheers

Jason Naughton

@DanCan Hi This is currently a known issue on some motherboards. Honestly not sure what is causing this to happen. I am working on a fix to this issue just haven’t had too much time lately.

@Jchinn412 The answer is it depends on how you have your disk structure setup

Post the results of these two commands.

lsblk
df -h

It maybe easy or harder (but not impossible) depending on how you have the disk created.

@eoli3n Versions are impossible to give because they keep changing, so we do try to have the version that are supported between masters/dev-branch/etc… for the os’s at that point in time (and backward)

Debian Based (Mint, Ubuntu, Debian), Redhat Based (Redhat, Rocky, Alma, Fedora).

The versions, dev-branch is more likely going to be in line with latest/greatest. Some what of a delay of course, but there’s no list that clearly spells out what version of specific OS is supported.

In my opinion, Redhat based OS’s are the best as we don’t have to continually update the installer code to support future versions. Most will just work right out of the box.

Migration process? No, if you’re moving one machine to another that’s one thing of a migration and there is a process for that, but if you’re meaning “I’m on bookworm and without moving anything, I’m going to do an in place upgrade?” I don’t believe there will be problems but what I would suggest is re-installing FOG once the upgrade is complete as any services or config files that got changed would need to be rebuilt for the new OS. It’s not hard and I don’t think there will be any issues. If there are, please let us know.

@Petrushka hello!!

In our firewalld rules we have

services: - ftp - http - mountd - nfs - rpc-bind - tftp ports: - { port: 20048, proto: tcp } # nfs - { port: 20048, proto: udp } # nfs - { port: "35350-36350", proto: udp } # tftp - { port: "49512-65532", proto: udp } # multicast

@Tom-Elliott
The upgrade to stable version completed successfully.
I’m now on fog 1.5.10.1673
Thanks again

@marcolefo Sounds like the package ‘build-essential’ should be an install target of the FOG install script? It doesn’t seem to be.

However I think my distro installs of Debian 12 and Mint 22.1 both installed that package by default.

Solved for me on Linux Mint 22.1

The base problem is that php-mysqlnd is a “virtual package” that is included in the package php-mysql, and trying to install it individually (as the FOG install script does) fails with apt dumping a list of php mysql versions and that “You should explicitly select one to install.” Even if php-mysql is already installed.

The solution for me was to remove php-mysqlnd as an install target in the FOG install scripts. As of this date, that includes:

In file [fog install pkg path]/lib/ubuntu/config.sh:

remove ‘php-mysqlnd’ from line 26 "packages="apache2[…]

In the file [fog install pkg path]/lib/common/functions.sh:

remove the lines

php-mysql*) for phpmysql in $(echo php-mysqlnd php-mysql); do eval $packagelist "$phpmysql" >>$error_log 2>&1 if [[ $? -eq 0 ]]; then x=$phpmysql break fi done ;;

@adam1972 FYI, there are no pending tasks… I just tried creatinga snapin bash that uninstalls the client, to see if it would stop repeatedly rebooting… It just sits there. The log has a “a power operation is pending, aborting module”… I can’t find anything that’s is pending… especially after rebooting several times lol

Edit: So, the target PC was not identical after all. It had an optical drive as well. Don’t know why that would change anything. From dracut emergency shell I found that the driver for the SAS controller card (aacraid) was not loaded for some reason. Works fine on other target PCs without the optical drive…

@RocksAndRolls I’m not sure how much additional help I can provide here but where it failing is at the end of the imaging process, the target system logs into the ftp server on the FOG server using the fogproject user account. That fogproject user MUST be able to rename the captured file in /images/dev from the mac address and the move the directory from /images/dev/<mac_address> to /images/<image_name>.

If you have verified you can log into the fog server via ftp as the fogproject user using the password saved in the fog ui then it has to be a permission issue on the /images directory.

The image capture process is

FOS Engine -> connects to /images/dev NFS share and creates a directory that matches it’s mac address
FOS Engine -> Uploads the disk connect as the root user (on the FOS Engine)
FOS Engine -> Connects to the FOG server as fogproject user and issues a mv command to move the directory from /images/dev/<mac_address> to /images/<image_name>
FOS Engine -> Logs out of ftp and completes the cleanup before reboot.

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.