I know I’ve been out of this for a little bit. I check in here or there, but just been extremely busy.

I don’t want to stop contributing, I just am taking time for myself after my workly duties.

I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

@Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
@george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
@Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

@everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

https://news.fogproject.org/fog-1-3-5-and-client-0-11-11-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-11/

TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

The quickest fix is to simply rerun the fog installer which should correct the problem.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

FOG is still actively being developed. It’s not necessarily readily apparent, but we can assure you things are still being worked on. These updates may not be communicated in a way that everybody just knows, but can easily be seen if one were to look at our repository site.

Between our own schedules and lives, we can get very busy. We try to keep things updated and help out on the forums even during lull periods. This might mean we aren’t pushing an RC or release as frequently. It may mean we’re working on other things for the project, such as can be seen if looking at our github site.

Our forums are heavily active, and this should point as an indicator to our “status” as well.

If anybody would like to see an increase in developers donating their time to making this free software, consider donating either with monetary support or by spending personal time to help with development.

FOG is an open source project - it’s even in the name. It is driven by people donating their time and resources. The releases of FOG revolve around when developers can spare a few hours throughout the week. Sometimes that will mean releases will be further, sometimes that will mean releases will be faster. That’s just the nature of our project, and many other open source projects.

Hey everybody,

I know you see me here on occasion from time to time. Life decisions have made it more difficult for me to do things I would normally be doing. Rest assured, I am still around, and while I’m not quite as active as I was in the past, it’s not because I don’t want to be.

I had to move, and as part of that I have none of my normal development stuff readily available. Part of the move made me not have a laptop, until today.

I need to setup my dev environment again, so it may take a little bit, but I will be back up.

https://news.fogproject.org/fog-1-5-10-41-officially-released/

While this maybe spur of the moment, it should officially release 1.5.10 with all relevant bug/security fixes encapsulated (among a few other features.)

This has brought a new methodology of releases in that bug/security releases should be done much more regularly.

dev-branch, historically, was a place where new development occurred (hence its name) but over the last couple of years or so it’s mainly been a bug/security thing, not really a true development approach.

This is OKAY, in my head. Why:

Well we have the master branch which is the ‘baseline’ of a verions. We have the dev-branch, which allows us to work on bugs/security issues. We have the working branches for what will eventually become master. Working is our “dev branch” but keeps proper seperation of things in my opinion.

Basically:
master -> basis for dev-branch (which merges into stable on a regular cadence - still being worked out)
working -> basis of forward development

So we effectively have:
production
staging
development well seperated.

THis may mean on the regular automated releases, no announcement or news article will be created, and I think that’s okay.

Hopefully exciting we have a release after 1.25 years

Thank you!

That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.

Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.

I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).

I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.

https://news.fogproject.org/fog-1-4-0-officially-released/

https://news.fogproject.org/fog-1-4-4-officially-released/

The third release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-3.

Test it on a lab or non-production server first. The upgrade from 1.5 to 1.6 is one-way: it changes the database schema, and there is no down-migration.

Upgrade from RC-2 now if you use fog-agent, a wildcard web certificate, or more than one master node. RC-3 fixes failures in all three.

Fixed since RC-2

