@sebastian-roth Ah, my bad. I did not see that previous post. I tried snponly.efi, deploying works fine now. Thanks a lot!

@george1421 Thanks, After downloading the more recent kernel since it worked, I proceeded this way because I encounter problems directly via the server interface.
We can now use fog on our newer machines.👍

@sebastian-roth said in Can't multicast on latitude 3310:

more I think udp-receiver is actually dying at this stage and not delivering the rest of the data.

What if we are running out of memory on FOS Linux partition. Where we bumped it up from 127MB to 275MB for the larger inits? This 3rd partition isn’t that large though. My C drive partition is 25GB, but I rarely multicast while imaging. I do remember we had to make the FOS Linux drive for one user before we upped it to 275MB but I can’t remember the circumstance.

Something else we need to be mindful of / is this is an untested image from the perspective of multicasting. This is the first uefi image to the first uefi target computer the OP has. The previous ones have all been bios based.

If I remember correctly when the multicast task starts, it actually spins up one udpsend task for each partition. I wonder if that task is terminating on the server not the target computer. But again why only for uefi systems…

I need to update the storage nodes, how are they updated? the Web Master updated it and it worked correctly

@fog_client Hello, its good to know these devices have that raid mode switch. Good job finding it in the bios. If you only have one drive in these computers you can leave it in ahci mode and be happy. Windows will not see any performance loss in this mode.

@kkthnxbb Thanks for posting the video. Looks like the crash happens exactly at the point where iPXE hands over to the Linux kernel. I stepped through the video and saw it showing ok for both bzImage and init.xz. While it could be a problem with the Linux kernel as well I would expect the issue to be in iPXE.

Do I get this right, migrating the VM from ESXi 6.5.0 to ESXi 6.7.0 fixes the issue for you?

Let’s try to go back to an earlier iPXE version. Which version of FOG did you use before 1.5.9? You can download older iPXE binaries on github using this URL: https://github.com/FOGProject/fogproject/tree/1.5.8/packages/tftp (just put in whichever version you had before, 1.5.8 or 1.5.7 or …). You don’t need to download all the binaries. Just grab ipxe.efi and put that into /tftpboot/ directory on your FOG server. Then boot up the VM again.

You might want to pay attention to the iPXE version string printed when it starts just to make sure the switch of the binary actually worked.

@Chris-Whiteley The default for a current install of FOG is still 4.19.x series because that is the last / latest LTS version of the linux kernel. When the kernel developers release the next LTS version of the linux kernel (supposedly to be 5.10.x) then the FOG Developers will make that standard.

This worked for me on a 3550 as well.
Thanks!

@george1421 Thanks for the help and quick responses!

I’m not sure how to mark a question as solved if I’m able to.

@dtkeith002 said in Acer Aspire A515-55 Connection Timed Out:

Does FOG offer the ability to listen on multiple interfaces / ips at the same time? I haven’t dug into the config files to see. If so I can try a direct bridge to the server VM and bypass the network completely.

Don’t think it’s worth going down that route. Testing on the same switch as the server should be enough to rule out most of the network related stuff.

From the picture we see that it seems to be able to fully download the kernel (bzImage) file but times out on the initrd (init.xz). I would setup a mirror port on the switch and capture traffic on both ends - client port (using a notebook with Wireshark on the mirror port) and directly on the FOG server (e.g. using tcpdump). Use capture filters to restrict traffic to a particular MAC address (ether host aa:bb:cc:11:22:33). Please upload the PCAPs to a file share and post links here.

If that doesn’t give us enough insights we might compile debug enabled iPXE binaries to analyze the TCP traffic - though this will a tough job!

Have you tried using ipxe.efi yet?

For these new hardware you need to use the 5.6.18 kernel found under the kernels update menu in the FOG Configuration or you can upgrade by hand using the kernel link https://fogproject.org/kernels/ I would always use an official kernel instead of any one off link you might find.

@acsand0199 If you have issues post back and I’ll see if I can give you a direction to look in.

@MikeBC I agree. In our imaging lab we are only using wd15 docks the wd19 even after the dock firmware upgrade were just to unreliable reporting to the firmware as pxe compliant. So in the end we moved the wd19 docks to the user’s desk and acquired their wd15 docks for the imaging labs.

This also worked for me, but with a Dynabook A40 laptop.

Thank you.

@jps While you can go with just updating kernel and init files with some manual adjustments in the config I am wondering if a proper upgrade to 1.5.9 would be the better choice in your case. We fixed hunderds of bugs since then.

Why so you still use such an old version?

@Sebastian-Roth To my memory we replaced kernels (both 32 & 64 bit), init’s/bzimage (expanded to more and more files etc during troubleshooting to try to find the culprit) none helped other than upgrading to 1.5.8. I assume it’s something Dell specific with some weird OEM magic that messes up something somehow somewhere… 😉

Thanks, @george1421. I haven’t worked out the DHCP problem yet, though - I just need to walk away from it for a while. I’m stumped.

@george1421 That was it! I figured it was a setting but couldn’t find it. Thanks!

@FuriousGamer065 First let me say I’m asking because I don’t know.

Does NVMe disks work in bios mode?

For SANBOOT you have to remember that is a bios only boot loader (built into iPXE). It references disks by their bios ordinal position.

For example with FOG it issues this command when you pick SANBOOT. sanboot --no-describe --drive 0x80 In bios syntax drive 0x80 is the first hard drive 0x81 is the second hard drive and so on. Since you have 3 drives 0x82 is the last bios referenced drive. Its possible because of the bios order 0x80 may not be your NVMe drive but a sata drive (I don’t know) but that will explain why SANBOOT is not working for you.

So you might ask how can well tell. Good question…

I think what I would do is create 2 new iPXE menus for testing.

The concept is based in this tutorial: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

But we are going to make a twist on this.

Make two new iPXE menus:
Menu Item: os.Sanboot.D2
Description: Sanboot Drive 2
Parameters:
sanboot --no-describe --drive 0x81 || goto MENU
Menu Show with: All Hosts

Menu Item: os.Sanboot.D3
Description: Sanboot Drive 3
Parameters:
sanboot --no-describe --drive 0x82 || goto MENU
Menu Show with: All Hosts

Now boot into the iPXE menu and see if either of the new sanboot menus work. It will be interesting to know if one of the alternate menus work correctly.

@george1421

Awesome!

BTW, little off-topic do you know why I had issues initially to upload on forum?
Was due to the fact fresh user account and low reputation?

Now I tested seems fine.