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.

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

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

• Multicast: canceling one host no longer cancels the whole session (#1903, #1905, #1909). Before, a cancel on one host stopped udp-sender and canceled every host in the session. Now only that host leaves. When every remaining host has connected, the session starts at once, without the max-wait. The FOS receiver also gives up after the session’s max-wait when no sender answers. That half is in FOS EXP_20261019-150930, which the update installs.
• Secure Boot: the PXE menu enrollment is recorded (#1869, #1899). The Enroll Secure Boot Key menu item opened MokManager, and the host page still showed no enrollment. The server now records mok-pending when it serves the key. The host page tells you how to confirm it.
• Group create form: the dead boot fields are removed (#1901). Group Kernel, Group Kernel Arguments, Group Init and Group Primary Disk were saved and never used. To set these on many hosts, use Edit selected hosts on the Hosts list.
• Tab titles in non-ASCII languages (#1910). After sidebar navigation, a Japanese or Chinese tab title was garbled. It now matches a full page load.
• Japanese translation is complete (#1910, #1913). Every message is translated. Uptime no longer shows an English plural s after a translated unit, such as 日s.

Thank you to @mashiro-mikage for the tab title fix, the Japanese translation, and the uptime fix.

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.

@robertkwild So you’re good now?

@robertkwild I think we need a screenshot of the issue you’re describing. Also, how did you enroll the machine? It almost sounds like the enrollment failed.

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

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

• Permissions: each task type is a permission (#1878, #1881). Before, a role that could start a task could start every task type: deploy, capture, wipe and debug. A role now also needs tasktype.<type> or tasktype.*. Set them on the new Task Types tab of the role edit page. The upgrade gives tasktype.* to every role that could already start a task, so no role loses access. iPXE quick image and full registration with a deploy now need the Deploy task type. This adds schema 441.
• New plugin: Directory Groups (#1879, #1883, #1885, #1888). It groups hosts by Active Directory OU, across one or more domains. A core FOG group backs each directory group. Core adds the hooks the plugin uses.
• Directory Domains: one join account per domain (#1887, #1897). A domain can hold the account its hosts use to join it. The FOG Client, the FOG Agent and FOS use it. The domain’s account takes precedence over the host’s own. This needs fog-plugins v1.6.27, which this RC installs.
• FOS gets the join password only for a host that joins (#1891). hostinfo.php sent the join account for every imaging task, also when domain join was off on the host. It now sends it only when domain join is on.
• API: plugin secrets are not returned (#1895). The API built its list of secret fields before the plugins loaded. Every earlier 1.6 RC returned plugin secrets to a signed-in API caller with read permission. Examples are the LDAP, OIDC and Directory Domain bind passwords. Update an RC server that runs those plugins.

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

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

• FOG Agent: a deploy with snapins images again (#1875, #1877). A deploy task created with snapins creates its snapin job at the same time. The agent ran those snapins on the old system before the reboot. When the last one finished, FOG marked the deploy task complete, so the task left Active Tasks and the machine booted to the iPXE menu. The agent now gets no snapins while a deploy is active. They run after imaging, as with the legacy client.
• Secure Boot: “Enroll Secure Boot Key” works on a fresh install (forum 18277, #1867). The installer copied MokManager into the enrollment kit before it downloaded the file. A fresh install published no MokManager, and iPXE showed “Permission denied”. An upgrade published the previous install’s copy. The installer now copies it after the download. Run the update to fix an existing server.
• Quick registration: FOG_QUICKREG_MAX_PENDING_MACS=0 turns pending MACs off (#1872, #1873). The limit was checked before a check-in added its MACs, so a host at the limit could store one more batch of any size. FOG now counts the new MACs too: 0 stores no pending MAC, and a batch that would pass the limit is refused whole. This adds a schema update that rewrites the setting’s help text.

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.

@robertkwild The issue most likely is not coming from the flip of Secureboot On/Off.

Unsigned or test-signed boot drivers. This is where a real BSOD can happen. If the machine has bcdedit /set testsigning on or nointegritychecks, and a boot-start driver depends on that (an unsigned storage or RAID driver, some sketchy anti-cheat, a dev build), turning Secure Boot on makes those settings get ignored. If the storage driver doesn’t load, you get INACCESSIBLE_BOOT_DEVICE. That one only happens in the off-to-on direction.

@robertkwild The secureboot enable/disabled ultimately does not matter and shouldn’t.

Windows will happily boot in either scenario.

@robertkwild for that particular fog server, correct. Once enrolled it’s good.

@Paladin1 Thanks, that explains the registration error. Registration reads the machine’s disk, so it needs a disk attached. With no disk it stops with that message every time. That is expected, so you do not need the debug task.

For your question: neither. Do not reinstall anything yet.

The BIOS boot mode on this machine applies to both the network boot and the installed OS. Your image is a UEFI install, so this machine has to network boot in UEFI too. We can try a different iPXE file for UEFI that loads its own network driver. That can avoid the firmware error.

On the FOG server:

1. Edit /etc/kea/kea-dhcp4.conf.
2. In the classes FOG-UEFI-64-1, FOG-UEFI-64-2, FOG-UEFI-64-3 and FOG-Surface-Pro-4, change "boot-file-name": "snponly.efi" to "boot-file-name": "ipxe.efi".
3. Run sudo systemctl restart kea-dhcp4-server.
4. Set the target BIOS back to UEFI and network boot it.

Tell us if you get the FOG menu or the same ASSERT. If it fails, change the file back. A re-run of the installer also puts snponly.efi back.

@Paladin1 Thanks, that answers it.

UEFI: Legacy boots and UEFI does not, so the ASSERT is the XPS 8400’s own UEFI firmware. FOG and iPXE cannot fix that. Use Legacy boot for this model.

Menu timeout: In the web UI, go to FOG Configuration > iPXE General Configuration. Set “Menu Timeout” to a larger number of seconds. The default is 3.

Registration error: “Could not determine a suitable disk automatically” means the registration found no disk at that moment. Your capture on the same machine did find a disk, so I need a little more:

• Does registration fail every time, or did it fail once?
• In the BIOS, what is the SATA mode: AHCI, RAID, or ATA/IDE?
• Please run a debug task on that host: Hosts > (the host) > Basic Tasks > Advanced > Debug. At the shell, run lsblk, then dmesg | grep -iE 'ata|sd'. Post a photo of both.