Topics created by Goll420

@goll420 Ok here is a quick explanation of why the suggestion. iPXE has 2 basic sets of boot loaders. One boot loader has all of the known network drivers installed and only uses a single standard driver that interfaces with the firmware on the network card. This is the same idea for both bios and uefi.

For bios the standard driver is undionly.kpxe (fog recommended)
For bios with the all included network driver its ipxe.kpxe

For uefi the standard network driver is snponly.efi
For uefi the all included network driver is ipxe.efi (fog recommended)

For the FOG recommended boot loaders. The undi driver for bios is very old (~20 years) and very stable. The snp driver for uefi is new (~6 years) and in the early days not very dependable. That is why FOG recommened the ipxe.efi (all native drivers). With new hardware coming out the iPXE boot loader community can’t keep up with really new hardware and the snp network drivers are getting more mature. So the FOG developers at some time may switch their recommendation to the snponly.efi, but not today.

One last bit of info, its up to the network card manufacturer to write the proper snp driver into the network card’s firmware. Some do this better than others.

Well rebooting the switch does seem to have had some effect, this batch are now multicasting at 2Gb/min. I’ll look at getting it replaced, it’s a noisy beast anyways.

@sebastian-roth Thank you.

It’s the 1.5.9 version. Not tried with a different browser, only Chrome for the time being.

I’ll dig through the logs but if the page is a redirect I guess that’s where the problem lies.

@Goll420 said in Multicasting:

I’ve set the remaining 8 going now, but I omitted the WOL part and started them manually. See if it makes any difference.
I never said before that this was a RAW image as the drive was encrypted with Bit Locker. I noticed an error on the end of the deployment on the hosts and then the reboot.
The tasks still show spinning and the hosts have all gone back to the deployment screen amd sitting there waiting for it to begin.
Logs show that the Multicast has finished, but I believe it’s this error that is stopping it progressing any further.

Sorry for the long delay. Time is sparse at the moment and digging into such things usually takes a bit. I just tested multicasting several times and they all worked perfectly fine finishing the task. I am fairly sure that what you describe is caused by some kind of “checkout” issue where hosts are don’t properly report back to the FOG server when finishing the multicast session. So it would be helpful to know what error message you see at the end. If you see this happening again you might want to take a look at the Apache and PHP logs (see my signature) on the FOG server to see if errors are reported there as well.

Image type being RAW shouldn’t play a role. As far as I can test and know the code this does not seem to be a general issue in the multicast code I reckon.

@Sebastian-Roth Thank you, I did forget about using Multicast. I’m running a job now using it and it’s immensely improved bandwidth utilisation!

Never mind, found the option in settings. Now working fine and just have to change the boot device before letting the client do it’s thing.