@Nono Without going through the web interface you can check the file in /var/www/fog/lib/fog/system.class.php.
Toward the bottom of the file there is a line that start with define('FOG_VERSION'

@hammerc807

This is what I had to do, was in the same boat.

Go to /opt/fog/.fogsettings

Remove the sysv-rc-conf entry from the packages line from there. (Reference: https://github.com/FOGProject/fogproject/issues/797)

Lower down in the same file, set “php_ver=‘8.2’” to “php_ver=‘8.4’”

Exit and save.

Then I had to remove symlinks in Apache that were using the old php modules:

sudo unlink /etc/apache2/mods-enabled/php8.2.conf
sudo unlink /etc/apache2/mods-enabled/php8.2.load

Then add the new links:

sudo ln -s /etc/apache2/mods-available/php8.4.conf /etc/apache2/mods-enabled/php8.4.conf
sudo ln -s /etc/apache2/mods-available/php8.4.load /etc/apache2/mods-enabled/php8.4.load

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…