• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    finally switched from 0.32 to 1.4.4

    Scheduled Pinned Locked Moved
    General
    2
    2
    785
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tian
      last edited by

      First of all thanks for this great project. We just switched our productive system for the students computer rooms from FOG 0.32 to version 1.4.4 and want to say something about what we experienced. Currently everything is working fine.

      • The capturing and deploying is more fast and, at the same time, has a better compression (old: PIGZ_COMP = -6, new: Zstd 12)
      • The display of the deploy/capture progress in the web interface is really great
      • The new FOG client is reacting more fast after cloning and is saving some additional time
      • A date filter for imaging log and snapin log is missing (but it will be added some time later - I asked that in an earlier topic)
      • Snapin files once uploaded are now kept and are not deleted when uploading a new file to an existing snapin - (I just will cleanup the snapin directory from time to time manually - think I saw a SQL statement to list the files currently assigned to snapins somewhere in the forums to make it a little bit more easy)

      We had a minor problem with the new client:

      • The snapins (some batch scrips and sfx-archives) created for FOG 0.32 we could use without problems on 1.4.4 and the new client, except where we used reg.exe to change registry entries: without the parameter “reg:64” the registry entries were written to HKLM\Software\Wow6432Node\abc (In the batch file the path was “HKLM\Software\abc” -> without “Wow6432Node” !). Adding “reg:64” solved that and it also might be better to tell it explicitly to write in the 64bit or the 32bit part.

      Something that is also different to FOG 0.32 is the queuing behavior (when unicast group deploying a room):

      • In FOG 0.32 there always was was a fixed order which computer was cloned - in the new one its like first come first serve
        – 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
      • In FOG 0.32 the text for computers when waiting in the queue displayed the number of computer in before one (based on the fixed order?) - in the new FOG it is different
        – computers that started up with the other computers but didn’t get a free slot always display “0 before me”
        – computers that didn’t start up at beginning (WoL didn’t work, network cable was plugged out, …) are displaying the number of computers deploying plus the number currently queued as computers before one. (e.g. 14 computers deploying, 5 queued = “No open slots, There are 19 before me” for the 20th computer switched on)

      The queue behavior describe above is not a problem for us - we just have to get used to it.

      Wayne WorkmanW 1 Reply Last reply Reply Quote 1
      • Wayne WorkmanW
        Wayne Workman @tian
        last edited by Wayne Workman

        @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.

        Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
        Daily Clean Installation Results:
        https://fogtesting.fogproject.us/
        FOG Reporting:
        https://fog-external-reporting-results.fogproject.us/

        1 Reply Last reply Reply Quote 0
        • 1 / 1
        • First post
          Last post

        191

        Online

        12.0k

        Users

        17.3k

        Topics

        155.2k

        Posts
        Copyright © 2012-2024 FOG Project