Broken iPXE boot loader
-
@JYost If your’e asking about the not found autoexec.ipxe that shouldn’t matter as it is just a means to use local files to autoexec ipxe items.
Effectively “autoexec.ipxe… Not found” is not an error message that is preventing booting in and of itself.
I suspect, possibly, that it is where your ipxe is failing to continue, but that seems more like when you compiled you forgot to include the embed script that (once autoexec.ipxe is not found) tells ipxe what to do.
-
I’ve downloaded the file ipxescript.txt file - Does the extension needs to be renamed to something else as it’s a script (i.e. .sh (bash??)? Also, what directory do I place the script in? (Sorry for the ignorance…I’m not a Linux guru)
Thanks again guys!
-
Hi, I have the same error, but I had git version, I did upgrade IPXE as is needed for our new Laptops, then I did rerun installation of Fog. I used install file from past the same as the fog we are having 1.5.10. It all looked fine, but the error is the same. Should I used new version of Fog over this one?
-
@Mightmar Just a few points of info to give you.
- iPXE is managed by a different project than the FOG Project. They have a quicker release cycle than the FOG Project so they will/may support newer hardware quicker.
- When a specific version of FOG is released it contains the current version of iPXE at the time a specific version of FOG is released.
- If you manually update iPXE using the following instructions: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe and then reinstall FOG 1.5.10 it will replace the updated version of iPXE created by the previous script with the version shipped with FOG 1.5.10. This is by design in case you make a change that breaks FOG you can always fix it by rerunning the FOG installer putting back the FOG files to a known good state.
So to say it another way, if you find issues with iPXE not supporting certain hardware, I would always upgrade the version of iPXE first and just remember that if you reinstall FOG it will replace the updated versions of iPXE and the FOS Linux kernel with the ones that were shipped with the current release of FOG. While I don’t know what the current release of FOG is I believe there are sub release later that 1.5.10 that fix a few discovered issues.
-
@george1421 Thank you for your response, so with this newest laptops (HP Elitebook 640 g11) I need to update IPXE with the newest IPXE version and do the “hacker way” - The hacker way to update your production environment is to copy over the updates files to the /tftpboot directory with this command cp -R /root/fogproject/packages/tftp/ /tftpboot
Note: watch the source path if your git fogproject directory is not in the /root/fogproject directory*
cause re-running for installation bring me back to start.
What if I use new version of fog Installer over my 1.5.10 now, it will break? -
@george1421 I did the “hacker way” yet there is still the error while booting the laptop
autoexec.ipxe… Not found (https://ipxe.org/2d12618e) -
@Mightmar I wonder if the devs for iPXE has changed something in the ipxe source code to cause this error message about autoexec.ipxe not found. This should be supplied by the fog project add on files. I’ll take a look at the compiler to see if something has changed. You should not see this error.
Reinstalling 1.5.10 will fix the error of the latest build of iPXE. Also you mentioned about a later version of FOG. Yes you can install that over 1.5.10 without issue. It should also have updated (but not the newest version of iPXE).
-
@george1421 I wonder now if upgrading the present version (1.5.10) to the newest, 1.5.10.1629, will fix it for these fresh laptops, even though I already have the newest IPXE version 1.21.1+.
Can I return to the previous version if something fails with running an old fog installer?
Is change from ipxe.efi to snp.efi or snponly.efi could help?
-
So I solved it by changing DHCP Option to snponly.efi. Now new laptop is installing, not sure if updating IPXE was required, but works now.
-
@Mightmar Ahh , so you’ve hit a problem we see occasionally.
SNP SNPonly files, are effectively using the onboard information to drive network connectivity in the PXE environment. ipxe.efi attempts to match the device to a specific driver (usually for better performance/speed/accuracy of information)
As you might imagine, if the driver isn’t matched or not fully fleshed out, the NIC may not operate or hand off accordingly.
I think you’re right that updating the information wouldn’t have necessarily been required, but also probably wouldn’t hurt anything either (or at least shouldn’t.)