• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Claude Girard
    C
    • Profile
    • Following 0
    • Followers 0
    • Topics 15
    • Posts 87
    • Best 6
    • Controversial 0
    • Groups 0

    Claude Girard

    @Claude Girard

    6
    Reputation
    1.2k
    Profile views
    87
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    Claude Girard Unfollow Follow

    Best posts made by Claude Girard

    • RE: Some clients disappear from web interface but are still present in databse

      @Matthieu-Jacquart said:

      I updated and restore database from last save (last week-end), and 1 hour later at least 3 hosts disappear, on 3 different groups, I made no changes…

      edit : we forgive you, you all make great job 😉

      I can confirm this bad news.
      I wanted to control my database, and I made this request in phpmyadmin:
      SELECT * FROM hosts WHERE hostID NOT IN (SELECT hmhostID FROM hostMAC)
      It returned 93 results
      10 minutes later, the same request returned 101 results.
      No operation made on fog interface between the requests.

      Do I need to upgrade client too ? I don’t think so, some disappeared computers have legacy client installed

      posted in Bug Reports
      C
      Claude Girard
    • RE: Some clients disappear from web interface but are still present in databse

      @Claude-Girard And good news:
      My sql request:
      SELECT * FROM hosts WHERE hostID NOT IN (SELECT hmhostID FROM hostMAC)
      hours ago !!!
      returns 0 rows since last fog update,

      posted in Bug Reports
      C
      Claude Girard
    • RE: Some clients disappear from web interface but are still present in databse

      Hopefully by the time i get in to work tomorrow I can put a solve setting on this thread.

      Yes I think you can.
      Hosts are still here !!!
      I can’t reproduce group issue, during 1 hour I delete hosts from groups, include them in existing or new groups, modify by group image association, service settings, active directory, and snapins.
      I lost 1 member in a group only one time, 66 members at start, and 65 after modifying settings in the group, not sure but I think after active directory settings.

      I decided to do that because I thought that after this bug my database was in an inconsistancy state.

      I sent these 3 requests to my database:
      SELECT * FROM hosts WHERE hostID NOT IN (SELECT hmhostID FROM hostMAC)
      Before update, I had a lot of rows in result, and growing. But now it’s ok.

      SELECT * FROM hostMAC WHERE hmhostID NOT IN (SELECT hostID FROM hosts)
      Never had result, was ok and is still ok

      SELECT * FROM snapinAssoc WHERE saHostID NOT IN (SELECT hostID FROM hosts)
      Returned a few rows in result, maybe not directly due to this bug, maybe this table was corrupted before.

      I think that tables refer to hosts by Mac adresses, except snapinAssoc table. Is it right ?
      So with these 3 requests, I can find bad hosts and bad snapin assoc, and I delete them from database.
      But maybe I forgot one or several tables to check ?

      Thank you for you job !

      posted in Bug Reports
      C
      Claude Girard
    • Rev 5968 Unable to locate MBR

      Hi,

      Rev 5968 but this issue seems to be present since Rev 5909 commit 2872cf5e99f0cba6f3cdcbe18d8dd1ab40347b4c

      When deploying an image, fog doesn’t find mbr file.
      In deploy debug mode, mbrfile is empty.
      I saw this issue with os type = linux. If I change this in os type= windows 8.1, mbr file is found.

      In funcs.sh, test on os type is made only for 1, 2 , 5 , 6 ,7 and 9 os type.

      posted in Bug Reports
      C
      Claude Girard
    • RE: Rev 5968 Unable to locate MBR

      I don’t know from which rev, but this issue is solved

      posted in Bug Reports
      C
      Claude Girard
    • RE: Imaging log not displaying logs

      @Tom-Elliott said in Imaging log not displaying logs:

      Confirmed and fixed in latest.

      Yes but now all imaging tasks are seen, not only those between start and end date

      And in snapins log, only today log is correct.
      With a start and end date, even if they are the same, result is not at specified dates

      posted in Bug Reports
      C
      Claude Girard

    Latest posts made by Claude Girard

    • RE: Storage group association again - upload mode

      I forgot to precise version: 1.5.2.31

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      @tom-elliott
      After doing the same tests, this time everything is ok.
      Thanx

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      I don’t know if this issue is linked to the initial one, but now capture and deply, in unicast mode or in multicast mode, are working fine.
      So, initial issue can be marked as solved.

      Maybe should I open a new subject, but , when my image storage group association is like this:

      0_1526996712464_fog01.png

      My images storage association are ok:

      0_1526997107272_fog03.png

      And I want to remove default one because I have only one storage group for an image.
      So I select it and delete it:

      0_1526997127242_fog02.png

      And now all images but the one I modified are linked to default storage group.

      0_1526997182902_fog04.png

      An finally, if it can help, I could see that just after modifiyng storage group in image association, I had only one line in database table, the one I was modifing.
      The others came after, with 1 and 1 in IgaStoragegroupId and igaprimary

      So I think that imageGroupAssoc table is dropped when asking to modify one image, and settings of other images are lost.

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      Ooops, I replied too fast. Not solved !!!
      My storage group association is again default for all my images.
      I’ll try again several tests to see after which one I can replicate this issue.

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      @tom-elliott
      In my previous post I meant that in Fog gui, list all images, in “storage group” column, all images was on default.
      And I verified in imageGroupAssoc table in database, IgaStoragegroupId and igaprimary were 1 and 1 for all lines.

      But now, this issue seems solved.
      I tried unicast deploy, capture, and multicast deploy, with Image storage group association = default + a primary node.
      Then I deleted default one in image storage group association, and I tried again same tests, so with only one storage group associated.

      And now all is fine.
      Thank you

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      Bad news.
      I saw that all my images were changed to default group and only this one, since upgrade to V 1.5.2.26

      So I think you should revert to previous code, before this fix.
      This issue is really annoying 🙂

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      Finally, I had a few time today, and I tried 2 debug task, one in deploy mode, the other in capture mode.
      But I don’t know if it will help you.
      In first screen capture, deploy mode, IP address 172.20.40.16 is the good one.
      In second screen capture, in capture mode, IP address 172.20.165.12 is bad.

      I modified storage variable, replacing 172.20.165.12 by 172.20.40.16, and running fog.
      unfortunately, in fog interface, storage node was again the bad one.

      0_1526653999106_IMG_20180518_161042.jpg

      0_1526654081308_IMG_20180518_162210.jpg

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      Unfortunately no, I didn’t see any change after upgrade to V 1.5.2.26
      Worst, I discovered that the issue in deploy mode was there again, but in multicast.
      I didn’t try multicast deploy with previous versions, so I can’t say if this bug was already present.
      I’ll try different debug mode next week, to see if I can help you better.

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      I have tested again, first by downgrading Fog to 1.5.2 version.
      Then upgrading to 1.5.2.11 version.
      For both versions my image storage group is:

      0_1525189971596_v-all-image-nodes.png

      First V1.5.2:

      Capture mode: node is correct

      0_1525190044754_v1.5.2-capture.png

      Deploy mode: node is bad

      0_1525190120206_v1.5.2-deploy.png

      This issue was solved, so now with 1.5.2.11 version:

      Capture mode: node is bad

      0_1525190215822_v1.5.2.11-capture.png

      Deploy mode: node is correct

      0_1525190259962_v1.5.2.11-deploy.png

      posted in Bug Reports
      C
      Claude Girard
    • RE: Storage group association again - upload mode

      I have only one node by group like that:

      0_1524596930728_storage-nodes.png

      And my image file is associated with my group “MP”,

      0_1524596945876_image-storage-group.png

      When I deploy, image is read from correct node (mp-fog), but when I upload, same image is captured to default group, Defaultmember node.

      posted in Bug Reports
      C
      Claude Girard