@brakcounty Sure thing you need to tell curl/wget to ignore/accept the non-official certificate: wget --no-check-certificate ... or curl -k ...

@Jim-Holcomb Hi Jim, you might need to give us some more information on what exactly is not working. Error messages? What is happening with the two disks and what’s your expectation.

As well we need to know the version of FOG you are using.

The more details we have the better we can help you.

@Floppyrub What you are referring to with group64 is just a variable used when doing a (full/manual) registration of a machine (code ref). This is not available in the postdownload script.

I don’t think the group information is available as of now. But that doesn’t mean it cannot be done. If you are keen to add the feature you are welcome to.

@Jordane Looks like the fog-client doesn’t use FIPS complient crypto but your system enforces this security standard: https://learn.microsoft.com/en-us/troubleshoot/system-center/orchestrator/exception-error-install-sma-web-service

Though it might also just be a question of libraries being FIPS certified or not: https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/retargeting/4.7.2-4.8#managed-cryptography-classes-do-not-throw-a-cryptographyexception-in-fips-mode

The fog-client currently uses Rijndael(Managed class) and I guess we would need to switch to AES:
https://learn.microsoft.com/en-us/archive/blogs/shawnfa/the-differences-between-rijndael-and-aes
https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.rijndaelmanaged?view=net-7.0

Possibly we cannot give you a quick solution or workaround on this. Maybe it’s a minor step to switch to a Aes class but I am not sure yet.

And then there might be a second issue as well. The error mentioned in the first code block (System.UnauthorizedAccessException: L'accès à la clé de Registre '230' est refusé.) points to registry access being blocked. Maybe this is caused by some kind of anti virus software?

@tag Thanks, will look into it.

@lostitguy From what you describe it’s iPXE pulling the wrong MAC address. To get this fixed you’d need to contact those people: https://ipxe.org/contact

The quick workaround you can take is booting this particular machines via USB: https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

We have new information from @rodluz about different MySQL versions:

• Ubuntu 18.04.2 - FOG 1.5.9.94 - MySQL 5.7.39 - Plugin works
• Ubuntu 20.04.1 - FOG 1.5.9 - MySQL 10.3.34 - Plugin works
• Ubuntu 22.04.1 - FOG 1.5.9.235 - MySQL 10.6.11 - Plugin does not work

Could be a bug reported - though people on stackoverflow state they cannot replicate the issue as described - maybe interesting to give it a try.

Here I found another official bug report on triggers. But this seems to crash the DB and I don’t think we are running into that.

@Jasper507446 Thanks for the update. Guess we had the same reported here as well: https://forums.fogproject.org/topic/16555/schedule-tasks-not-repeating

Can you please post the full contents of the log file /opt/fog/log/fogscheduler.log?

Thanks to @Tom-Elliott for taking a look at this. So far it doesn’t look like a simple PHP (8) issue. We need to further dig into it. Will do a remote session with @rodluz.

@dyacishyn said in Unable to access FOG management web site:

Unable to load dynamic library ‘pdo_mysql.so’ …

Please run the following commands (as root!):

apt --purge remove php-common
apt install php-common php-mysql php-cli

This has been discussed on github a while ago. I still have no idea how this can happen: https://github.com/FOGProject/fogproject/issues/525#issuecomment-1358575774

May I please ask you to upload the full installer logs to the forums? You find those in the subdirectory where you tun the installer script (fogproject/bin/error_logs/).

@dyacishyn Please post what you find in the mentioned logs. If I had to guess I would think you did not install the latest dev-branch but an earlier version that is lacking PHP 8 support. But I might be wrong.

@danieln said in Cannot delete image off of all nodes. Type 2 FTP Error...:

If I wanted to do this, would I just delete the entire directory? Or would I just delete the d1p1.img file? I feel like the entire directory, right?

Yes, delete the whole directory.

Speaking of, is doing an update just running the following commands?:
cd /fogproject
git checkout dev-branch
git pull
sudo ./installfog.sh

As I said, there is a new official release in the pipeline and you could install that if you feel like it. Instead of dev-branch use master instead in the above command sequence.

Is there anything else to it? Aside from backing up the FOG database?

If you have FOG running in a virtualized environment I would also take a snapshot just to be sure. As always, backing up the DB is advised.

@ClementK Well done! We shall add this to the docs!

@brakcounty So we still need to figure out why the browser gets a quick response while iPXE does not?! Probably using tcpdump/wireshark as mentioned or even better asking your network team to look into it.

You can to more tests as well, either download wget or curl for windows to test. Or you can boot up a Linux live OS CD to do the same testing.

@dyacishyn Which Linux OS and FOG version did you Run before updating? Please post what you find in the Apache and PHP logs (see my signature) as well as the output from running the command dpkg -l | grep php on your FOG server console (e.g. via SSH).

@H3Krn Thanks for checking up in this. I’ve got it on my list but don’t seem to find the time.

@rodluz Do you want to take a look at this?

@danieln said in Cannot delete image off of all nodes. Type 2 FTP Error...:

If I absolutely have to delete an image directory off of the nodes, would manually doing it have the same effect? Or does it have to run through the Master and FTP to do it correctly?

Well If image replication is working then images should be copied from master to the storages. Manually deleting an image from a storage node would simply trigger for it to be copied again. But if you manually delete it from the master (can do via FTP but also directly in the server using plain rm - rf ...) it should vanish on all the storage nodes on the next replication loop as well.

If you want to find out where the FTP error comes from you can enable detailed FTP logging (search the forums for vsftpd logging I think) or use tcpdump/wireshark to analyse the actual FTP traffic.

In any case I highly recommend you update your whole FOG install (all nodes) as soon as the current imaging workload slows down. By then a new official release will be out as well.

@quinniedid said in Feature request for FOG 1.6.x - Configure image capture to use NFSv4 instead of NFSv3:

I have been tasked with having to completely rebuild FOG on a new OS.

Well that’s interesting. Why a new OS? Based on what software stack? Or did I just read this the wrong way and you simply meant adding NFSv4 support?

@ClementK said in Dual boot (2 disks) unable to boot grub:

Maybe I need to run a postinstall script to update the UEFI boot entries?

Exactly. Look into using the efibootmgr tool.

@Hope1983 So from the output it looks like this is actually a docker container. I have not used docker much myself, guess others need to help on this.