Update to fog 1.6 fixed problem

@Tom-Elliott updated and working - thanks for fixing!

Great, thanks. Bug resolved!

@Tom-Elliott said in 1.6.0-alpha.1377 not showing available images on host:

Now, we have heard occasionally people have UI loading slowdowns when they’re suing FOG Client in their environment and the number of machines and check in times are just too frequent for the FOG Server to keep up and respond to all of them.

Sounds about right, I’ve turned it to 5 minutes but maybe I’ll try it at 30 and see what happens. We have about 1300 host entries (although they’re probably not all active now) but most should be off during the summer holidays. Thanks

@oelked I’m not sure I understand.

What is Persistent Groups plugin not doing that you’re hoping for?

Don’t get me wrong, a plugin building is a good time, as it helps you learn how to hook and event things in the FOG UI as well as potential interactions with other elements as possible. Just I don’t understand the scope of the problem you’re having that Persistent Groups couldn’t address.

Hello, no problem, I’ll try to describe it in more detail
Steps to reproduce

Create location

Set location name

-Storage Group
Establish

Storage Node
Omit because Node is not yet created or exists

Set Storage Node Protocol HTTP

Use inits and kernels from this node True

Add

no error occurs

Location is created.

When you create another location using the same procedure, the previous one will be overwritten
no new location will be created.

This behavior only occurs if no storage node is stored.

I noticed this behavior because I wanted to create my location structure in the master before I created all the storage nodes.

@Outer2211 Why is this a bug?

If the timezone isn’t defined (in the FOG Settings) it should default to the UTC time as it wouldn’t know what timezone your system is in.

@Tauric From the pictures we see that FOG recognized the filesystem as NTFS and should be able to resize it. It’s still strange the size was larger. Good you got this fixed by reinstalling the master to capture from. No idea what could have been wrong with the other one.

@Sebastian-Roth Thanks for the update! Again, this feature for us is more of a “nice to have” than an essential, so no immediate rush. I know all of y’all are busy!

@mronh I had a bit of time today and started looking at it. This is a bigger issue, code security involved and I wasn’t able to fix this in the time given.

I have got it on my list of things to fix when I find some more time.

@mosi This issue is fixed in the latest dev-branch version. Please update.

@AlexPDX This “bug” appears on new installs as well as on upgrades from any previous version.

This is just a minor thing because if things were right it would show the node’s kernel version instead of “Unauthorized”. It’s just not able to pull the kernel version information. Will be fixed when we find the time but this is not a show stopper.

@Mentaloid Confirmed a bug in 1.5.10. Will be fixed in the next version. Will keep you posted here.

Moving the topic to bug reports.

Code:
https://github.com/FOGProject/fogproject/blob/1.5.10/packages/web/lib/pages/snapinmanagementpage.class.php#L466
https://github.com/FOGProject/fogproject/blob/1.5.10/packages/web/lib/fog/storagenode.class.php#L200

@Sebastian-Roth Just an FYI, I ran into this again on different hardware. An HP Z2 G4 Workstation did the same thing.
There may have been more to it though, still troubleshooting a bit. My failsafe in the postdownload script to have it still join the domain through the unattend file was injected into the file, but the computer did not join the domain through that method, there may have been a different reason for that though.

Point being, there could be other hardware that weirdly doesn’t get all the variables. I sadly can’t super test on this hardware as I discovered it when imaging a production machine that I can’t take out of production for testing. But I can probably find a chance to get the fos level device info or something.

@pep Finally found some time to properly document this issue on github.

Update issue: https://github.com/FOGProject/fogproject/issues/561
Snapin issue: https://github.com/FOGProject/fogproject/issues/562

Both should be fixed in latest dev-banch. The later still needs some good testing. I just did a very basic test to make sure the default schema is being applied.

@Kleber I guess the spacing of the information printed is not working as intended when the status bar is just started. I played with the stuff a bit and came up with an easy solution that would expand the text information to the whole width but restrict the green status bar to the lower part:

statusbar.jpg

Would that be a feasible option? If not then some else with more status bar skill needs to look into this.

@premier Turns out this was a bug in the code. This is now fixed in latest dev-branch version. With the new official release on the door step your should update to 1.5.10 as soon as it’s out.

PS: If you’d kept up the topic and offered more information we might have been able to fix this way earlier.

Hi @Sebastian-Roth,
Yes, I think that the dev-branch solves the problem. I tried to install from master branch and the problem with the xinetd appeared, but with the dev-branch apparently works fine