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/

@Paladin1 Thanks for the report. You’re right, the docs were out of date.

The installer now asks Install/update the FOG database schema now? (Y/n) and does the schema update itself when you answer yes, which is the default. The browser step only applies if you answer no.

The “Denied” you saw is expected on a new install. With no FOG users yet, the schema page only accepts the link the installer prints, which ends in &fogtoken=.... On an existing install, you log in as an admin instead.

The install pages are updated for both versions:

• 1.5: https://docs.fogproject.org/en/latest/1.5/installation/server/install-fog-server/
• 1.6: https://docs.fogproject.org/en/latest/1.6/installation/server/install-fog-server/

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

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.

Changed since RC-9

• iPXE: boot no longer freezes on some UEFI firmware (forum 18271, #1857). default.ipxe read the SecureBoot and SetupMode EFI variables. On some older firmware that read never returns, and the host froze before the menu. The installer no longer writes those two lines. Run the update to rewrite default.ipxe. Hosts no longer report their Secure Boot state on PXE boot. FOS still reports it when the enrollment task runs.
• CSV import reads a file that FOG exported (GH-1851, #1855). “CSV (All)” starts the file with a UTF-8 byte-order mark. The import did not skip it, so it did not find the header row. It imported the header as a host, and the row failed with “No viable macs to use”. The import now skips the mark.

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 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.

@fierke A correction to my last post. The fix is now merged into working-1.6 and rc-1.6.0. Update your checkout and re-run the installer. The installer now writes default.ipxe without those two lines, so you do not need to comment them out again.

You are right that this can happen on other machines too. Any UEFI firmware that never ends its variable list hangs the same way. The update fixes it for all of them.

I would still like the show efi/SecureBoot result and your BIOS version when you have time. That confirms the cause before the iPXE side ships.

(Yes I’m using AI to help out in troubleshooting and fixing as well trying to get more details in an AI model so the posting below is a reply requested for information.)

@fierke Thanks, that narrows it down a lot.

Those two lines read EFI variables. To find one, iPXE walks the firmware’s whole variable list. Some older UEFI firmware never ends that list, so iPXE loops forever. That fits what you see.

Can you help me confirm it? On the E7240:

1. Leave the two lines commented out for now.
2. PXE boot, and press Ctrl+B when iPXE starts to get the iPXE shell.
3. Run dhcp, then show efi/SecureBoot.
4. Tell me whether it prints a value, prints an error, or hangs.

Also, which BIOS version is on the machine? It shows on the F2 setup screen.

Either way, I am removing those two lines from default.ipxe so this cannot stop a boot. I am also fixing iPXE so it reads the Secure Boot state directly, without the walk. Your workaround is safe until then. Note that re-running the installer writes the lines back, so comment them out again after an install.

@fierke Are you running secure boot?

I think this is a firmware bug. I’ll take a look but just asking.

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

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.

Changed since RC-8

• FOG Agent: a held domain rename reports pending, not failed (#1850). After a join or rename attempt, the server waits one hour before it sends the AD credentials again. A second rename within that hour waited, and agent 0.1.12 logged hostname: failed at every poll. The server now tells the agent when the rename may go ahead. Agent 0.1.13 logs hostname: pending (... this one runs after <time>) and renames on the first poll after that time. Older agents still log failed until the hour passes.

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 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.

FOG 1.6.0-RC-8 is available

The eighth release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-8. Release page: https://github.com/FOGProject/fogproject/releases/tag/1.6.0-RC-8

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.

Changed since RC-7

• FOG Agent: renaming a domain-joined Windows host (#1846). On RC-7, agent 0.1.12 refused the rename and logged hostname: failed ... this machine is in a domain, so its computer object must be renamed too at every poll. The server now sends the host’s AD credentials for the rename, and only while the rename is outstanding. The agent renames the machine and its computer object together, then reboots once. Needs FOG Agent 0.1.12 or later, and the host’s AD username and password set in FOG.
• Client page: a FOG Agent card (#1844). ?node=client now links the FOG Agent download. It shows a silent MSI install example and enroll examples.
• Dashboard: agent version rows filter the host list (#1848). Clicking a version in the Agent Versions card opens the host list filtered to that version.

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 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.

I don’t know if we’ve officially asked users if they’d like to join the Discord we have.

We haven’t “hidden” the links, but we didn’t announce the discord we have.

The link to join if you’d all like to:
https://discord.gg/gZ7DC2ThxF

Thanks!

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

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.

Changed since RC-6

• FOS check-in failed behind Apache’s forced HTTPS (#1835, issue #1829). Check-in failed with “Invalid MAC Address!” and registration with “No viable macs to use”. The redirect turned FOS’s POST into an empty GET. It now keeps the POST. Re-run the installer to apply it.
• Legacy FOG Client: “Thumbprints did not match” after restoring an old root CA (#1837). The installer kept a client communication certificate that the restored root did not sign. It now re-issues that certificate under the current root, with the same key. Registered clients need no reinstall.
• Schema update stopped at step 344 on MySQL (#1840). It failed with 1067 Invalid default value for 'hostSecTime' on databases first built on MySQL 5.x. The schema updater now completes.
• Install failed with “Could not download bzImage32 properly” (#1842). A short GitHub error page was saved as the kernel and as its checksum file. The installer now treats an HTTP error as a failed download and logs the reason. If you already hit this, delete /root/fogproject/tmp/bzImage32* (or the file it names) and re-run the installer.

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 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.

@jmeyer This is a bug in schema step 284 on MySQL. Your data did not cause it.

Cause: on MySQL, an ALTER TABLE re-checks the default of every column. Your hosts.hostSecTime still has the old default 0000-00-00 00:00:00. MySQL’s default sql_mode (NO_ZERO_DATE) refuses that default, so the step stops. MariaDB servers do not show the problem.

Fix: https://github.com/FOGProject/fogproject/pull/1838 is merged into dev-branch. While the steps run, the schema updater now relaxes the zero-date check for its own session.

The fix reaches the stable release on October 11. To continue now, install from dev-branch:

cd /root
git clone -b dev-branch https://github.com/FOGProject/fogproject.git fogproject-dev
cd fogproject-dev/bin
./installfog.sh -y

The failed step changed nothing in your database, so you do not need to restore the backup. The backup the installer made is still at /home/fogDBbackups/fog_sql_1.5.10.2482_20261009_113907.sql.