@AUTH-IT-Center Sorry moved these items to a new topic.

I want to get this addressed, but this is different from the double quotes issue:

Also:

please hit up your sql database:

SELECT * FROM fog.history;

likely it will see the latest entry of something along the lines if:

Task ID:  Name: Single Snapin Task - test321 has failed to save. Error: Save completed but no valid ID was assigned (insertId=0). Possible duplicate-key update or missing auto-increment.

This is what I’m seeing when I try to create a single snapin task (i’ve not tried with all-snapins yet, but one thing at a time. I am working to fix it, just trying to narrow down the why.

@AUTH-IT-Center I added another update but the error you’re seeing is a little strange because it should’ve bene addressed, I don’t know. The min() item is saying it requires a value and the approach I took was to check if there is data in the array, pass it to the min funciton otherwise set it to null (which should work if true)

Of course i don’t have much time to dig deep into this today, but my testing seemed to work without much issue.

Let me see if I can create a host without an image associated, tie a snapin and make a snapin task.

Okay thanks for that, that helped me fix that particular problem and address another elephant I didn’t realize still existed:

Non-Imaging tasks should not require an Image to create a task - which is partly (i believe) why you saw that error.

I’m only guessing here that this was a machine that did not have an image defined to it? If not there’s another rabbit hole I’m not sure I’m ready to dig into right away, but I did add corrections that non-imaging tasks shouldn’t require an image being set on the host level to create the tasking in the first place as well added some failsafes around that particular error:

$assocID = @min((array) $assocID);

Was the error it was hitting at line 496, basically with PHP 8, they made min function require a value and if assocID is empty (set just earlier) that’s why you were seeing an error. The assocID here specifically represented the image association on a storage group.

I corrected this specifically by setting assocID to null if there’s nothing in the returned assocIDs previously.

Apologies for the long winded answer.

@AUTH-IT-Center Since it’s writing a 500 can you provide the php-fpm www-error.log (if redhat based or apache2.log if debian)?

There’s likely some syntax issue I’m unaware of:

For the htmlspecialchars it’s only display representation:

When the HTML forms are built, we encode things which allows the fields to display correctly, and when you hit safe we decode them to ensure they’re stored in the DB correctly.

This leads me to believe this isn’t really the problem but there’s some other syntax issue that I may have missed/added unsuspectingly?

@The-Dealman Awesome thank you! and we did publish 1754 specifically due to this issue (manually running the automated processes just in case your org is worried at all )

@jmeyer As a matter of fact, the task requirement for storagegroupID has already been fixed it seems, I am on 2267 for working-1.6

Can you please try updating and see if you still have the same issue and if so, accurate/current screenshots of those errors please?

So thank you I can fix the requirement of the storagegroupID (likely meaning we can remove the need for the storagenodeID - which means I need to figure out a way to dynamically change required fields based on the task, but that’s not a major problem I can think through quickly.

If you can post actual screen shots/images of the error that goes a lot further because what you did made me just discard things because somehow you showed a 1.5.10.1688 image saying “it’s this problem” but that problem isn’t really true. Your issue is completely different (albeit from your side it may seem similar)

Context actually matters with these things otherwise I go down thinking “Yeah, no wonder it’s not working, they say they’re on working-1.6-beta.2262 but the image I see says totally different thing, that must be the issue.”

@jmeyer I’m seeing conflicting information. You say you installed working-1.6.0-beta.2262, but then your picture shows 1.5.10.1688.

I believe we just released 1.5.10.1754 but that shouldn’t matter if you’re running working-1.6.

The warnings you’re seeing in the logs seem unrelated and are just that, warnings, - they’re not directly breaking anything just a separate cause (which I realize may feel like they’re one in the same - just I know these specific things are not.)

Please get your mysql up and running and output:

SELECT * FROM history;

Most likely this will contain some information I may have missed in an attempt at better error and failsafe handling.

Particularly the the last few items that correspond to the time you see either of these issues.

The first thing I’d take a look at is why your FOG Server thinks its 1.5.10.1688 when you believe it’s working-1.6-beta.2262.

@alexamore90 I think you’re asking for something like this? https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins?_=1768874256297

@The-Dealman they auto build every month. On the 15th of the month. So technically it already is backported. Dev-branch is the branch meant to fix the bugs reported. These then roll up into stable automatically on the 15th.

@The-Dealman Can you switch to dev-branch and do a pull and test?

Unfortunately I’m working out of two different branches as my focus has been mainly on working-1.6 and I had to fix a similar issue there. Forgot to do it as part of when the working-1.6 was reported. My apologies.

This should be addressed in the latest of dev-branch.

@Alun Couldn’t you look at the release date (December 15 2025) against the latest release of Ubuntu before December 15 2025?

Since we can’t possibly fix for future versions until those future versions actually exist.

I’m not just trying to be smart, but I think that was Ubuntu 24.

Is there a problem or you’re just asking the question?

@Clebboii Are you still seeing these issues?

We did find another (separate but similar) bug relating to Phantom tasks as well, so you may need to update to the latest and this should be addressed too.

Please let us know, thank you!

@sgennadi Can you please provide more information on this?

Is this still happening in the latest 1.6?

I’m asking mainly because I’m not sure what is happening:

What I think I see:
On image create task gets ready to complete after doing the data gathering:

It correctly removes the /image/<imageNamePath>
It does NOT move /images/dev/<macaddress> -> /image/<imageNamePath>

So a work around exists (as annoying as it may be) that you can manually move the /images/dev/<macaddress> to the image name and that will still work though I agree it should be automated.

I believe 2141 may have been early on in the moving toward SSH purely for handling image moving and I would hope that this problem is addressed in newer files.

@FOGBreaker101 over the last couple of days we found there was a bug in fog that could create required items inappropriately. We made some code to try to prevent that altogether, as well as fixed the issue directly causing the bug. This showed us some other bug(s) and likely we’ll get more reports of new bugs yet. But hopefully this helps explain the why it happened.

It did get us to make better logging and functionality of the pdodb class so all in all a worthwhile improvement.

@FOGBreaker101 Please update and try again.

I am not 100% sure what the actual error is, but what I’m seeing from a DB standpoint there is a totally different issue occurring and that I could work around.

Can you try to update and try again? If you’re still having an issue and I can try to take a look.

@Tom-Elliott Figured it out, please update and try again, apologies:

Trying to account for bad information in the DB and it was stated that imaging log required type and finish time, since these aren’t defined at check in, they shouldn’t be required.

THanks for letting me know.

@sgennadi Can you show me yoru history table?

it should show what’s happening or some piece of information relating to image log creation.

@sgennadi please pull and try again.

It seems theres a new requirement for NFSLastMemberID which wasn’t being set in the create tasking. While it should’ve errored appropriately it was being hidden. The History show a “succes” entry but with a 0 id which isn’t any good anyway.

Cleaned up the PDODB class a bit to help more clearly state what the issue is and cleaned up a couple other things as well.

@Infojoe They are one in the same lol and you’re welcome.