@robertkwild ok i read you can do 10 or other so fine, il close

FOG iPXE meu is doing cert validation check at some point. Where would I need to change so it can verify my cert?
I’m on Rhel 9 running apache 2.4. No error on any of the log file.

Please help!!!

@Tom-Elliott I have tried what you said without success. I still get the TFTP error

@Tom-Elliott
The last problem was tha windows main partition ! Now it works perfectly ! Thx for your precious help.

Solved 🙂

@rodluz

@Erika said in Issue : EFI Stub: initrd data into pcr 9:

@rodluz said in Issue : EFI Stub: initrd data into pcr 9:

@Erika I would like to try the newer 6.12 kernel to see if this issue would get resolved. I will have a kernel for you to try later today.

My colleague and I tried this morning,
It doesn’t work.

bzimage 6.12.png
6.12.png

efi stub: loaded initrd from linux_efi_initrd_media_guid device path
measured initrd data into pcr 9

Does’nt works on this video : (hosted 2 day)
https://streamable.com/dlqhin

When it works normally, it should go to this step as in the video :
https://streamable.com/esg8f0

@AUTH-IT-Center Hi thanks for the reply.

Yes I’ve read that link, my problem is that I’ve done the password migrations “backwards” - ie I’ve copied the passwords from the database to .fogsettings instead of the other way around as specified on that link.

@alexamore90 Lets try to unpack this.

You have 3 ESXi servers connected to an unmanaged switch.

This part is a bit unclear. After deploying on a few pcs the speed dropps to 900mb/min (watch your unit of measure). Normally its up to 22GB/min (again assuming you are getting this number from partclone).

After deploying to a few PCs the speed drops. Is this simultaneous deployments or consecutive deployments the speed drops?

Unmanaged switch: So this isn’t an enterprise class switch. You may have issues with throughput on the switch itself. The aciscs might not be fast enough for the amount of data your are trying to push through. Look at the throughput listed in the technical documentation for the switch.

You didn’t mention the uplink speed from the ESXi servers to this switch. On a well managed 1GbE network you should get around 6GB/min throughput. On a well managed 10GbE network I’ve seen 13-15GB/min. So your 22GB/min seems a bit higher than expected. I can say with a physical FOG server connected via 1GbE link, I can saturate that 1GbE link with 3 concurrent image deployments. When that happens the error rate increases and the throughput drops off quote a bit.

The other thing if you are trying to do concurrent deployments with these 3 FOG servers, make sure the drives on ESXi are SSD or NVME drives and not spinning disks for performance reasons.

In the end I don’t think this is a FOG server issue specifically, rather something in the environment that is causing the speed issue.

@wilsol you’re downgrading the kernel version, not FOG. These versions exist and while generally having the bleeding edge is fine, sometimes the bleeding edge is … well… problematic. Will there be a fix? Most likely, when we know exactly what’s causing and can produce a patch, notify the kernel development team what we find, or disable the offending piece once we know what it is and what (if any) it impacts by being disabled. Until then, using the slightly older version is the workaround/fix.

@Tom-Elliott

Ok thanks @Tom-Elliott - that helped me. I had a script that was failing and trying to find logs for it was difficult to get a location that it could write to, that I could find after the deployment, and i couldn’t see if it was erroring or whatever… running in deploy debug was really helpful. Thanks.

@ALV_SUPECOLES This seems to be similar to this thread: https://forums.fogproject.org/topic/17759/ipxe-initialising-devices

In this case uefi firmware was updated then iPXE stops at initializing devices. If compiling and installing the latest version of iPXE doesn’t solve the problem then we will have to wait for either iPXE developers or Lenovo to fix the problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@nicolas-moraes I managed to solve it and in my case it was not a FOG or network issue. I verified that DHCP was working correctly (confirmed with tcpdump), options 66/67 were unchanged, TFTP was running, and the FOG web/ipxe boot.php were reachable.

The key test was that when the client stayed at “Start PXE over IPv4”, the FOG server was not receiving any DHCP or TFTP requests at all, which pointed to a client-side problem. Even though Secure Boot and Fast Boot were already disabled, the issue was caused by the BIOS state.

After restoring BIOS defaults on the HP laptop and re-enabling PXE IPv4 boot, everything started working again. It seems some UEFI/PXE flags were stuck, and resetting the BIOS fixed it.

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