@ rodluz

Okay - So I got FOG working on my rocky 9.6 set up with a few caveats.

I had to do some work to get tftp and pxe to work correctly.

created a symlink from /var/lib/tftpboot > /tftpboot

enabled and started the tftp service manually - systemctl enable tftp & systemctl start tftp

then created a file in /etc/systemd/system/tftp.socket.d/override.conf (after making a director /tftp.socket.d and giving that file permissions) with the following code:

[Socket]
ListenDatagram=69

[Service]
ExecStart=
ExecStart=/usr/sbn/in.tftpf --foreground --secure /tftpboot

reloading the systemd service daemon - “systemctl daemon-reload” & “systemctl restart tftp.socket”

The server would then pxeboot at least BIOS at this point.

The Web UI currently seems to have php conflicts. I installed php-8.0.30-3 and the modules connected to this when installing the server. The web UI has a quirk on the FOG configuration page when you have a button for DefaultMember FOG Version: () it is not printing the version of FOG or the versions of bzimage or init.xz files and in checking using curl http://ip-address-of-server/fog/service/getversion.php - i ony see - 1.5.10.1698

here is a picture of the error

error.png

Yes, was able to confirm it is working. Thank you for your help!

@boombasstic This is known and will be fixed automatically on the 15th, but please if you need to switch to the dev-branch and install it. Then you should be able to export reports.

@Tom-Elliott I figured it out.

I was getting confused by the similar language between the installation process and storage group setup.

A normal installation is just a fog storage node that has a web server and UI on it. A FOG network requires atleast one to work. However a Storage node can be set as the master of a storage group no matter the installation type.

My problem was that because the storage node in the “Bris” storage group did not have a master node setup, the default group could not replicate any images or snapins over. All storage groups must have a master for it to work effectively.

@Tom-Elliott feel free to clarify any of the above rant.

Thank you for the information. I used a bare metal machine. I started with a VM but then just used a old pc. I tried it with Fedora then Ubuntu but did not have any luck. I did not get any errors when installing with the install script.

I will take a look at the information you gave me and see if I can get anything working.

@collegestjoseph Can you try out this testing kernel and let us know if it works? https://github.com/rluzuriaga/fos/releases/tag/EXP_20250927

@Fog_Newb Yep, it’s as I suspected:

The Line:

Subsystem sftp /usr/lib/openssh/sftp-server

should be changed to:

Subsystem sftp internal-sftp

Then restart ssh services: systemctl restart sshd

Then your Storage Node testing should succeed!

My RP address was not pointing to my FOG server 🤦

Once this was adjusted, multicast is functional. Definitely a good reminder to start small.

I found the issue!

The udpsender path on my system was “/usr/sbin/udp-sender”

The path that is set within config.class.php is:

define('UDPSENDERPATH', '/usr/local/sbin/udp-sender');

I ran the following and restarted the FOGMulticastManager to resolve:

sudo ln -s /usr/sbin/udp-sender /usr/local/sbin/udp-sender

And we have logs now! Time to begin multicast testing 🥳

@rhysb92 We need more information.

i ask because I have just built a new VM, and installed dev-branch/stable and it completed and I was indeed able to login with the fog/password combination where i then changed the PW.

So I feel like we’re missing some key information.

All issues have been resolved by the latest kernel . Best regards, this thread can now be closed. Solved. 😉

Well, I have to admit, I opened this issue a while ago, and then didn’t really have time to play with it. I only have a handful of these machines, and while it’s a pain when I have to reimage one, I didn’t have time to spend a lot of time trying to figure this out. Well, today I had to reimage another one of them, and so just out of curiosity checked this thread again, and wouldn’t you know it, it seemed like the issue might be resolved…I updated the kernel, started imaging, and it is going in 5 minutes again!

Thanks so much for an amazing product and community!

Q

I completly reinstalled the dev_branch software in an new Debian 12 guest and now it seems to work fine.
Thank you

@Tom-Elliott that seems to have solved it. Thanks yet again for speedy service! Cheers

@Tom-Elliott
That was it, Tom. Thank you so much for helping me with this. I was starting to lose some hair!

Fix is here:
https://github.com/FOGProject/fogproject/issues/740

Hey @Tom-Elliott I was able to get our FOG instance working by following the upgrade path to upgrade fully to 1.5.10.1673. I guess I should have tried that first :-/.

Thanks for your help.