• Agent enrollment failed with a 503 after the root CA was replaced (#1810). The installer created the FOG Agent CA only when its file was missing. If the root CA changed later, for example when you copy an older server’s /opt/fog/snapins/ssl onto a new install, the Agent CA stayed signed by the old root. Every enrollment then failed, and the Apache log showed FOG agent enroll: signing for host <id> ... failed: the issued certificate does not verify against /opt/fog/snapins/ssl/CA/.fogCA.pem. The RC-3 installer re-creates the Agent CA when the current root did not sign it. It keeps the old pair beside the new one with a date suffix.
• A wildcard web certificate broke the installer (#1800). The installer used the certificate’s commonName, for example *.example.org, as the server name. Apache refused the configuration, and the installer’s own calls to the server failed. --hostname was ignored. The installer now uses --hostname and checks that the certificate covers it. With no --hostname, it uses the server address.
• Constant ssh connections between master nodes (#1806). The services opened a connection to the ssh port of every master node on each pass. sshd logged Connection closed by <server> every few seconds. The services no longer probe the nodes for this check.
• fog-agent waited up to five minutes to see a task (#1802). The server told the agent to poll every 300 seconds. It now sends the client check-in interval, FOG_CLIENT_CHECKIN_TIME, which the legacy client already uses. With the default setting, agents poll every 60 seconds.

New since RC-2

• Windows activation through fog-agent (#1804). The server sends the host’s product key to the agent when the key is valid and the host enrolled as Windows. It needs a fog-agent release that supports activation. An older agent ignores it.

Before you upgrade

• Back up your database and /opt/fog/.fogsettings.
• Read the release notes: https://github.com/FOGProject/fogproject/blob/rc-1.6.0/docs/release/1.6.0-release-notes.md
• 1.6 removes Display Manager, Directory Cleaner, User Cleanup, Client Updater, Green FOG and the persistentgroups plugin. Their data is dropped. The site and accesscontrol plugins move into core.
• PHP 7.4 or later is required. Plugins built for 1.5 do not load.

Install or update (as root)

• A 1.6 beta, RC-1 or RC-2 server: run bin/updatefog.sh --channel rc from your FOG checkout.
• A 1.5 server installed from git: update to the current 1.5 stable, then run bin/updatefog.sh --channel rc from the checkout.
• A new server, or a 1.5 server installed from a tarball:
  curl -fsSL https://raw.githubusercontent.com/FOGProject/fogproject/working-1.6/bin/bootstrap.sh | bash -s -- --channel rc

Report problems

Open an issue at https://github.com/FOGProject/fogproject/issues. Include your FOG version, your OS, and the installer log from bin/error_logs/. Report a security problem through “Report a vulnerability” on the same repository, not in a public issue.

@Coolguy3289 Thanks for the log line. It points at a bug, not at your approach.

The installer creates a “FOG Agent CA” under the server root CA. It only creates it when the file is missing. If the root CA changes later (for example, you copy the old server’s /opt/fog/snapins/ssl onto the new box so existing clients keep trusting it), the agent CA stays signed by the first root. Every enrollment then fails with the error you see, and the agent gets a 503.

The fix is in PR #1810: the installer now re-creates the agent CA when the current root did not sign it.

To fix your server now, without waiting for the PR:

sudo grep PKI_AGENT_CA_CERT /opt/fog/.fog-pki

Move the .fogAgentCA.pem and .fogAgentCA.key files in that directory to a backup location. Then re-run the installer. It creates a new agent CA under your current root, and enrollment works.

You do not need your internal PKI for this. The FOG-generated root is fine for production.

@DiegoP Thanks, your workaround found the cause.

FOS installs mdadm’s udev rule, and that rule assembles every RAID member at boot. It ignored mdraid=true. The arrays then held nvme0n1p2/p3, so capture could not read the partitions.

FOS now assembles arrays only when mdraid=true is on the kernel command line. Without the flag, it leaves the member partitions alone. With the flag, nothing changes.

The fix is in the experimental FOS release EXP_20261001-163131: https://github.com/FOGProject/fos/releases/tag/EXP_20261001-163131. Replace /var/www/html/fog/service/ipxe/init.xz on your FOG server with that release’s init.xz. Then remove the postinit workaround and capture again. Please tell us whether it works.

@kratkale I’m not sure what problem you’re trying to solve.

if those 2 machines don’t have a valid image associated, what are you expecting to see for the 'Image Name"? In my head this is expected.

@kratkale Good, thank you for confirming.

If a snap-in does not run, open a new topic for it, and post these three things there:

• the snap-in task status from the web UI (Tasks, Active Tasks)
• whether the PC runs the FOG Client or the FOG Agent
• the client log from that PC: C:\fog.log for the FOG Client

Your certificates are the original ones, restored from the old directory. The clients do not need to trust a new CA.

The second release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-2.

Test it on a lab or non-production server first. The upgrade from 1.5 to 1.6 is one-way: it changes the database schema, and there is no down-migration.

Upgrade from RC-1 now if your server was upgraded from 1.5. RC-1 left the certificate files of a 1.5 server in the wrong directory. RC-2 prevents this and repairs a server that RC-1 already affected.

Fixed since RC-1

• A 1.5 upgrade lost its certificates (#1797). FOG 1.5 made /etc/fog a link to /opt/fog/service/etc. The upgrade wrote the new CA and web certificates through that link, then replaced the link with an empty directory. The files stayed in /opt/fog/service/etc/pki, where FOG does not look. Apache kept running on the certificate it had loaded, so the upgrade looked clean. At the next restart or reboot, Apache failed with SSLCertificateFile: file '/opt/fog/pki/web/leaf/.webLeaf.pem' does not exist or is empty. RC-2 converts the link before it writes any certificate. On a server RC-1 already affected, the RC-2 installer copies the files back. It never overwrites a file that exists, and it keeps any differing copy beside the original as pki.recovered-<date>.
• updatefog.sh --channel rc reported no release candidate when it could not reach the remote (#1793). A failed git ls-remote, for example as root with an SSH remote and no key, read as “No release candidate is currently published”. The installer now names the remote and says it could not reach it.
• The installer summary showed the netboot protocol of the previous run (#1798). A re-run with --no-public-web-cert showed Netboot (PXE) protocol: https, and then correctly set up HTTP netboot. The summary now shows the protocol the run uses.
• Versioning (#1796). The RC tag no longer changes the version that 1.5 branches compute.

If Apache on your RC-1 server does not start

Your certificates are most likely in /opt/fog/service/etc/pki. Update to RC-2 with bin/updatefog.sh --channel rc. The installer restores the files.

Before you upgrade

• Back up your database and /opt/fog/.fogsettings.
• Read the release notes: https://github.com/FOGProject/fogproject/blob/rc-1.6.0/docs/release/1.6.0-release-notes.md
• 1.6 removes Display Manager, Directory Cleaner, User Cleanup, Client Updater, Green FOG and the persistentgroups plugin. Their data is dropped. The site and accesscontrol plugins move into core.
• PHP 7.4 or later is required. Plugins built for 1.5 do not load.

Install or update (as root)

• A 1.6 beta or RC-1 server: run bin/updatefog.sh --channel rc from your FOG checkout.
• A 1.5 server installed from git: update to the current 1.5 stable, then run bin/updatefog.sh --channel rc from the checkout.
• A new server, or a 1.5 server installed from a tarball:
  curl -fsSL https://raw.githubusercontent.com/FOGProject/fogproject/working-1.6/bin/bootstrap.sh | bash -s -- --channel rc

Report problems

Open an issue at https://github.com/FOGProject/fogproject/issues. Include your FOG version, your OS, and the installer log from bin/error_logs/. Report a security problem through “Report a vulnerability” on the same repository, not in a public issue.

@kratkale That run is clean. Every step finished, the sudoers and certificate errors are gone, and all FOG services started.

The summary near the top says “Netboot (PXE) protocol: https”. That line is wrong: it showed the setting from the previous run. The end of the run is correct: netboot uses HTTP. I am fixing the summary line in the installer.

Please check these, in this order:

grep chain /tftpboot/default.ipxe
systemctl is-active FOGMulticastManager

The first line must start with chain http://192.168.0.196/. The second must say active. Then PXE boot one PC. If it reaches the FOG menu, switch the other PCs back to PXE and try the multicast task again. If a step fails, post the output of that step only.

@kratkale Thank you, that output shows the cause, and your certificates are not lost.

On FOG 1.5, /etc/fog was a link to /opt/fog/service/etc. The 1.6 upgrade moved your PKI files to /etc/fog/pki, so through that link they landed in /opt/fog/service/etc/pki. A later step of the same upgrade replaced the /etc/fog link with an empty directory. Your files are still in /opt/fog/service/etc/pki, but FOG no longer found them. This is an installer bug, and I am fixing it.

Copy them back. cp -n never overwrites a file that already exists:

cp -an /opt/fog/service/etc/pki/. /etc/fog/pki/
[ -d /opt/fog/service/etc/customizations ] && cp -an /opt/fog/service/etc/customizations /etc/fog/
ls -la /etc/fog/pki/root/ca /etc/fog/pki/web/leaf

Both listings must show real files: .fogCA.key in the first, .webLeaf.pem and .webLeaf.key in the second.

If you ran the Apache sed from my last post, put your original file back:

[ -f /etc/apache2/sites-available/001-fog.conf.orig ] && cp /etc/apache2/sites-available/001-fog.conf.orig /etc/apache2/sites-available/001-fog.conf

Then start Apache and run the installer, from your fogproject/bin directory:

apachectl configtest && systemctl restart apache2
./installfog.sh -y --no-public-web-cert
grep chain /tftpboot/default.ipxe

The last line must start with chain http://. If any step fails, post the output of that step. Leave /opt/fog/service/etc/pki where it is for now.

@kratkale Apache stops because its certificate file is gone. The Secure Boot error last week has the same cause: files under FOG’s PKI directory are missing.

I cannot find the cause without seeing what is left on disk. I asked for this on 2026-09-25, and every new error since then comes from the same missing files. So please run this one command first, before you change anything. It only lists file names and changes nothing:

{ ls -la /opt/fog /etc/fog /etc/fog/pki /etc/fog/pki/root/ca /etc/fog/pki/web /etc/fog/pki/web/leaf /opt/fog/snapins/ssl/CA; ls -ld /opt/fog/pki; find / -xdev \( -name '.fogCA.key' -o -name '.webLeaf.pem' -o -name '.fogWebCA.pem' \) -ls; } > /root/fog-pki-state.txt 2>&1

Post the contents of /root/fog-pki-state.txt here.

After that, this brings Apache back with a temporary certificate. Browsers will show a certificate warning, and PXE works again over http:

apt-get install -y ssl-cert
sed -i.orig --follow-symlinks -E \
  -e 's#^([[:space:]]*SSLCertificateFile)[[:space:]].*#\1 /etc/ssl/certs/ssl-cert-snakeoil.pem#' \
  -e 's#^([[:space:]]*SSLCertificateKeyFile)[[:space:]].*#\1 /etc/ssl/private/ssl-cert-snakeoil.key#' \
  -e 's#^([[:space:]]*)(SSLCertificateChainFile|SSLCACertificateFile|SSLVerifyClient|SSLVerifyDepth)#\1\# \2#' \
  /etc/apache2/sites-enabled/001-fog.conf
apachectl configtest && systemctl restart apache2
grep chain /tftpboot/default.ipxe

The sed keeps your original file as /etc/apache2/sites-available/001-fog.conf.orig. The last line must start with chain http://.

Do not run the installer again until we know where your CA files are. It would fail the same way.

FOG 1.6.0 Release Candidate 1 is available

The first release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-1.

Test it on a lab or non-production server first. The upgrade from 1.5 to 1.6 is one-way: it changes the database schema, and there is no down-migration.

Before you upgrade

• Back up your database and /opt/fog/.fogsettings.
• Read the release notes: https://github.com/FOGProject/fogproject/blob/rc-1.6.0/docs/release/1.6.0-release-notes.md
• 1.6 removes Display Manager, Directory Cleaner, User Cleanup, Client Updater, Green FOG and the persistentgroups plugin. Their data is dropped. The site and accesscontrol plugins move into core.
• PHP 7.4 or later is required. Plugins built for 1.5 do not load.

Install or update (as root)

• A 1.6 beta server: run bin/updatefog.sh --channel rc from your FOG checkout.
• A 1.5 server installed from git: update to the current 1.5 stable, then run bin/updatefog.sh --channel rc from the checkout.
• A new server, or a 1.5 server installed from a tarball:
  curl -fsSL https://raw.githubusercontent.com/FOGProject/fogproject/working-1.6/bin/bootstrap.sh | bash -s -- --channel rc

Report problems

Open an issue at https://github.com/FOGProject/fogproject/issues. Include your FOG version, your OS, and the installer log from bin/error_logs/. Report a security problem through “Report a vulnerability” on the same repository, not in a public issue.