I am presently CentOS 7.7 (with plans once the repos catch up to migrate this to CentOS 8).
Remi Repo
(yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm)
I enable the 7.4 distribution in /etc/yum.repos.d/remi-php74.repo
I’ve installed this on a dozen or so servers, none of which depend highly on PHP (fog obviously does) without issue. However with all the deprecation going on/off in PHP - I do worry.
Does the current FOG server run without modification with the new PHP 7.4 distrobution?
@Tom-Elliott
Tom - I have been updating FOG on a regular basis and never changed the encrypted string to clear text and it always worked. Was an encrypted string “semi-supported” for some time after the commit? Did a recent update nullify that? Curious minds want to know.
-rw-r–r-- 1 fogproject apache 205192 Oct 28 10:49 refind.efi
I don’t know how to retrieve the version.
When I use the above version, everything exits properly (we are 100% UEFI /netboot IPv4 with Legacy Disabled). When it boots from disk the “blue line” atop the screen appears, some misc text and then windows boots from disk. When I use any other version the “blue line” appears and then it hangs - has a message with respect to initializing/loading then hangs.
Every reinstallation of FOG (updates. etc…) seems to remove the service/ipxe directory and reinstall all components. It always fails to boot the PC correctly so I copy the above version and it works again.
@george1421 I heard the same information. A windows update caused FOGService issues. I have not seen a new Fog Client however.
@DeRo93 said in HP Elitebook 840 G6 - UEFI PXE Boot not working.:
Elitebook
Same network segment for both PCs ?
I had an issue with UEFI with non-standard netmasking and after weeks of messing around with it learned that the I needed to have the broadcast address of 255.255.255.255 instead of the what should have worked (only on the router - router was a Cisco). Basically I use to hardwire in the correct broadcast address on the appropriate Cisco interface, I took that out (let the Cisco set up the default) and it worked… Don’t ask me why, it was “legal” from a networking perspective.
@Daniel-Miller Nope, once FOG Service stopped, it discontinued any logging. On the windows log side can’t find a thing. sc query and sc qc all look good as it is running now.
I get no indication that service crashed - basically something didn’t work (fog based printer creation for example) then I manually look around and need to restart the service (and printer gets created).
I’ve also noticed that if I am creating a lot of printers on a host (10 or more let’s say) it gets partially through then dies. I start up FOGService again and it completes.
Wish I had more data to go through.
Fog Version 1.5.7.49
Windows 10 Enterprise version 1903
FOG Client version v0.11.16
Installed using “Smart Installer”
Client installed as a component of the image (before the image capture)
Yes followed all Sysprep instructions.
Tail end of fog.log below:
11/7/2019 10:39 AM Service Sleeping for 101 seconds
11/7/2019 10:40 AM Middleware::Communication URL: http://fog.mscs.mu.edu/fog/management/index.php?sub=requestClientInfo&configure&newService&json
11/7/2019 10:40 AM Middleware::Response Success
11/7/2019 10:40 AM Middleware::Communication URL: http://fog.mscs.mu.edu/fog/management/index.php?sub=requestClientInfo&mac=3C:52:82:76:63:BB|00:50:56:C0:00:01|00:50:56:C0:00:08|02:50:41:00:00:01&newService&json
11/7/2019 10:40 AM Middleware::Response Success
11/7/2019 10:40 AM Middleware::Communication URL: http://fog.mscs.mu.edu/fog/service/getversion.php?clientver&newService&json
11/7/2019 10:40 AM Middleware::Communication URL: http://fog.mscs.mu.edu/fog/service/getversion.php?newService&json
11/7/2019 10:40 AM Service Creating user agent cache
11/7/2019 10:40 AM Middleware::Response Success
11/7/2019 10:40 AM Middleware::Response Success
11/7/2019 10:40 AM Middleware::Response Module is disabled globally on the FOG server
11/7/2019 10:41 AM Service Sleeping for 137 seconds
Only one version of rEFId works for me, all subsequent installs simply hand and fail. I’ve gotten myself to the point where I simply save all my *.efi from the ipxe directory then copy back after a new installation fails to correct the issue.
I am 100% HP clients and this behaviors is identical between various generations (G2-G6 all seem to want this old version to boot).
Any way to:
1: Have a working version
2: If not #1 - at least preserve old *.efi files
3: Is there a magic refind.conf parameter I need to set?
?
Thanks for clarifying - when did this change happen? Spoke with Sebastian weeks ago and he was volunteering to debug (leads me to believe this change was not well known).
I use “technicians” to help me deploy (students) and they are not normally given this credential as it could create a security concern. Masking this would work and this should be reflected in the FOG Settings and the Active Directory Setting for the individual clients/groups.
Can we clean up the “Host module setting” and rid ourselves of the “old client” configuration/setting choices? I’ve been on the new client for untold years and I can’t imagine that anyone else has “old client” support issues/concerns. That being said all options with the old client are “grayed out” except the “Client Updater”. Which has a check box even though I am on the new client and it claims this only reflects on the old client.
Just thought a little cleanup would be an easy fix.
I am deploying a recent version of Windows 10 via my fog-server. The FOG Client seems “broke” as it runs for a while and then dies. I have set the FOGService to restart/restart/restart and it does not help to keep the service alive.
Granted, Windows 10 is a likely culprit, however I am guessing this is also them most common deployment and this needs to work flawlessly. I’ve found myself having to login (sometimes more than once) to restart this service. Someone please fix this.
I’m on the dev-branch running the most recent updates. CentOS 7.7 (latest 7.X release) MariaDB (10.2.27) and PHP version 7.3.11.
In recent months (I haven’t imaged much lately) my clients stop joining their AD domain (I got a an error in FOG.log [Fog.log says unknown username or bad password, code = 1326]) even though I know this to have not changed. I recreated the client from scratch and it failed, tried this on various PC generations and it also failed.
I went to FOG Settings > Active Directory Defaults and re-entered all information. The AD DEFAULT PASSWORD fails to encrypt and continues to store this in plain text. I can now join the domain, however I am extremely uncomfortable with this.
Am I doing something wrong? Do I need to do something to encrypt this manually? The notes on the UI indicate this should be automatic.