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

@Tom-Elliott Thanks fo the quick reply!
I did rerun the installer today and it seems to be working now, thanks a lot for the quick feedback and fix!

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

@piaFOG26 Are you able to confirm if things are now working for you?

Thanks @Tom-Elliott . That actually makes a lot more sense now. 😁

I saw the greyed-out “Mass edit” button, but hadn’t worked out that I had to select multiple items (turn them blue) from the filtered list of hosts in order to be able to use that button to set values across multiple entries. Once I did, it worked as intended.

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

@Tom-Elliott sorry tom yes i am, sorry for the late reply, tbh i think its just hp machines that do this

@Tom-Elliott

Thank you!

As you thought, it was a double DHCP server… Even though .6 was in bridge mode, the DHCP server on it was still enabled, unlike the other MikroTik switches we have. Disabling it brought the iPXE booting back. I’ve run a re-inventory task and am now running an image capture task.

I’ll have to keep a future eye open for that as we expand our classroom network.

Cheers!