@astrugatch Okay thanks and sorry there was that issue.

Can you pull and try installing again?

Thank you!

@maxcarpone I would ask you, if you’re daring/willing (it’s considered beta but uses the same pipeline with a lot more modern ui, I need people testing, and Fog_newb can likely attest the new ui look and feel though I think they ran into an issue and needed to get functional right away so the snapshotted back)

Upgrade to working-1.6.

I have a goal (along with @JJ-Fullmer ) to try to get working-1.6 to be master/stable branch by October.

1.6 has been “stagnant” since around 2017 and was in relatively stable grounds back then even.

With AI (as you undoubtly can see I’m using to help drive some things) it’s allowed us to get a lot more coding/refactoring and will hopefully present a much better experience of things on the UI side. Without testing I cannot fix UI bugs though.

AI can do some cool things, but it doesn’t know what “wrong/right” looks like, and JJ and I are only 2 people.

There are others on working-1.6 but more feedback is always good.

@Jeremy That mount error is our bug. FOS was passing NFS mount options without
actually telling mount it was NFS, so when the storage path doesn’t come
through, busybox falls back to trying every local filesystem in turn and each
one rejects nolock — the ext2/ext4/vfat lines were never really involved.
Fixed and merged, and there’s a new experimental build below with it in. Test it
when you get a chance and let me know how it goes.

Two things when you do. Add isdebug=yes to your bootargs — mode=debug isn’t
our debug switch, so right now you’re getting rebooted back to U-Boot before you
can read anything. And send me the output of these from the failing boot:

uname -a cat /proc/cmdline cat /proc/filesystems

Your error listed f2fs, and our arm64 kernel is built without f2fs and without
module support, so it can’t have produced that. I think that boot was running
your kernel8.img with our init rather than our kernel — which would mean we
still haven’t actually tested the kernel fixes on real hardware.

wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_Image wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_init.cpio.gz wget https://github.com/FOGProject/fos/releases/download/EXP_20260826-143004/arm_dtbs.tar.gz

All three are from the same build, so there is no mixing them up with what you
have now.

Thank you Tom, I got updated to Working-1.6beta.4105 and that issue is fixed. Not sure if it is just this particular install or not.

Some Issues I am noticing is Host registration is not showing up whether from the fog menu or the client. I can see it is trying but does not appear to be writing to sql.

36f170d3-0a3b-4de3-b327-4233bc53534b-image.png

Deployment: Getting invalid mac errors it seems on all devices. The task seems to be populating alright.

No viable macs to use

@Tom-Elliott Thanks Tom. 1.5.10.2344 seems to be capturing fine. No additional null tasks were created and the PC had no problem checking in and starting the capture.

I’d swear, not only with this version but the earlier ones that were malfunctioning during check in and creating additional tasks, I had to create the task twice. Like I went through the process of setting up a capture but nothing showed up under tasks then had to do it again.

I can’t seem to duplicate it though. Setting up a 2nd capture for the laptop, I only had to do it once (and no additional null tasks were created).

PC finished the capture no problem and laptop checked in and is capturing now. Looks like 2344 did it!

Thanks again.

Resolved. I’m sharing FOG with as many people as I can. Love this project!

And I can’t add any hosts—whether via the web interface or by booting over the network—; ultimately, the new host doesn’t appear in the database…

Failed to query: Error: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: '' for column `fog`.`moduleStatusByHost`.`msHostID` at row 1 Error Message: Error Code: "22007", Error Message: ["22007",1366,"Incorrect integer value: '' for column `fog`.`moduleStatusByHost`.`msHostID` at row 1"], Debug: SQL: [629] INSERT INTO `moduleStatusByHost` (`msHostID`,`msModuleID`,`msState`) VALUES (:hostID_0,:moduleID_0,:state_0),(:hostID_1,:moduleID_1,:state_1),(:hostID_2,:moduleID_2,:state_2),(:hostID_3,:moduleID_3,:state_3),(:hostID_4,:moduleID_4,:state_4),(:hostID_5,:moduleID_5,:state_5),(:hostID_6,:moduleID_6,:state_6),(:hostID_7,:moduleID_7,:state_7),(:hostID_8,:moduleID_8,:state_8),(:hostID_9,:moduleID_9,:state_9),(:hostID_10,:moduleID_10,:state_10),(:hostID_11,:moduleID_11,:state_11),(:hostID_12,:moduleID_12,:state_12) ON DUPLICATE KEY UPDATE `msHostID`=VALUES(`msHostID`),`msModuleID`=VALUES(`msModuleID`),`msState`=VALUES(`msState`)

Just fyi, I resolved my issues with this by turning off DMA protection in the bios/uefi.

@Tom-Elliott I did update to version 1.6.2254 and the first multicast that worked was the first one I tried after the upgrade. This second one is now hanging like the one that prompted this thread.

Where in the logs can I find any clues?

Encountered the same issue, version: 1.5.10

I can successfully capture the image and then see the size of it in the web panel but then it’s not being moved to /images/ by fog. Requiring me to move them manually which works but I’m kinda concerned.

FTP works fine even though I am afraid I don’t understand why I need FTP to move some files inside a directory on a singular server.

@Tom-Elliott thanks Tom - using the excellent fog-docker from 88fingerslukee - so will wait to hear his response

@Strahd Have you been able to make progress?

@Tom-Elliott
The fix worked perfectly! The menu issue is now resolved.

Thanks for the support!

@Tom-Elliott Hi! I updated my FOG server to latest beta-branch version: 1.6.0-beta.3197. I also updated my storage node to 1.6.0-beta.3197. This fixed the invalid path issue I was having. Thank you for the help!

1a0e5491-b776-49fe-9fbf-d2bc40087f78-image.png

@Tom-Elliott Tom, looks like everything has been resolved after going from 2144 to 1.5.10.2218! No errors and I was able to capture no problem. Thanks

@toschulz So I suspect the problem is due to a divergence of db schema between dev-branch/stable + working-1.6

If you can update yoru Mysql directly:

sudo mariadb -u root fog (if no root password of course - if you have a root password add -p

UPDATE schemaVersion SET vVersion=0;

Then refresh your screen, click the install/update, and hopefully the error will go away.

The way the schema is configured is it will attempt (idempotently) to rerun every single SQL query in the schema chain.

This should fix the problem you’re seeing.

I believe there’s a column on the login history piece being requested that may just simply be missing which would cause the issue with datatables.

I have figured out the issue. I was looking in the wrong place in BIOS for the secure boot setting which was on. Turning off secure boot fixed the process which runs perfectly now.

@Tom-Elliott Hello Tom yes I have installed the compatible Fog client from the Fog server on the reference machine, sys prepped and captured the image and now I am deploying.