@tian I’ve got exactly the same problem. The initial 10 queue items complete, but the next batch won’t start. I have to click the lightning bolt icon in the task list to force it to start. Am running up to date FOG software on a fully patched Ubuntu server.

@sebastian-roth thanks for the information. Since everything else is running fine there has been no need to try the dev-branch. It’s good to know that it will be included in the next release.

@tian Trying to catch up with older bug reports. Sorry for the late reply.

As we moved to bootstrap this is just how those progress bars look like. Probably not as easy to change.

I am marking this solved - won’t add.

@tian said in finally switched from 0.32 to 1.4.4:

when all computers are starting simultaneously there are more deploying at the same time than allowed in the storage node’s “max clients” option: e.g. 13 are allowed and it has been 14 to 16 for the first deploy batch of a room, the later computers normally will start when it is below 13 again but it can happen that 2 will start at the same time again (depending on the moment they try to check in I think) and it might be 12->14 again

That’s a known problem - it’s caused by a race condition. It is a minor problem since everything still works and sort-of stays within the boundaries.

@Tom-Elliott Thanks for your hard work - good to know it will be there in a future release.

@Tom-Elliott Thanks for the solution. I’m using the new user.class.php now (renamed the not working one before) and the login with the previous user name (only letters and one “-” in the middle) is ok again.

(Since we don’t use the ldap integration I didn’t test the ldap.class.php)

@Sebastian-Roth Thanks for the explanation.

dmidecode is not available by default in OSX it seems. I started the fog debug mode and got the following:

# dmidecode 2.12 # SMBIOS entry point at 0x8cd15000 SMBIOS 2.4 present. 51 structures occupying 2746 bytes. Table at 0x8CD14000``` The message " Invalid entry length (0). DMI table is broken! Stop." only appears at the end of the dmidecode command.

@Tom-Elliott Today we tested with Version 1.3.0-RC-1 (SVN Revision: 5935) and the “Chainload failed” message still appears with exit type “EXIT”.

But since the exit type “REFIND_EFI”works, we’re OK with that.

@Wayne-Workman THey base on the time. If all of them have the exact same checkin time, they will ALL say 0 before me, because it doesn’t know which is which, (of which I’ll likely fall back to the ID of the tasking).

For now it’s working but a bit odd.

@Tom-Elliott @Sebastian-Roth sorry for the late reply - I now tested it with git6907 and the display is fine now.

Also thanks for correcting the hard disk related prefixes to binary.

@Tom-Elliott @Sebastian-Roth I just did a quick test with svn5107. Right now a deploy task has been running and the hard disk information has been kept. Tomorrow I’ll test some more and report back if there is still something wrong, but it looks like it is OK now.

Thanks everyone for fixing this.

@Tom-Elliott Thanks for fixing the two other bugs also. I’m on git5662 now and it is working again.

And something other worth mentioning:
It is a great change that the state in the snapin log is now displayed as “complete” instead of “4” - this makes things more clear.

@Tom-Elliott Thanks Tom.

Uploading an image with “Multiple Partition Image - Single Disk (Not Resizable)” is running right now.
Guess it solved the problem. If there is any problem at the end of imaging or when downloading I’ll report again.

Service settings are now functioning again. Thanks for reporting.

Yes they can be ignored. I am more interested in figuring out why they did not exist but that’s all that schema did.

@Tom-Elliott Thanks - git5135 fixed the snapin log:

“active snapins” are added/removed correctly -> OK snapins are running ok on the client -> OK the snapin log displays the database content correctly again (it added the new snapin tasks additionally to the ones from yesterday)** -> OK** the snapin status still is reported as “4” in snapinJobs and snapinTasks -> OK? no “sjHostID 0” entries in snapinJobs are created from hosts only started up/running -> OK

@Tom-Elliott Thanks for the fix. It works now (git5040).

For the Database changes - they seem to be OK too:

snapinAssoc: removed snapin associations are deleted from table, Auto_Increment not increased hostMAC: the table entries for the hosts the snapin has been removed have been rewritten -> new hmIDs, Auto_Increment increased by the number of hosts in the group

@tian Thank you for reporting back! Posts like these make all the difference to future readers!

Yesterday after getting SVN3696 working like described before i run the apt-get with dist-upgrade. But no updates have been found anymore.

Today I updated from SVN3696 to SVN3710 and was able to install it without any problems.