FOG ubuntu image fails to update database

[Tom Elliott]

@mashina The history table issue’s I’m seeing appear to be legitimate:

You wouldn’t be able to deploy snapins to a host if the snapin isn’t associated to a host. That said, I don’t know exactly what deploy type, nor what actual “version”

while I can checkout the commit hash, it’s just a hash and not somethign I readily memorize.

your exact version of FOG would show on the bottom right of the UI when you login.

I believe your commit hash relates to working-1.6-beta.2273 or something like that.

That’s within 2 of the actual “current” but also notably it is within the save function rewrite. Which we definitely see in the history writing.

It appears like you’re trying to do a Multiple Snapin Task and this is failing?

[mashina]

This post is deleted!

[mashina]

@Tom-Elliott

FOG version: 1.6.0-beta.2273

Let’s ignore the Snapin errors for now. The error is thrown at the end of the Multicasting image.

[Tom Elliott]

@mashina Okay so just so I fully understand:

The database is successfully updating, but for some reason it’s not returning the exit code correctly.

I don’t know why (I do want to fix the error you’re seeing but it doesn’t appear to be causing a true “problem” just causes the machine to appear like there is a problem when after the reboot actually occurs), however all is perfectly fine just it might take a minute or 2 longer to actually get into a bootable/workable system?

So your issue is not at all related though the messaging is similar (Failed to update database) but its failing because it believes the task no longer exists (which indeed is true although only in the context that it is successfully completing the task, but not sending the expected code FOS is waiting for.)

(I know I’m seeming to ramble, just trying to get my thoughts out and help steer the issue toward whats actually wrong so we know where to look to hopefully fix it.)

The database is updated, but because FOS doesn’t get the code it expects, it thinks it needs to retry. The retry has nothing to associate to any more (Hence the no active task.)

[Tom Elliott]

@mashina I have made an update after being able to replicate the problem you described.

Issue it seems was an error 500 occuring on line 329 of the taskingelement.class.php element because it couldn’t find a relevant imaging log.

I’ve added code that seems to be able to address this though not sure what is actually wrong otherwise. WIth the patch I made things seem to complete okay so I think it’d work good for uni and multicast tasks if you’d be willing to update and test?

[JGeear]

This post is deleted!

[JGeear]

@JGeear It appears there is a issue with the UI after all. I tried updating the password there are extra characters added.

[JGeear]

@JGeear Updating the password of the storage node fixed the issue. Still I would like to know how these passwords were changed??

[mashina]

@Tom-Elliott

Yes, it looks like multicast is working correctly. Thank you for the support.

I also want to add a few details to clarify our setup.

A few months ago, I was running version 1.15.10. Since we are developing an API-based solution, we decided to upgrade to the latest development branch.

During the upgrade, I noticed that when the message appeared telling me to visit /fog/management to update the database, no database update actually took place. Instead, the web interface took me straight to the FOG login page.

If I understood that correctly, it suggests there were no database schema changes between 1.15.10 and 1.6. However, that later led me to question my understanding, because several issues arose afterward, including the one mentioned in this post: “Database Update: Failed.”

I will add the other issues to the forum soon and link them here.

[mashina]

@Tom-Elliott Absolutely. I will get back to you in a few hours.

[mashina]

This post is deleted!