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

@Small0145 said in Client registration error:

il y a environ 18 minutes

@kelocktnt look in “Pending Hosts” on the hosts page. It should be the

OMG !!!
i’ve been walking past it since the beginning without seeing it!!! too newbiees

Thank youu @)

@Tom-Elliott Success. I switched to single-user with init 1, and installing systemd-sysv worked fine.

As this is a machine upgraded from debian 11, maybe it wasn’t using systemd. Installation of 1.6 worked no problem Thanks,

@AUTH-IT-Center That is correct. That’s what that FOG Settings item is meant to do. If that is checked, on registration it should set that flag on future registrations, but it doesn’t on existing hosts that were registered before it was checked. If after this is checked and a new host registers and this isn’t working, I would believe there to be a bug.

Though a workaround exists, so while, it would be a bug, it may not be the biggest concern to get fixed immediately over say actual imaging issues.

@PatrickL You might want to review this post: https://forums.fogproject.org/topic/17648/massive-cpu-usage-from-a-service

That .sysvd is suspicious and very similar to the thread above.