@sapeurorca Try to reset encryption for that host, try to re-install the fog client on that host.

@Tom-Elliott Store them in the database and have a daily cron job that cleans out logs older than N days (user defined). If FOG were to switch to MariaDB 10.3, the TokuDB engine would be available for use. TokuDB has in-engine compression. The compression savings is pretty staggering compared to InnoDB. TokuDB does not support foreign constraints - and because the FOG db doesn’t use them, we are A-OK there.

@george1421 said in Bulk editing hosts:

If you are going to mass update the database like this, stop apache and php-fpm first, then run your update, and finally restart php-fpm and then apache. Both php-fpm and apache cache database values for faster access. You are changing the underlying database but its not seen in the UI because of the cache.

#wiki worthy.

I have tests that automatically test Ubuntu 18.04 automatically every day. Links in my signature.
I’ve been told by @Sebastian-Roth that there is a big repository difference between Ubuntu 18.04 LIVE and non-live, namely the universe repository is present in one, missing in another.

@andreiv Have you seen this article yet? https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Downloading_-_Multicast

Just adding a note here. Typically when the TFTP server address is requested at a prompt, this in the past has several times been due to multiple DHCP servers replying with different option 066 addresses. Typically, a rogue DHCP server or two redundant DHCP servers that are simply mis-configured.

@Boyan-Biandov said in upgraded to Ubuntu 18.04.1 LTS:

Is it really necessary to copy the images to a folder, other than /images on the new fog server and then once they are copied there “rearrange” them by moving them again into the final destination of /images (assuming fog defaults)?

Yes, because FOG’s NFS configuration does not allow writing to /images, it’s a read-only share. /images/dev is read+write. I kept the walkthrough as simple as possible, leveraging things already setup on the servers. If you wanted to use something like SCP, you could put the images directly where they need to go.

@bsalogga This article was made for you: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

You could also disable the nodes you want to delay replication for via Storage Management.

@Sebastian-Roth is right, the logs will tell us more. Also, Tom did fix the issue of the replication sleep cycle maybe two years ago. if lftp processes are still running, no more get started. They have timeouts so no fears of infinite hanging processes.

Also I’m just going to say that most replication issues I’ve seen people have are normally due to configuration problems. Like a bad fogstorage username & pass, or MySQL remote access being disabled, or firewall on the OS blocking the needed ports, or bad FTP username/pass for the storage node.