@huecuva said in Hanging on ipxe initalizing devices.:

Can those iPXE binaries be changed in the webgui?

No because it all depends on the DHCP server you actually use in your network (quite often it’s not on the FOG server itself).

@rubensurtfe-0 As soon as the boot files are sent to the target computer, the FOG server is no longer involved with the target computer. SO this error is with what ever OS is running.

@george1421

Now you said that isc-dhcp server worked?? The reason why I ask is that isc-dhcp server and dnsmasq do the same thing. So why would isc-dhcp server issue IP addresses and dnsmasq does not respond?

To be honest, this is beyond me.

Initially, when I configured the FOG server I installed isc-dhcp server, configured pool of addresses and added “next-server” and “filename”. Then I set bootprelay of the switch to point to the FOG server and everything worked (and still works if I go back to this scenario).
Afterwards I realized that our expensive switch supports dhcp and decided to give it a shot (why use separate service for something that already runs on the switch, right?). Since then I’ve encountered this issue i.e. switch supporting only numerical option codes (66, 67 etc). Analyzing the frames turned out that my clients are unable to evaluate those options even though they do exist in the dhcp packets! Having “next-server” and “Boot file name” in the packet body seemed like the only way it works. I managed to confirm this by analyzing frames coming from my working isc-dhcp server.

Now, you can probably see how strange it is.

@active-pcb I guess the partitions were set to use a fair amount of the disk space for /home when you installed Ubuntu. Run sudo fdisk -l and post output here in the forums.

@nerdstburns Adjusting compression ratio with Zstd might help to speed it up.

Thank you!

@sebastian-roth @george1421 I may have posted this thread prematurely. I ended up having my colleague try a different type of Ethernet dongle (USB-C vs regular USB) and that did seem to fix the halting issue. I can verify tomorrow, but I think that message in the picture is still there, it just keeps imaging until complete now. I also found out a nice new BIOS came out for this model, so it is possible an update can fix the message. I can test the bios update with one at some point, but we are pretty busy with students returning next Tuesday in person.
I think we can mark as solved in the meantime.

Thank you - That is helpful. It seems the persistent groups plugin works more along of the line of what I expected from the default groups.

It seems then that it is not possible to have snap-ins defined as defualt, associated to an image or ALL hosts regardless of groups? Perhaps that goes against what a ‘snap-in’ is reallly intended for…

@george1421 The command work for me. Thanks for the help.

@george1421 @Sebastian-Roth Just wanted to give you an update. From what I can tell, the section of dhcpd.conf where you declare options, was missing a } so the file wasn’t reading the options I guess? I compared the file to an old server and that was the only difference I could find. I probably deleted it while editing the file at some point. Works like a charm now.

@fognerval is the BIOS on UEFI or Legacy boot? You might need to change your files on the DHCP server. Also, are both the Device and DHCP servers on the same network? If not, then you might need some IP helper configuration or proxy. More information on setup is needed I think to figure it out.

@nil If you are interested in helping start out by writing a tutorial in the tutorial forum. Then once others have a chance to prove it out it will be converted to a wiki page.

Thank you for helping the FOG Project move forward by adding new options for installing FOG.

@sebastian-roth Thanks for your reply, we will try the alpha version.

My teammate ask me to say a big thank you because since 2008 we use fog and we see you’r answer are very quick and we are very happy to use fog.

did i need to do something to indicate the post as resolved ?

@julio If you need rename and domain join on Linux systems you’ll have to manually add scripts to do that work for you. Rename can be done woth post-deploy scripts I would think but domain join is another story. You might even need to add systemd/initd scripts to do that for you. Currently this is way beyond what FOG or the fog-client can do for you I have to admit.

@george1421 The code works as expected now. I used your shortened fog.updateregbarcode that just echos the variable into the text file on the C; drive.

@matthew11 Totally out of scope question for FOG. FOG hasn’t use syslinux for pxe booting in over 10 years. FOG uses iPXE for a pxe boot loader. There are parallels between the two, but they are not the same.

With that said, if you have the default config file for syslinux it might be possible to translate that into iPXE syntax, but I would have to see the changes needed to that file.

@seppim I have no idea since I did not test loading it with memdisk. I did not look but I suspect the iso image may be larger than 2GB (thinking memdisk is a 32 bit application and not a 64 bit app. But this is only a guess). I know when I was testing the boot.wim file on the iso was 1.3GB in size.
I was able to get it to boot in uefi mode here: https://forums.fogproject.org/post/140212 but in bios mode it complains about needing bootmgr.exe in the iso image.

@Epsilon52 Thanks for the update and good to know. Maybe it just needed a cold boot or something like that.