@wayne-workman Hey Wayne, you can forget this. I tinkered with it a bit (reentered in the credentials, changed the path a few times, etc) and for some reason, it started working on the SYSTEM user using psexec. After that, I tested as a snapin, and with the powershell template (powershell.exe -ExecutionPolicy Bypass -NoProfile -File xxxxx.ps1) it worked correctly.

@Sebastian-Roth Looks like i didn’t need to convert the root certificate, it was already in pem format. I ran the openssl verify command, and it returned an ‘OK’. I’ll insert that into the trust and recompile. I wont be able to test until tomorrow morning, so I’ll update you then. Thanks for all the help!

@Sebastian-Roth Hey Sebastian,

Quick note, I had to make an additional change to get mine to work. I’m using a custon wildcard certificate that doesn’t hold the IP of the computer as a DN. So when changing it to https, I got a “RemoteCertificateNameMismatch” error. I changed the php at that section to look like this, and use the hostname instead of the IP. Not sure if there should be a change to use the hostname instead of IP if specified in the .fogsettings file, or maybe you have a better way of doing this?

                $location = sprintf(
                    'https://fogserver.gvsu.edu/%s',
                    #$StorageNode->get('ip'),
                    $StorageNode->get('webroot')
                );

@sebastian-roth Yeah I can do that. Give me till next week, gotta get a few imaged while it’s up and running.

@sebastian-roth I was able to test on both an M83 and a 7010. I’ll be doing more widespread testing once we get back after the holidays, but everything seems to be fine!

@george1421 I’m working on getting an updated FOG server running using NFSv4 as well. I’ve just installed 1.5.10.10 on Ubuntu 22.04 LTS and have gone through the steps on configuring the OS and FOG for NFSv4. I’m a bit stumped on the FOS changes, so I tried using this kernel for the server. When trying to boot a client to the FOG server with a bootable USB, the client kernel panics. I’m assuming it’s because the kernel here is for a previous version of FOG. Any ideas?

@sebastian-roth I was able to test on both an M83 and a 7010. I’ll be doing more widespread testing once we get back after the holidays, but everything seems to be fine!

@sebastian-roth Back tracking on this a bit…

I was able to get it to work by following George’s instructions at the start of this thread, with making a USB the easy way (using the latest iPXE version directly on the USB drive). My other test this morning was using an older version of iPXE on the USB drive that then boots to the iPXE version on the server. That does mean though that their latest version fixed the issue, since I tried the easy method USB drive at the start of this thread with the same error. My thought is that it exits fine on the server, but then when it tries to exit the older iPXE version on the flash drive that it encounters the error.

@sebastian-roth

1. Yep, use the iPXE on USB to boot to the iPXE on the fogserver, then use that to chainload.

2. I think it’s the latest: g47098 matches the 47098 start of the commit id

@sebastian-roth Just reran the test with the latest ipxe version. Still has the same issue on a 7010.

@sebastian-roth As long as I can remember, I haven’t had an issue with iPXE on an EFI usb drive on an Optiplex 7010. I have had the issue where it gets stuck on “Initializing iPXE…” on 790s when using the EFI usb drive. I can’t speak to the built in iPXE booting on those machines since our network structure doesn’t allow for direct pxe booting.

@sebastian-roth Finished this. Ended up with “c70b3e04e86cefca335e36f883829d89583a6921 is the first bad commit”.

@sebastian-roth Can do. Feel free to post the instructions and I’ll get working.

@sebastian-roth Yeah I can do that. Give me till next week, gotta get a few imaged while it’s up and running.

@sebastian-roth That seems to have worked. Was able to boot to to a task on an Optiplex 7010. Will test on a few others tomorrow to be sure.