@tesparza You will need to do a Full Host Registration when you do the network boot.

@dmcadams Sorry for the late reply but I’ve had too much on my table this week and couldn’t find the time to think through this again.

Great you tested different kernels and found one working fine. Short answer is, name this kernel binary different to the default Kernel naming theme, e.g. bzImage-4.19.6 or whatever suites you and set this name as Host Kernel in each host’s settings having this issue. Make sure you update the general kernel to the latest via FOG settings again so all your other machines will use the new one.

The longer answer is: With that new information I don’t think it’s a temperature issue really. Sounds like this kicks in with a certain Kernel version probably because it has some new driver or feature added that is causing this. Often some new features (e.g. NVMe optimization or so) are implemented differently by various vendors. While drives from vendor A might go with it just fine some other vendor uses a different code in its firmware causing a problem in the Linux kernel.

If you are really keen we can go and test each kernel version one by one to find what’s causing it and possibly find a solution (special kernel parameter or a patch for the code). Though this will need work and time. I can give you many hints and instructions but it’s your call to work on it. Compiling kernel after kernel (very easy to do) and testing each while keeping close track of the results to find it. It really needs determination to stick with it. But you will learn a lot I am sure.

@epatterson Any changes made to the Synology or FOG server configuration? Why should it work in the morning and error out later if nothing was changed?

Maybe restart first the Synology and test, then the FOG server and test again.

@tom-elliott
Thank you, will do it that way.

@jim-holcomb Was an upgrade recently done?

@tom-elliott Ahhh, thank you. Yes, that seemed to be my problem. Can that be sent along with the API request, out of curiosity?

@george1421 - Wow I am still amazed at how powerful this gem is! Thanks so much!!

@yoshideoeuf said in UEFI can't PXE boot:

it’s /24 for both

So do you have a dhcp helper service enabled on the router between .2.x and .3.x subnets?

Do you have the dhcp option 66 and 67 filled out for both subnets?

@thecount1829 Well I don’t see this as a total waste of time. Mainly because you now know more than you did this AM. You also learned how to debug pxe booting issues. Knowing where to look is the key.

As I tell the youngins I mentor, “If it would have worked the first time, what would you have learned?”. Its all good here. In the end you solved the problem and can keep moving with your project. Well done!!

issue was with the actual ISO and is now resolved!

With easy mode vmware must tailor the VM config to match the settings on the install ISO. I have vmware workstation 15 on my office computer I’ll have to see if there is a way to tweak the VM this way.

@ricardomartins For updating to dev-branch you don’t need to reinstall. Just follow theses steps:

sudo -i git clone https://github.com/FOGproject/fogproject/ cd fogproject git checkout dev-branch cd bin ./installfog.sh

Here is the fix:
Try every boot file until you find the right one for you.

This is what I did as I ran out of options and it turned out to be good. Follow this tutorial: https://wiki.fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server under DNSMASQ settings for iPXE

I had a similar problem with DELL laptop GPT partition on M.2 .
After capture, i could not deploy it on other system/brand with different storage size (smaller that is).
My fix was :

resize the C : partion to space usage and reboot. recapture the image deploy the new image on the desired system/brand
🙂

@willingmost7 That’s just one way. There are lots of ways. This is pretty beyond my skill set. Luckily, @george1421 has done an excellent job producing this tutorial about the topic: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/8

I have done a fresh installation of ubuntu_20.04 and fog_1.5.9 on VirtualBox environment and works fine. Probably it’s a vmware issue or vmware config issue.

@tesparza Thanks a ton for your good will to help! Appreciate.

It’s a paid software. I need it to keep the students from destroying the computers.

I have found another thread talking about this RRRx software (which does the same so I don’t mind using it instead) and he fixed it by replacing the boot file, he used ipxe.kpxe instead of undionly.kkpxe.

And here is the proccess I made trying to figure out the problem: https://forums.fogproject.org/topic/15636/unable-to-boot-properly-after-radix-smartrecovery-installed/2?_=1628169887941

@tesparza Probably a database maintainace might help. Search the wiki or forums to find the instructions.

@esmatos Well the error is saying that the boot file needed is not found.

I can say that pfsense does work with fog. You need to make sure you fill out the Network Booting section properly.

Enabled: Checked
Next Server: (ip address of fog server)
Default BIOS: undionly.kpxe
UEFI 32 bit: i386/ipxe.efi
UEFI 64 bit: ipxe.efi

If that doesn’t work then lets grab a pcap of the pxe booting process as long as the FOG server and pxe booting client are on the same subnet you can use the FOG server to capture the pcap: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@astrugatch if this host isn’t already registered, this can be enabled globally, and likely won’t hurt anything even if it’s forgotten about.

FOG Configuration Page -> FOG Settings -> KERNEL ARGS add noapic

@sebastian-roth

Solved!!!

The error was in /etc/default/isc-dhcp-server.
It was set to eth0 instead of ens18

I have more problems. I will open new posts if necessary

Thank you for all!

I recently ran across this same issue, but it was not due to the fast spanning tree protocols. Our IT department added 802.1x authentication on the wired ports of all our switches, but the time out to fail back to MAC authentication was just longer than the 27 seconds @george1421 referenced in his post. We had a handful of hosts work, but a large majority failed. Our IT department had to shorten the 802.1X authentication timeout in order to make this work for us.