My RP address was not pointing to my FOG server 🤦

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

@Tom-Elliott I don’t think its working then.

Storage Groups:
b08b1903-48f2-4cd1-98d3-66b7d7432ac3-image.png

Storage Nodes:
3c2a27a5-0d58-4dc3-867f-f3983e04be2c-image.png

Image Storage Group Association:
a24f19ea-8550-4c79-aced-f1449c408f23-image.png

However as provided in my last post, according to my logs this image in not replication, nor any snapins.
Also the images on my nodes are different sizes, so I take it as my asumption of non replication is correct:
Melbourne Server:
7641ab3e-b182-4c76-91da-727f78b8a8f9-image.png

BRIS_FOG server:
d3a0f4cb-afd5-4f0e-bd41-ff34bc56fc76-image.png

Any ideas?

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 🥳

@Fog_Newb Is this happening on all images you’re capturing or just this specific machine, or this specific model of machine?

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

@Richarizard504 dev-branch should now have all the necessary things to allow exporting of any report style thing properly.

Thanks for reporting and apologies for not catching this sooner.

Hi every one.

I’ve got the same problem with Dell Pro 16 PC16250.

The PXE boot stuck at : EFI Stub: Loaded initrd from Linux_EFI_InitRD_Media_Guid device path

I’ve allready had this message with other models : Dell Latitude 3550 et des Dell Optiplex 3080 SFF, but boot keep going and the deployment start.

And not with Dell Pro 16 PC16250

My server (debian 12.12) is up to date.
Fog is also up to date 1.5.10.1698
The kernel too : bzImage version : 6.12.35

I tried to change the DHCP (Debian too) file with snponly.efi : stuck too

I’ve tried older kernels : 6.1.89, 6.6.9, 6.6.49 : stuck too

In the BIOS, Secure boot and TPM are disabled

I’ve tried to add kernel arguments : acpi=off noapic nolapic pci=nomsi nomodeset intel_iommu=off iommu=off

But no success

Dear Fannarino,

First, what version of FOG are you using? I assume you are using this FOG server for DHCP?

with your VM is the networking set to NAT for the VM or Bridged?

First - Did the install script finish without any errors? I would check that as the script handles all the database stuff FOG needs. Check the Docs on installing FOG to ensure you did all the steps on the database.

Since you are using a different network than that one you use for the internet, then you need to ensure all IP addresses for the interface you are using match. If you set these up with a script using a network for the internet and then changed it, then you will need to ensure all IP addresses match.

Second - On your Fog Settings in the Web UI, check your various IP Address settings particularly
Fog Configuration: TFTP Server
Fog Configuration: Web Server
Storage Management > DefaultMember

Next, check in your Fedora VM, check the following.
/etc/dhcp/dhcpd.conf
/tftpboot/default.ipxe

Then check your FOS, which is the bzimage files FOG uses to load the OS your computer is pxebooting. this might effect proper booting or execution of any task in FOG. You can check this in Fog Configuration, then click on the blue button that says "DefaultMember FOG Version: ( ) it will list two files.
bzimage Version
bzimage32 Version

If this is too old you can replace these, which are located in redhat OSes (I use rocky linux myself) under /var/www/html/fog/service/ipxe. You would need to replace about 4 files which you can download from github, under fog project.

These are the points I can think of.

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.

@AngryITGuy The iPXE file likely needs the boot shim or whatever to allow things to work correctly and with upgrades this isnt’ really feasible as every newly built ipxe file (snp.efi, snponly.efi, etc…) would need that shim configured and installed in place.

It’s possible there was a step in the original installer from your collegue that may have moved the ipxe files from a backup where these were shimmed appropriately?

I don’t know exactly just spitballing.

Ultimately, yes, I’m glad you got this working by disabling secure boot.

Technically, it’s possible to do this with secure boot, but not in an easily scalable way that we can include as part of the install script. Nor, in reality, do I think we want to do such a thing. While it’d be nice to do it as an installer, I am hoping we can get a document that more clearly details what steps to do. This is mainly due to the constantly changing nature of fog, so if we have an easily repeatable knowledgebase on what steps to do in a well documented sort of way, it’d be a lot better than trying to have us maintain some installer that could easily have some issue on a new iteration and continually have to maintain yet more blocks of potentially os dependent code.