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 sixteenth release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-16.

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

• Multicast: a named session is no longer canceled before hosts join (#1922, #1923, #1924). RC-15 canceled a named session about 10 seconds after it started, and the PXE menu then rejected the session name.
• Multicast: a host cancel no longer ends a session that expects machines by name (#1925, #1926). Unregistered machines that joined by name keep receiving. End the session with its own Cancel.
• Multicast: the PXE join closes when udp-sender starts sending (#1927, #1928). A late machine could join a session already in transfer and receive a partial image. This adds schema 442 (multicastSessions.msTransferStart).
• Installer: the ssh2 extension matches the PHP that php-fpm runs (#1929, #1931). On Linux Mint, snapin uploads failed with a 500 because php-ssh2 went onto a different PHP version. Linux Mint now uses the distro PHP, as Ubuntu does. Forum: https://forums.fogproject.org/topic/18289
• Services: each daemon child opens its own database connection (#1930, #1933, #1934). A restarted service child could fail with “Packets out of order” and read empty settings.
• Dashboard and reports: per-day charts use your time zone (#1935, #1936, #1937). The imaging history graph showed each day one day early west of UTC. The per-day charts on the Imaging, Snapin, Audit, Fleet, Hardware and Storage reports now count each run on its day in FOG’s display zone.

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.

@WielandPP1 Thanks for the log line. It shows the cause exactly.

PHP 8 is supported, so you do not need a different PHP version. The problem is a missing PHP extension. On Linux Mint, the installer adds the ondrej PHP repository. In that repository, php-fpm installs PHP 8.4, but php-ssh2 installs the ssh2 extension for PHP 8.5. Your web server runs PHP 8.4, so ssh2_connect() does not exist and the snapin upload fails.

To fix your server now, install the ssh2 extension for PHP 8.4 and restart PHP-FPM:

sudo apt-get install php8.4-ssh2
sudo systemctl restart php8.4-fpm

Then try the snapin upload again.

We are also fixing the installer in working-1.6 and rc-1.6.0:

• The installer installs the ssh2 extension for the PHP version that PHP-FPM runs.
• On Linux Mint, the installer uses the distribution’s own PHP, as it already does on Ubuntu and Debian.
• If the extension is missing, the upload shows “SSH Connection has failed” instead of a 500 error.

@gleckey no patch would be necessary for FOG. The PHP vulnerability applies to PHP packages, not to fog.

Now, you can update the packages using your OS package management, or you can rerun the installer for FOG which also tries to update any of the packages FOG may need. Either option will work.

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

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

• Installer: choose the UEFI loader that DHCP hands out (#1915, #1916). Some firmware does not release the NIC when snponly.efi hands off to FOS. Those machines boot with ipxe.efi. Install with --uefi-bootfile ipxe to hand out the iPXE loader. The installer saves the choice in .fogsettings, so an upgrade keeps it. The default is still snponly.
• Dashboard: a peer FOG server no longer shows “Access Denied” (#1917, #1918). A storage node entry can point at a full FOG server with its own database. Its disk usage and server information now accept the node signing key, not only a known IP address. Set the same key on both servers: https://docs.fogproject.org/en/latest/1.6/management/web/storage-node/
• FOS: fixparts is back. A capture showed “Could not fix partition layout (runFixparts)”. The fix is in FOS EXP_20261021-160109, which the update installs.

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.

@DBailey635 No.

So this one was a decision to actually attempt to make Groups more useful.

While it seems like it’s removing features, it actually enhances them.

Groups in the past were things that any host could join at any given point in time. Why is this a problem? Imagine HostA in 5 groups. What group applied what pieces of it to the host? Did a group apply anything to a Host? It could yes, but if I have HostA in GroupA and GroupB. GroupB has ImageB assigned to it, and GroupA has ImageA assigned to it. If you update a group (open and hit save) it would modify All hosts in the group. But now you’re looking at different group you may get confused.

So Yes you can still mass edit hosts based on groups in 1.6, you just do it from the Host page. (You can filter the list to specific groups)

Groups are now additive in nature. You assign Snapins, Printers, etc… to a group. (You can still apply to hosts as well, but groups aren’t applying to each individual host anymore). If a host is in multiple groups, things that arent’ assigned to that host, but assigned to the groups will now be applied to the hosts.

https://docs.fogproject.org/en/latest/1.6/management/web/groups/

This helps break it down a bit more technical, but hopefully more representative of the feature set.

@piaFOG26 One more item, about the “Access Denied” in the disk usage box on the VM dashboard.

Your VM and your master node are two full FOG servers, and each has its own database. The master node only trusts requests from the storage nodes in its own database, so it refuses the VM. I fixed this in FOG: a request signed with a shared node key is now accepted. The fix is on dev-branch now and reaches the stable release on November 11.

To use it, both servers must have the same key. First, finish the schema update on the master node. Then:

1. Make a key on either machine: openssl rand -hex 32
2. On the VM, open Storage Management, then edit the master node (NComun). Paste the key into Node API Signing Key and click Update.
3. On the master node, run this from the fogproject folder you installed from: sudo php bin/fog-node-key.php --set <the same key>

If you need it before November 11, install dev-branch on the master node. The fix must be on the master node, because that is the server that checks the key.

@piaFOG26 Thank you, the screenshots help. I still need the install logs.

Your master node (Ubuntu 20.04) has the 1.5.10.2518 files, but its database is still at schema 270. This release needs 288. In your screenshot, the installer asked “Install/update the FOG database schema now?” and you answered n.

Run the installer again on the master node and answer Y. The installer then updates the schema itself, and you do not need to log in to the web page.

The “Unauthorized” on the schema web page means the account you used is not a FOG administrator. Which user did you log in as?

If the installer fails again, please post the newest file from /root/fogproject/bin/error_logs/. If you ran the installer from a different folder, use the bin/error_logs/ folder in that location.

Also, please tell us what fails on the master node other than the disk usage box on the dashboard. Can you still capture and deploy images?

@delacroix fixparts went missing from FOS during a Buildroot update. The fix (fos#195) landed yesterday, and the first build with it is EXP_20261021-160109. I checked that release: /usr/sbin/fixparts is present in init.xz, init_32.xz, and arm_init.cpio.gz.

Your debug task boots the init that your FOG server serves, not the one you downloaded. Put the new file in place on the server:

cd /var/www/html/fog/service/ipxe
mv init.xz init.xz.old
wget https://github.com/FOGProject/fos/releases/download/EXP_20261021-160109/init.xz
sha256sum init.xz

The hash must match the init.xz.sha256 on the release page (it starts 8e3457ad4268add5). To check the content without a boot:

xz -dc init.xz > /tmp/init.img
debugfs -R "ls -l /usr/sbin" /tmp/init.img | grep fixparts

Then run the capture again. If fixparts is in that listing and the capture still fails, please post the output of fixparts /dev/sdX (or /dev/nvme0n1) from a debug task.

@piaFOG26 There is nothing on fog that says “you must update” though most likely we’d have recommended it.

Ubuntu 20 LTS went EOL June 2026. That aside, we need more informaiton please.

Provide the install logs and maybe a screenshot of the actual error you’re seeing when trying to update.

Also, worthwhile, might be worth installing the 1.6.0-RC version (RC-14 is the current latest available) as likely by mid November, it will become the latest official available release.

Either way, please provide more information.

Thank you,

@DBailey635 Look at the address in the failure: iPXE asks 192.168.5.6 for default.ipxe. Your FOG server is 192.168.5.25. FOG does not supply that address. iPXE gets it from the DHCP answer it receives.

The first download (snponly-shimx64.efi) works, so the first DHCP offer is correct. iPXE then does its own DHCP request. A second DHCP server answers it and names .6 as the next-server. .6 has no TFTP server, so the request times out.

The usual cause is a MikroTik in “bridge mode” that still runs its default DHCP server on the bridge interface. Please check:

• On the MikroTik at .6: run /ip dhcp-server print and /ip dhcp-relay print. Disable any entry you find.
• On the MikroTik at .1: under /ip dhcp-server network, set next-server to 192.168.5.25.

To confirm, run tcpdump -ni any port 67 or port 68 on the FOG server while the laptop boots. You should see offers from two servers.