@george1421 said in Broken iPXE boot loader:

@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).

This is the first post I found searching autoexec.ipxe so replying here for future searchers.

This was an addition in a recent ipxe version, and is meant to be a way to add ipxe based functionality without needing to recompile ipxe in order to edit an embedded script (https://github.com/ipxe/ipxe/discussions/1237#discussioncomment-9847219), I can’t find the post/doc again but I remember reading in one place that ipxe added it as part of the hopes of getting a signed ipxe shim so users could use the signed shim and then use this script to add what they can’t embed. While technically we can create a blank file in /tftpboot/ i.e. just

#!ipxe

which will remove the error during boot, this can then cause kernel panics when loading into FOS. Why it does this is a bit of a mystery at the moment, maybe it’s adding to or replacing another part of our pxe menu scripts that causes something in loading the kernels to lose access to ramdisk drivers. But adding it can break everything, so for the time being, just ignore the error.

I was unable to resolve this issue with pnputil using a cmd.exe script.

I noticed that the problem was also present on another FOG installation managed by other system administrators.

I assume (perhaps wrongly) that the problem is linked to an ANSI/UTF encoding issue. If someone using another language manages to run pnputil.exe in a cmd.exe script, report it here.

I was finally able to resolve this driver deployment issue using powershell. I’m leaving a sample code (install of a driver named usbblstr.inf) in case it helps someone.

New-Item -Path "c:\" -Name "drivers" -ItemType "directory" -Force Copy-Item -Path "usb-blaster" -Destination "C:\drivers" -Recurse Start-Process -FilePath "pnputil.exe" -ArgumentList "/add-driver C:\drivers\usb-blaster\usbblstr.inf /subdirs /install" -RedirectStandardOutput "$env:tmp\usb-blaster-install.txt" -RedirectStandardError "$env:tmp\usb-blaster-err.txt"

Sincerely,

Julien

Just checking in here to Mark this as SOLVED. I had added the dev branch under a different folder. So the mix up was between the chair and the keyboard. Performed @Tom-Elliott Recommendations and reinstalled from my primary install and it is now working. trying to pxe boot MacBookPro’s. That’s another story, for another thread.

@Tom-Elliott Thank you Tom. I change the UUID’s by the devices names on the /etc/fstab on the “golden” machine before I capture a new image and I redeploy it, but apparently it doesn’t change anything

ok, got it.

My storage pool had the other IP address, once I changed the IP of the storage pool to same subnet has the machine I am trying to clone, it went smoothly.

It is now copying at 257MB/min… is that good ?

@george1421 Gotcha. Thanks for the reply. I’ll post a picture of the error when I’m able to get back to testing next week.

@Tom-Elliott

Yeah, this was my suspicion. I see both sides of it too. Sounds like I’ll have to either super simplify some of my install scripts and make some sacrifices or figure out another solution.

I appriciate the response and confirmation!

@george1421 Hi,

Thanks for your reply. Its strange. I am working with (almost exclusively) early 2012 hardware. My older Imacs 2009-2011 afaict pxe boot fine image with FOG w/o issue. The problem comes along when, I try to image our macbooks. They display different levels of progress before they flat out hang. I had one mbpx,y I’m almost sure it was a 3rd gen intel just can’t find it right now. I may be being processed to go out the door to our clients.

Yes the 2019 verison of ipxe was executed from a boot of clonezill 3.1.x the version I would attempt to boot from ventory stick or from an imaged usb stick would display an error regarding not having efi capability and/or hang or return to the ventoy menu. If I just let them be long enough the MBP would just restart.

So I did attempted to roll my own and ran into the same problem with the oobox downloadable iso/zip file. Hang… I am researching w/o much success with how clonezilla compiled their ipxe menu entry or how to just plain add efi capability to ipxe.iso/zip and burn it to a usb stick. I just am not knowledable enough to formulate a good question or find what I am looking for (cause I don’t know:))

So thanks again for your reply. I have a large donations of older MBP’s coming just before the holidays and I would lik to be able to make it rain.

Regards,

@azm9s
In general, it didn’t work.
it doesn’t add it to the domain, that’s all.
Either I did something wrong.
or I have configured something wrong in the settings.

Hello, it looks something is wrong with you backend.
Are you able to open from the browser:

http://192.168.1.22/fog/service/ipxe/boot.php http://192.168.1.22/fog/service/ipxe/bzImage

?

@george1421 No luck, could you please have a remote session at your convenient time?

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.

@kentasmith Try changing your DHCP option 67 to another one of the boot files available (link below). We had this error and this resolved it. Think changing it to ipxe.kpxe instead of undionly.kpxe helped.

https://docs.fogproject.org/en/latest/installation/network-setup/dhcp-server-settings/#option-67

Hey @george1421 , Thanks for the quick reply, sorry for the missing details.

What device is your dhcp server? (manufacturer and version)

DHCP (and DNS) is running on an Active Directory 10.0.20348.1668, Windows Server 2022 Standard

Is it on the same subnet as the FOG server? You mentioned the VM and FOG server was on the same subnet.

This applies to any machine I’ve tried to deploy to from fog, for example fog is on subnet 100, unless the target of the deploy is specifically on subnet 101 it will fail to boot into the PXE server. Even with a Workstation/VM on subnet 100 (exactly the same subnet as the fog server) it will without fail time out this will happen on any subnet other than 101. In our case VLANs will correspond to Subnets.

Any machine on the 101 subnet can pxe boot to fog to capture and deploy with no issue with both UEFI and BIOS.

What hypervisor are you using?

We have found that we will see this issue whether on a VM or a Workstation so this isn’t limited to the hypervisor in question.

I assume when you say “run PXE” you are saying you are trying to pxe boot the VM?

Yes, correct.

Is the VM in bios or uefi mode?

We have tried both with the same result for either.

What specifically do you have defined for dhcp option 66 and 67?

For the two DHCP Policies we have in place for fog we have the following options set for 66d and 67:

FOG snponly.efi policy
66: 10.2.100.103 (IP address of our fog server)
67: snponly.efi

FOG ipxe.efi
66: 10.2.100.103 (IP address of our fog server)
67: ipxe.efi

@luilly23 thanks for the reply. It was a working script before and I had updated it to comment areas and operations recently and added regions within the powershell script. There were no reboot options that I can remember (fairly sure) inline in the script but will double check.

There was a reboot option on the snapin itself.

Is there any log of the fog client to server comms that could say “this caused the reboot” or just more detail. I was thinking of turning the reboot off of the snapin properties to see if it would progress.