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

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

These fixes prepare the update channels and the version number for the 1.6.0 release. They add no schema step and no UI change.

• The beta channel finds the current development line (#2014, #2015). --channel beta named working-1.6 directly. It now uses the newest working-* branch, the same way --channel rc finds the newest rc-* branch. When no beta line exists, updatefog.sh and the bootstrap installer say so and suggest --channel stable. Before, the checkout failed.
• The version number after 1.6.0 is correct (#2012, #2013). After the 1.6.0 tag, the patches line would report 1.6.N. The installer reads an X.Y.Z version as a FOS release tag, so it would ask for a kernel that does not exist. The patches line now reports 1.6.0.N.
• The required 1.5 upgrade check also runs on rc-1.6.0 (#2011). CI only.

FOS (kernel and init), from the Latest FOS release

An RC install or update downloads the Latest FOS release. Latest is still EXP_20261027-181357, unchanged since RC-18:

• Kernel 6.18.59, the current 6.18 LTS release.
• FOS verifies TLS, which is the client half of #1978.
• The Performance Test task.
• x64 and x86 boot an initramfs, not an ext2 initrd (FOGProject/fos#75). The file names stay init.xz and init_32.xz, and the boot menu does not change. /tmp is now a real RAM disk with a size limit: FOG_KERNEL_RAMDISK_SIZE sets the size, kept between 64 MB and half of the client’s memory.
  • Warning: a customized init can no longer be loop-mounted. Add your files as an overlay cpio appended to init.xz instead: https://docs.fogproject.org/en/latest/kb/how-tos/customize-the-fos-init/ . A post-init script needs no rebuild at all: https://docs.fogproject.org/en/latest/kb/how-tos/post-init-scripts/
  • If a client fails to boot with this init, go to FOG Configuration > Initrd Update and install the init from EXP_20261027-155909, the last ext2 init. Then report it on FOGProject/fos#75.

API documentation: https://docs.fogproject.org/en/latest/1.6/kb/integrations/api

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.

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

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

These fixes come from #2000, a test of the upgrade from 1.5.10.2518. Thanks to cepadugato, who reported it and contributed the first fix.

• The 1.5 upgrade completes on the first installer run (#2001, #2002). A 1.5 server’s schema count skipped the step that creates fileDeleteQueue, so step 290 failed with error 1146 and the installer printed Failed!. A second run finished the upgrade. Now the updater repairs the schema when a step names a missing table, and it retries that step once.
• An installer rerun keeps the 1.5 web backup (#2003, #2004). A second installfog.sh run after the upgrade replaced the only 1.5 web-tree backup, so bin/revertfog.sh had no web tree to restore. The installer now renames a backup of another release to fog_web_<its version>.BACKUP and keeps it. The release notes now name the backups correctly.
• User names longer than 40 characters fit on upgraded servers (#2005, #2006). On a server upgraded from 1.5, users.uName and users.uCreateBy stayed VARCHAR(40). A long LDAP or OIDC login, such as a full email address, did not fit. Schema step 446 widens both columns to VARCHAR(255).
• The schema updater repairs column types that cannot lose data (#2007, #2008). A skipped 1.6 step that changed a column type was only reported before. The updater now applies a longer string type, a wider integer, or NOT NULL to NULL. Any other type drift is still only reported. A new required CI check upgrades a real 1.5 database with each pull request.

FOS (kernel and init), from the Latest FOS release

An RC install or update downloads the Latest FOS release. Latest is still EXP_20261027-181357, unchanged since RC-18:

• Kernel 6.18.59, the current 6.18 LTS release.
• FOS verifies TLS, which is the client half of #1978.
• The Performance Test task.
• x64 and x86 boot an initramfs, not an ext2 initrd (FOGProject/fos#75). The file names stay init.xz and init_32.xz, and the boot menu does not change. /tmp is now a real RAM disk with a size limit: FOG_KERNEL_RAMDISK_SIZE sets the size, kept between 64 MB and half of the client’s memory.
  • Warning: a customized init can no longer be loop-mounted. Add your files as an overlay cpio appended to init.xz instead: https://docs.fogproject.org/en/latest/kb/how-tos/customize-the-fos-init/ . A post-init script needs no rebuild at all: https://docs.fogproject.org/en/latest/kb/how-tos/post-init-scripts/
  • If a client fails to boot with this init, go to FOG Configuration > Initrd Update and install the init from EXP_20261027-155909, the last ext2 init. Then report it on FOGProject/fos#75.

API documentation: https://docs.fogproject.org/en/latest/1.6/kb/integrations/api

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.

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

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

• Service restarts no longer flood servicemaster.log with PHP warnings (#1994, #1996). A service’s supervisor closes its database connection before it starts each worker. Its next log line could read a setting on that closed connection, which wrote “Trying to access array offset on false” at FOGBase.php lines 3747 and 3752. The supervisor now reopens the connection before it logs. A failed settings read no longer warns, and it no longer empties the settings cache.
• SSH: no more “Undefined array key “_link”” warning, and no fatal after a failed connect (#1997, #1999). FOGSSH::disconnect() unset its connection, so the next use of the shared SSH object warned. A disconnect with no live session also threw a TypeError on PHP 8.
• User export imports back (#1987, #1993). A user row with no password gets a random password and a warning to set one. A password hash is stored as-is, and a typed password is hashed. A new permission, user.export, adds “Include password hashes” to the user export page. It is denied by default, and each hash export writes an audit row.
• The installer warns about no_root_squash only on the <share>/dev export (#1988, #1990). An unrelated export, such as an ISO share, no longer raises the warning. Thanks to sgennadi, who reported it and proposed the fix.

FOS (kernel and init), from the Latest FOS release

An RC install or update downloads the Latest FOS release. Latest is still EXP_20261027-181357, unchanged since RC-18:

• Kernel 6.18.59, the current 6.18 LTS release.
• FOS verifies TLS, which is the client half of #1978.
• The Performance Test task.
• x64 and x86 boot an initramfs, not an ext2 initrd (FOGProject/fos#75). The file names stay init.xz and init_32.xz, and the boot menu does not change. /tmp is now a real RAM disk with a size limit: FOG_KERNEL_RAMDISK_SIZE sets the size, kept between 64 MB and half of the client’s memory.
  • Warning: a customized init can no longer be loop-mounted. Add your files as an overlay cpio appended to init.xz instead: https://docs.fogproject.org/en/latest/kb/how-tos/customize-the-fos-init/ . A post-init script needs no rebuild at all: https://docs.fogproject.org/en/latest/kb/how-tos/post-init-scripts/
  • If a client fails to boot with this init, go to FOG Configuration > Initrd Update and install the init from EXP_20261027-155909, the last ext2 init. Then report it on FOGProject/fos#75.

API documentation: https://docs.fogproject.org/en/latest/1.6/kb/integrations/api

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.

@sgennadi Thanks for this, and for the detail. You were right: the check matched no_root_squash anywhere in /etc/exports, not just on the /images/dev export.

It is fixed now, much the way you proposed. The new nfsDevExportHasNoRootSquash() checks only the <share>/dev export. It ignores comments, other exports, and look-alike paths such as /images/dev2. Your ISO export with no_root_squash no longer triggers the warning.

• Issue: https://github.com/FOGProject/fogproject/issues/1988
• 1.6 (working-1.6): https://github.com/FOGProject/fogproject/pull/1989 (merged)
• 1.6 RC: https://github.com/FOGProject/fogproject/pull/1990 (merged)
• 1.5 dev-branch: https://github.com/FOGProject/fogproject/pull/1991 (merged)

To get it now, pull dev-branch (1.5) or rc-1.6.0 (1.6) and re-run the installer. It reaches the 1.5 stable branch with the monthly roll-up on November 11th.

The warning was only a message, so your exports were never changed. If /images/dev is already all_squash, you can ignore it until then.

@Dominique I can’t promise that, no.

1.5.10 is the original release, and it is a long way behind now. It was built and tested against PHP 7.x. It may run fine on PHP 8, but I don’t know which PHP 8 version, if any, would be safe for it.

What we do know works on PHP 8 is the current stable branch. Here is how the branches fit together:

• master is the official 1.5.10 release. We don’t work on it directly.
• dev-branch is where all the bug fixes and maintenance happen.
• stable gets everything from dev-branch rolled into it once a month.

So stable is 1.5.10 plus a few years of fixes, PHP 8 support among them.

If you want to move to PHP 8 before 1.6.0 comes out, I’d do it in this order:

• Snapshot the server first, so you can roll back.
• Update FOG to the stable branch and run the installer. Do this while you are still on PHP 7.2.
• Then move PHP to 8.2. On Red Hat 8 the installer will not do that for you; it installs whichever PHP module is enabled. Run dnf module reset php then dnf module enable php:8.2, then dnf distro-sync.
• Re-run the FOG installer, so it picks up the new PHP packages.
• Test the web console, a host registration, and a unicast and a multicast deploy before you call it done.

Since this is production, your plan to wait for 1.6.0 and try the RC in a test environment first is a good one too.

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

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

• FOS checks the server’s TLS certificate (#1978, #1980). The boot menu sends FOS the server’s public-key pin as fogpin=. FOS refuses a server whose key does not match. With no pin, FOS checks the chain against its own CA bundle. If that check fails, FOS warns once and continues.
• New task type: Performance Test (#1982). It is an advanced task. FOS times disk reads, network reads and decompression on the client, names the slowest one, and changes nothing on the disk. The host’s Performance tab, under History Items, lists each result. This adds schema 444.
• Audit: work that no person did is recorded as (system), not fog (#1984). fog is also the default admin’s username, so a rejected API token or a host that FOS registered looked like the admin’s action. This applies to the Audit Log, to Created By on records saved with no signed-in user, and to quick-registration tasks. Rows written before the update keep fog. Task e-mail through ${user-name} does not change.
• FOG_KERNEL_RAMDISK_SIZE describes what the value now does (#1986). This adds schema 445. It changes the text only, not the value.

FOS (kernel and init), from the Latest FOS release

An RC install or update downloads the Latest FOS release. Latest is now EXP_20261027-181357:

• Kernel 6.18.59, the current 6.18 LTS release.
• FOS verifies TLS, which is the client half of #1978.
• The Performance Test task.
• x64 and x86 boot an initramfs, not an ext2 initrd (FOGProject/fos#75). The file names stay init.xz and init_32.xz, and the boot menu does not change. /tmp is now a real RAM disk with a size limit: FOG_KERNEL_RAMDISK_SIZE sets the size, kept between 64 MB and half of the client’s memory.
  • Warning: a customized init can no longer be loop-mounted. Add your files as an overlay cpio appended to init.xz instead: https://docs.fogproject.org/en/latest/kb/how-tos/customize-the-fos-init/ . A post-init script needs no rebuild at all: https://docs.fogproject.org/en/latest/kb/how-tos/post-init-scripts/
  • If a client fails to boot with this init, go to FOG Configuration > Initrd Update and install the init from EXP_20261027-155909, the last ext2 init. Then report it on FOGProject/fos#75.

API documentation: https://docs.fogproject.org/en/latest/1.6/kb/integrations/api

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.

@Dominique If you’re able to, I’d highly suggest to snapshot the server first, or otherwise ensure you have a path to reinstall php down to 7.2 just incase updating to 8.X breaks your 1.5.10 availability.

No, you shouldn’t need to re-install fog after updating PHP, but it also wouldn’t hurt anything (but again I highly recommend snapshotting if possible just due to the age of 1.5.10 vs the stable branch code base.)

@Dominique Running such an old version of PHP and FOG probably not a good thing.

While 1.5.10 worked on the 7.2 line I don’t recall if it accounted for 8.X versions of PHP, You’re willing to attempt it but I would still highly recommend updating to the latest for both the stable and php versions (and if you’re updating FOG may as well update to the rc-1.6.0 version as I plan on mid november timeframe to make it official and need feedback to ensure all is well.

Thank you!

@Coolguy3289 I believe we fixed the problem, please confirm and I can solve this thread, thank you!

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

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

• REST API: changes that can break a script. Check your API tooling before you update.
  • A cancel names one object. DELETE /{class}/cancel with no id is removed, and an id that does not exist answers 404 (#1960, #1969). FogApi Remove-FogObject -type objectactivetasktype sends the removed request.
  • PUT /{class}/join (bulk edit) needs {class}.edit, not .create. POST /group/join on an existing group also needs group.edit (#1967).
  • A list sends JSON null for a NULL column. It sent "" before (#1965).
  • Errors answer 400, 404, 405 or 409 with a {"error": ...} body. An unrouted path answers 404, not 501 (#1962, #1971).
• REST API: a create that leaves out a field gets the column DEFAULT (#1948). An image created without isEnabled was disabled, and its next capture failed with “Image is not enabled”.
• REST API: a bulk edit runs the same checks as a single edit (#1958). Loading a node failure by id works (#1955). The pxemenuoptions list sends regMenu as an integer (#1971). The OpenAPI document reports the real maxRows and matches what the API sends (#1944, #1963). Two unauthenticated URL prefixes that matched no route are removed (#1971).
• Modules: “Not set” follows the module default (#1974). A change to a module’s default now reaches every host left Not set. A new host has no module rows, so it follows the defaults. This adds schema 443: it writes an explicit Off row where a 1.5-era host had a default module turned off, so no host changes state at the upgrade.
  • Warning: ticking a module’s Default now switches it on for every host left Not set, not only for new hosts. Schema 443 protects only modules whose Default is already on. On a server upgraded from 1.5, many hosts have no row for a module whose Default is off, because 1.5 stored “off” as no row. Ticking Default on that module turns it on for all of those hosts at once. Before you tick it, set the module to Off on each host that must not run it.
• Groups: mass edit a group’s member hosts from the group page (#1940).
• Installer: a fresh install on Debian 12 no longer stops at sysv-rc-conf (#1943).
• Installer: a warning when sshd blocks password login for the FOG service user (#1976). Image captures fail at the move step in that case. The installer does not change sshd_config. A Kea install no longer prints the isc-dhcp-server unit error.

Thanks to cepadugato for the RC-16 test report (#1945). It covered Debian 12, Debian 13 and Ubuntu 24.04, with BIOS and UEFI clients.

API documentation: https://docs.fogproject.org/en/latest/1.6/kb/integrations/api

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.