@tom-elliott Thanks Tom!

@sebastian-roth thx for the support!

@LittleTux Thanks for the feedback on this!

@ihcrcdan We eventually got it resolved. We had to remove 3 columns from the mysql.user table. Once that was done, I was able to update the password and the installer was able to complete. Just took us a while to find that information.

@george1421 Thank you again, that fixed it.

@sebastian-roth
It’s still working for me.

@george1421 I’ve actually managed to deploy this image to a range of different hardware without doing the sysprep, although I guess the fact that this thread exists might indicate that’s not the best idea… I would very much be interested in the guide you mentioned, I think next time I’m in the office I’ll have to seriously look into doing it through vmware/vbox.

Figured it out. The old database was using the wrong bzImage file. Thank you again for all the help.

@cedre2 said in Network Printer:

Fog client can’t read on a network share from a domain and install printers

Can’t you create a network share specific for these printer stuff that is free to access without username/password?! That way the SYSTEM account used by the fog-client run as a service will be able to access the files.

@sebastian-roth Thank you for your help. I just saw from a recent post exactly that, here.

@george1421 said in Make room on fog server's storage:

@sjensen If you delete the image from the image list (not from within the image definition) the deletion action will only remove the list entry and leave the raw files behind. If you go into the image record and delete the image from there, there is a checkbox to also remove the raw files (or something named similar). This will purge the files from the disk.

@JDnoble18 As George said, permissions look fine. Now that I think of it again I can imagine you ran into an issue where the installer would mess up with a link to the web root directory. Please run the following commands and post output here:

grep FOG_VERSION /var/www/html/fog/lib/fog/system.class.php grep FOG_VERSION /var/www/fog/lib/fog/system.class.php ls -al /var/www

I just tested kernel update on FOG 1.5.9.49 and it works as expected. So it does not seem to be a general issue.

@sebastian-roth Hey thanks a lot, it worked!

@george1421 Thanks for the help. I was also trying to use the username of “fog” instead of root at the server. That’s what I get for not knowing much about linux…lol

@george1421 said in Cannot boot hard drive from PXE menu:

@blankzapper booting you can hit F12 to pick the boot device?

No. Also there is no option to “Enable F12 Boot Menu”.

Something else to check, make sure that mobo is running the latest bios version. They might have corrected that behavior in a later firmware update.

It’s latest BIOS released 2014. Nothing newer. I am seeing if it possible to hack this AMI BIOS. I updated RealTek option ROM, to 2016 release, but it didn’t fix anything. I think UEFI network boot option must be added. I don’t know if this can be done without big changes (and likely bricked motherboard!)

@plegrand Which Linux OS and version do you use? Which FOG version do you run right now?

@david201 You might be better off getting this out of Docker. Here are steps on how to migrate FOG. If you have the right switches enabled in the hosting OS, you should be able to mount NFS inside of the container. Otherwise, there are other ways to get the images & things out.
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

Cool! I didn’t know that option was there. Thanks.

@Hope1983 From the fog.log:

25.11.2020 16:31 Middleware::Response Invalid security token

That means the tokens used to encrypt the connection are not ok anymore. This happens over time or when changing hostnames for example. Go to the FOG web UI -> edit the settings of the host you got this log file from and click the big orange button named “Reset Encryption Data”. If you want to do this for several hosts in one fo you can create a group, put them all in and then go to the group settings and click “Reset Encryption Data” there.

For the database you want to take a look at the credentials stored in /var/www/html/fog/lib/fog/config.class.php. Though I would imagine it’s user “root” with an empty password which was still used in FOG 1.5.5.

Ok, after lots of digging in the code and @JJ-Fullmer database we seem to have found out what happend. Turned out some of his PowerShell code messed things up by deleting the primary MAC address of some hosts and the fog-client did its share to kind of reset some of the hosts’ information and make them pending.

The PowerShell code is fixed already and I will work on adding some checks to hopefully not mess as much up with the fog-client as we did here.

Initially we thought the snapin hash problems were at fault but the evidence collected points to this being a coincidence.

@sebastian-roth IT WORKS !!!

I had to put right for “service local” and “system” on share access AND on security files.
share.png Folder.png

Thank you very much ! And sorry for my bad english 🙂
Thank you again !!!