@sgennadi Thanks for the write-up. It matches what I found. --addcert first appears in sbsigntools 0.9.4, so 0.9.4 is the minimum. EPEL 8 ships 0.9.2, so this affects every EL8 install, not only Oracle Linux. The Rocky Linux Core SIG package you used is a good way to get a newer version.

A dev-branch change (PR #2081) makes the installer test for --addcert before it signs. When the option is missing, the installer now names the required version instead of printing a bare “Failed”.

@sgennadi Thanks for the detailed report. Your diagnosis is right.

Cause: FOG 1.5, and 1.6 builds from before July 2026, stored FOG_MESSAGES in the session as a string. Current code stores a list and appends to it. When a browser still carries one of those old sessions, the inactivity notice tries to append to the string, and every request from that browser returns a 500.

Fix: https://github.com/FOGProject/fogproject/pull/2080, merged to dev-branch. setMessage() now resets a non-list queue, and getMessage() drops old string entries. Pull dev-branch and re-run the installer to pick it up.

If you cannot update right away, clear the FOG cookie in the affected browser, or delete that browser’s session file. The error stops for that browser.

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

Working 👍

@Valer Hi Valer,

You can see my tutorial on using Secure boot with Shim, and my thoughts on what 2.0 means for Secure Boot with FOG here: http://forums.fogproject.org/post/158170

@sgennadi
Fixed by
touch /images/dev/.mntcheck

Can you help me with bug topic ?
Fog 1.6.0-beta.2141 remove folder with image

** WARNING: /etc/exports still exports with no_root_squash.
** Captures land as root, so moving the image out of
** /images/dev fails with ‘550 Rename failed’.
** Replace the /images/dev export options with:
** all_squash,anonuid=1002,anongid=1002

Fixed problem

It doesn’t work with 6.6.49 too and 6.6.34.

Update to fog 1.6 fixed problem

@sgennadi Should be fixed now. Sorry for the issue. A kernel testing build got in the way.

@quazz Complete!

@skipdawg02 said in Intel NUC10i3FNK Network Adapter Intel i219-V 10/100/1000 Mbps Ethernet not detected:

Thank you for the feedback. That’s strange because it should have worked with 5.6.18 out of the box. We’ll compare the config files to see what else is different.

@Quazz

@Quazz said in Git commit fcf4695 Setting up MySQL user and database..........................Failed:

@JJ-Fullmer Thanks for the instructions; that worked!
Some notes on the situation for me:

Woo Hoo!

Root password was set BUT only for ‘localhost’, but the host localhost did not have any type set (whereas the others had mysql_native_password)

I think that this may have also been the case for me. I certainly remember having set a root password but after fixing everything my only conclusion was that I must have not. But I did also notice that my mysql.user table had 3 different root users for localhost, 127.0.0.1, and 1 other I can’t remember right now. Mine were all set to the mysql_native_password plugin as well. It looks like a solution is in the works here already, but just wanted to add that note that the root problem might be the authentication problem.

@sgennadi Thanks again for the report. Obviously I have missed out on purging php-mycrypt from the fogsettings automatically when we decided to not use that package for FOG anymore last Autumn. I just tested and pushed a fix to dev-branch. Please pull the latest and give it a try.

@sgennadi ok the SX6000 IS the the PCIE/NVMe M.2 storage card, gotcha.

I did a quick google search and only found one post where they were talking about getting crc errors in their drive. There is also an ssd toolbox created by adata that can inspect the drive. I’m wondering if there is a firmware update for the drive that might address this error. Lastly since this drive is so new, there may not be a linux driver available yet to properly manage this drive so its using the generic nvme controller driver that is giving you that error.

I code it but I don’t remember it all, thanks for the assist.

@plegrand Posted to the other posting. Should be good in latest.

SVN Build 5619 problem fixed

Issue fixed