Hi @Tom-Elliott. Do you know which settings do I need to change so outgoing email is not coming from Apache?
I changed the outgoing email for FROM EMAIL and EMAIL BINARY in the web UI to donotreply@mydomain.com. Notification email went out as apache@myfogserver.localdomain. I then set myorigin = mydomain.com in main.cf, I received the notification from donotreply@mydomain.com which looks correct but according to maillog, and full header of the email, the email was sent from apache@mydomain.com.

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

@NoIPName

Hey !

like @Tom-Elliott says , 1.5.10-x is the good way but if your problem is still present so i would ask you this :

from Fog GUI could you export in CSV your actual hosts list ? could you add in this CSV a new line changing the hostname and mac values could you clean all your hosts from Fog GUI could you import the CSV that you exported

is it working ?

@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

@rogalskij said in OS Details no longer working:

For those experiencing the same issue on mainstream linux distros, navigate to your “resolv.conf” config file located in /etc/resolv.conf and add your individual search domains. Test a ping to a DNS name via command line on the box itself, then check your GUI again. Took about 2 minutes for it to reflect and show for me.

I’ve just done this, and now noticing a remarkable increase in performance of the 1.6 web page. Thank you!

First of all, sorry for resurrecting this old thread. However … I was experiencing this issue with HP machines with BIOS U62 Ver.01.01.21 07/01/2024.

The only way I was able to workaround the issue is by using refind binaries from FOG 1.5.5 as @PeterL says in their answer:

@PeterL said in REFInd-Initializing - hangs:

Your issue with rEFInd is because of HPs EFI.
I have exactly the same issue with ProDesk 400 for quite some time.
The workaround to get those systems booting via rEFInd was a downgrade of the rEFInd binaries.

For me a downgrade to rEFInd out of the FOG 1.5.5 package did the trick.

FOG 1.5.5

Path in the ZIP archive: fogproject-1.5.5.zip\fogproject-1.5.5\packages\web\service\ipxe\refind.efi

The binary is dated 15.11.2018

On a Debian system place the file in /var/www/html/fog/service/ipxe
Once as “refind.efi” and a second time as “refind_x64.efi”.

But I’ve tried with latest rEFInd version from sourceforge as @george1421 points in their answer

@george1421 said in REFInd-Initializing - hangs:

@peterl FWIW the refind files can be located here: https://sourceforge.net/projects/refind/files/

For a very log time FOG shipped with 0.11.0 version of refind. This was a very stable, but old release. Based on the image date you referenced that must be the 0.11.4 release of refind. You might also want to try 0.13.2 (newest at the time of writing). To see if the very latest version of refind works for you.

but even this latest version isn’t able to boot the EFI partition from the internal disk. So weird, not sure how may I help to diagnose this issue for rEFInd project … but I’d like to help. Can’t find a way to increase verbosity for rEFInd despite I’ve tried some config directives in refind.conf

Thank you for this helpful post guys 😛

@aurfalien I’m sorry, I am generally working in working-1.6 and even there I was mistaken.

The file you’re looking for is likely /var/www/fog/lib/fog/host.class.php.

It follows similar rules though the line you’d want changed would be at 2199 I think.

Hopefully this helps?

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

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

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

Version 1.5.10.1629
Environment - Dell Poweredge server running Alma Linux 9.5

Not to dredge up an old forum post, but I experienced this same error after migrating from an old CentOS server to newer hardware and Alma Linux. (What apparently many are moving to now).

For me the issue seemed to be related to trying to pull an image from a laptop that had the previous client on it. I have 2 computers that I use as dedicated imaging devices, 1 laptop and 1 desktop. I uninstalled the old FOG client, but when installing the new client and attempting to point it to the server, I got the CA Certificate error mentioned on the “Pinning” stage of the install. I tried to find an old cert on the device itself, with no luck.

What I ended up attempting after doing a little digging was to add back the following Windows firewall rules. I did that, and it seemed to kick over immediately and installed on the very next try. I am unsure if this is coincidence or if the firewall rules truly needed to be on the device before installing. But it worked after that and I now have a successfully pulled base image like I utilized on the previous server. The rules I used in an elevated command prompt are below. Perhaps someone from the FOG community can comment on the accuracy of my firewall rules? Good luck and hope this helps someone in need!

netsh advfirewall firewall add rule name=“Fog Client” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGService.exe”
netsh advfirewall firewall add rule name=“Fog Shutdown” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGShutdownGUI.exe”
netsh advfirewall firewall add rule name=“Fog Tray” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGTray.exe”
netsh advfirewall firewall add rule name=“Fog Update Helper” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGUpdateHelper.exe”
netsh advfirewall firewall add rule name=“Fog Update Waiter” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGUpdateWaiter.exe”
netsh advfirewall firewall add rule name=“Fog User Service” dir=in action=allow program=“%ProgramFiles(x86)%\FOG\FOGUserService.exe”

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

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

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 We have to be careful some Soho routersthe don’t behave well with pxe booting. Some will put its IP address as the boot server even if you have dhcp option 66 configured. I don’t know the edgerouter, but if there is a bootp option make sure that is turned on too.

The edgerouter is based on vyos so it should behave correctly. Make sure when you define dhcp option 66 its the IP address of the fog server and for dhcp option 67 the boot file name needs to be all lower case. Make sure you don’t have a leading or trailing white space in the name.

If you have double checked everything then get a witness computer and load wireshark on it. Make sure you setup a capture filter of port 67 or port 68 start the scanning then pxe boot the computer until you get the error message then stop scanning.

What you are looking for is the DORA sequence
Discover (sent by target computer, akin to hello world, please configure me)
Offer (sent by one or more dhcp server, I would there to be only one of these and from your edgerouter).
Request (sent by the target computer)
Ack/Nack (sent by the dhcp server)

The interesting packet will be the OFFER.

Look at the packet, there should be an ethernet header section with the following fields.
Next-Server: this should be the IP address of your fog server (this is the bootp part)
Boot-FIle: this should be the name of the ipxe file to load.

If either of those are blank some pxe clients will not boot if they look at the bootp fields.

In the dhcp options section you should see option 66 and 67 that should mirror the values in the bootp part.

@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