@Tom-Elliott Hellooooo,
Sooooo, leaving the UUIDs as is I simply decided to use a different machine to create the image. I was using Intel and switched to a SuperMicro and set BIOS booting option to BOTH meaning Legacy + UEFI.

That same image was successfully deployed to that very problem Intel box as well as others. And since it was EXT4, the partition grew and shrunk as needed.

@Tom-Elliott looks like i have to update my fog to 1.6 instead of 1.5 as i thought i resolved it by updating fog to the latest 1.5 but the error is still there on 1.5, i thought it went at first as when i made my first image it saved as a folder but on my second capture its saving as a file again

@Tom-Elliott Which information would help you to understand the problem more?

Secure Boot is disabled at the moment.

@Tom-Elliott i had the exact same error on another pc i wanted to image, you were right Tom, as the CMOS battery died it had the wrong date/time so i amde it correct and voila

thanks for pointing me in the right direction!!!

@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