Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

    @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:

    Make a key on either machine: openssl rand -hex 32 On the VM, open Storage Management, then edit the master node (NComun). Paste the key into Node API Signing Key and click Update. 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.

  • Get the latest news on what's happening.
    200 Topics
    841 Posts
    Tom ElliottT

    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.

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    G

    Do the new PHP Vulnerabilities’ CVE-2026-109618 (RCE via OOM corruption) and CVE-2026-109619 (RCE via stale global state) apply to FOG? And if so, will there be a patch?

  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    Tom ElliottT

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

86

Online

12.8k

Users

17.7k

Topics

157.3k

Posts