• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. tian
    T
    • Profile
    • Following 0
    • Followers 0
    • Topics 23
    • Posts 91
    • Best 7
    • Controversial 0
    • Groups 0

    tian

    @tian

    9
    Reputation
    1.8k
    Profile views
    91
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    tian Unfollow Follow

    Best posts made by tian

    • RE: hard disk information vanishes after deploying/download from client inventory

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

      posted in Bug Reports
      T
      tian
    • RE: backing up data error

      @george1421 this should be the correct solution
      We’re also on Ubuntu 16.04 and the fog installer is failing at exactly the same point. After running the commands to alter the root user in mysql the installer runs fine.
      I think this problem re-occurs even when just updating the system by apt-get sometimes - so I am running the mysql alter commands every time after apt-get to be on the safe side.

      posted in FOG Problems
      T
      tian
    • finally switched from 0.32 to 1.4.4

      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.

      posted in General
      T
      tian
    • RE: GIT4798/4804 database problem (IDs of certain Tables increase)

      Some change between git5221 and git5283 seemed to have solved the hostMAC table problem.

      I cant see the increase anymore in git5283. Since the hostname changer service seemed to be related to it I tested the AD join and it still seems to work fine.

      I’ll test some more, but it looks good now.

      posted in Bug Reports
      T
      tian
    • RE: database connection not available

      Hi matijn,

      did you already try this?:
      https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

      We’re not on Ubuntu 18.04 yet and still running 16.04. But every time we update the OS by apt-get (doesn’t matter if upgrade or dist-upgrade) and it contains a SQL update the things described in the link above needs to be done.

      If that solves your problem and you have some sort of automatic updates turned on you could think about to deactivate them and run them regularly by yourself.

      If that doesn’t solve your problem maybe someone else has another idea.

      posted in FOG Problems
      T
      tian
    • RE: Display error in statusbar of active deployment tasks

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

      posted in Bug Reports
      T
      tian
    • Queue problems when deploying

      Hi,

      I’ve encountered some problems maybe related to the queuing when deploying a group of computers. The groups have a size of 25 and 31 computers and the problem occurs in fog versions 1.5.10.1615 and also 1.5.10.1639.

      The problem is that all the computers in the group are starting fine by WoL, booting up PXE an then successfully enter the queue to start imaging but none of them are starting imaging and display:
      “There are open slots, but XX before me on this node (in line for yy:yy:yy)”

      • XX is a higher number between 18 an 31 as far as I could see. Lower , single digit numbers seem not to be present.
      • On the Dashboard the status is like: Free: 0, Queued: 31 (or 25), Active 0
      • Under Tasks all the Imaging-Tasks are there and have the Status “Checked in” (Pause symbol)
      • in the database table “tasks” there are no other Tasks with the taskStateID 1, 2 or 3 except the 31/25 that should be there
      • The Max. Client Size of the (only) main node is set to 13 and has been tried to set to 8 or 10 but no computers started imaging

      The “workaround” to get it started is to force 13 computers manually by clicking the lightning button in the active tasks. Then the PCs are starting to get the image. What I could monitor:

      • after 13 computers are forced to image the queued comupters display: “No open slots, There are XX before me” with XX now lower numbers stating at around 15 but no lower or single digit numbers as far as I could see
      • in the group of 25 computers the last 12 automatically begin to start
      • in the group of 31 computers the status after 13 finish is:
        – Free: 0, Queued: 18, Active 0 but no new computers begin to start imaging.
        –After forcing another 3 computers to start, additionally 3 begin to start automatically and the status is: Free: 0, Queued: 12, Active 6.
        – Now the status is Free: 0, Queued: 0, Active 13 (witch seems to be normal)
        – after finishing all the tasks the status will be Free: 13, Queued: 0, Active 0 again

      Single computer deplyoment works just fine.

      Any Idea what could cause this problem? The version (1.5.10.something - I’ll try to find out the version number) we used before 1.5.10.1615 didn’t have this problem.

      Thanks.

      posted in FOG Problems
      T
      tian

    Latest posts made by tian

    • Queue problems when deploying

      Hi,

      I’ve encountered some problems maybe related to the queuing when deploying a group of computers. The groups have a size of 25 and 31 computers and the problem occurs in fog versions 1.5.10.1615 and also 1.5.10.1639.

      The problem is that all the computers in the group are starting fine by WoL, booting up PXE an then successfully enter the queue to start imaging but none of them are starting imaging and display:
      “There are open slots, but XX before me on this node (in line for yy:yy:yy)”

      • XX is a higher number between 18 an 31 as far as I could see. Lower , single digit numbers seem not to be present.
      • On the Dashboard the status is like: Free: 0, Queued: 31 (or 25), Active 0
      • Under Tasks all the Imaging-Tasks are there and have the Status “Checked in” (Pause symbol)
      • in the database table “tasks” there are no other Tasks with the taskStateID 1, 2 or 3 except the 31/25 that should be there
      • The Max. Client Size of the (only) main node is set to 13 and has been tried to set to 8 or 10 but no computers started imaging

      The “workaround” to get it started is to force 13 computers manually by clicking the lightning button in the active tasks. Then the PCs are starting to get the image. What I could monitor:

      • after 13 computers are forced to image the queued comupters display: “No open slots, There are XX before me” with XX now lower numbers stating at around 15 but no lower or single digit numbers as far as I could see
      • in the group of 25 computers the last 12 automatically begin to start
      • in the group of 31 computers the status after 13 finish is:
        – Free: 0, Queued: 18, Active 0 but no new computers begin to start imaging.
        –After forcing another 3 computers to start, additionally 3 begin to start automatically and the status is: Free: 0, Queued: 12, Active 6.
        – Now the status is Free: 0, Queued: 0, Active 13 (witch seems to be normal)
        – after finishing all the tasks the status will be Free: 13, Queued: 0, Active 0 again

      Single computer deplyoment works just fine.

      Any Idea what could cause this problem? The version (1.5.10.something - I’ll try to find out the version number) we used before 1.5.10.1615 didn’t have this problem.

      Thanks.

      posted in FOG Problems
      T
      tian
    • RE: Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify

      @AlexPDX since also the computer names are known it should be possible to add it to the database.
      But it would not make much sense because when running a Hardware Inventory task or deploying a client (where also a Hardware Inventory task is run automatically) I think the data would be removed from the database.

      To have the data in the fog database permanently I guess we have to wait untill FOS is able to get this data by itself and add it to the database.
      For now to get the SSD model data without accessing each computer physically and have it in one place is enough for us to check for possible firmware updates, run the firmware updates and re-check if the updates were applied correctly.

      posted in Hardware Compatibility
      T
      tian
    • RE: Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify

      we also have Dell computers, where the hard drive information is not in the Hardware Inventory (using fog 1.5.10.3 and AHCI in UEFI). To know the SSD models (e.g. for firmware updates) in the computers I made a snapin with a small batch file to get the information directly from Windows:

      cd %~dp0 
      
      net use x: <UNC-Path> /user:<domain>\<user> %1 /PERSISTENT:NO
      wmic diskdrive get model,firmwarerevision,serialnumber >> X:\OptiPlex_HDD\%computername%.txt
      net use X: /delete
      

      The 3 values in <> needs to be customized. and the parameter %1 is the first snapin argument and the snapin arguments are set to hidden so the password is not in the local log files.

      To combine the files I used:

      for %f in (*.txt) do (type "%f" & echo %f) >> out.txt
      

      and edit the final file manually to look better.

      Maybe this helps a little bit. It might not be the best way to do this but we now have the model, firmware version and serial number for all the computers in one file.

      posted in Hardware Compatibility
      T
      tian
    • RE: Minor display issue in "Storage Group Activity"

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

      posted in General
      T
      tian
    • Minor display issue in "Storage Group Activity"

      There seems so be a minor display issue with prime numbers involved since some results have infinite digits:
      f7d66c51-ce82-4f27-8367-64533d617539-image.png
      6d8c0983-b77b-4d02-a3f5-8672ab7e0451-image.png
      But it is not that important since everything else in 1.5.9 is working fine.

      posted in General
      T
      tian
    • RE: database connection not available

      Hi matijn,

      did you already try this?:
      https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

      We’re not on Ubuntu 18.04 yet and still running 16.04. But every time we update the OS by apt-get (doesn’t matter if upgrade or dist-upgrade) and it contains a SQL update the things described in the link above needs to be done.

      If that solves your problem and you have some sort of automatic updates turned on you could think about to deactivate them and run them regularly by yourself.

      If that doesn’t solve your problem maybe someone else has another idea.

      posted in FOG Problems
      T
      tian
    • Minor display error in fog 1.5.4: progress bar when capturing/deploying

      Hi,

      we just updated from fog 1.4.4 to fog 1.5.4. As far as we tested it looks fine but the progress bar when capturing/deploying an image behaves kinda weird:
      0_1531401782272_2018-07-11 - Fog Progress 01.png 0_1531401792028_2018-07-11 - Fog Progress 02.png 1_1531401792028_2018-07-11 - Fog Progress 03.png 2_1531401792028_2018-07-11 - Fog Progress 04.png 3_1531401792028_2018-07-11 - Fog Progress 05.png
      At beginning all the information is squeezed in the little green status bar and after some progress there are more readable information. It’s the same in IE and Firefox.
      (Capturing was tested on an older machine with higher zstd compression so the speed/time shown there is ok)

      It is not that important but sometimes made it more easy to spot a computer with a slower network connection directly.

      Thanks

      posted in Bug Reports
      T
      tian
    • RE: Image Size: ON Server 0.00 iB - Was working but now its not.

      @ravigon how about the values of igaPrimary (wonder why I wrote igaGroup …)?

      What is the ID in “Storage Management” -> “All Storage Nodes” -> your storage node (normally “DefaultMember”) -> “Storage Group”? And are the other settings there correct?
      Could you also check the Image Size log in “Fog Configuration” -> “Log Viewer” if there are any errors?

      posted in FOG Problems
      T
      tian
    • RE: Image Size: ON Server 0.00 iB - Was working but now its not.

      The Image Size Service seems to run every hour and check the image sizes (Fog 1.4.4):

      ...
      [10-18-17 9:21:51 am] * Starting Image Size Service.
      [10-18-17 9:21:51 am] * We are group ID: 1. We are group name: default
      [10-18-17 9:21:51 am] * We are node ID: 1. We are node name: DefaultMember
      [10-18-17 9:21:51 am] * Finding any images associated with this group as its primary group
      ...
      [10-18-17 10:21:51 am] * Starting Image Size Service.
      [10-18-17 10:21:51 am] * We are group ID: 1. We are group name: default
      [10-18-17 10:21:51 am] * We are node ID: 1. We are node name: DefaultMember
      [10-18-17 10:21:51 am] * Finding any images associated with this group as its primary group
      ...
      

      But we once had a problem that its was not displaying the size for one or two images. The solution was that in the table “imageGroupAssoc” the value of igaGroup (?) was not “1” (I think it was 0).
      After manually changing this value to 1 the next time the Image Size Service was running all of the images was showing the “Size on Server”. Dont’ know what caused this but we didn’t have this since then anymore.

      So I think it’s worth checking the imageGroupAssoc table in the database and storage settings in FOG.

      posted in FOG Problems
      T
      tian
    • RE: backing up data error

      @george1421 this should be the correct solution
      We’re also on Ubuntu 16.04 and the fog installer is failing at exactly the same point. After running the commands to alter the root user in mysql the installer runs fine.
      I think this problem re-occurs even when just updating the system by apt-get sometimes - so I am running the mysql alter commands every time after apt-get to be on the safe side.

      posted in FOG Problems
      T
      tian