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

    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
    • Storage group association again - upload mode

      Hi Tom,

      I confirm that this issue is solved:

      Re : Fog 1.5.2 ignores image storage group association

      But only in imaging mode.
      When uploading an image, “Working with node” column is always default, and image is really uploaded on default node.
      Image storage node assignment is ignored.

      Fog Version: 1.5.2.10 on all nodes

      posted in Bug Reports
      C
      Claude Girard
    • Error displaying imaging log
      Server
      • FOG Version: 33 svn 6024
      • OS: Debian stable (jessie 8.6)
      Description

      HI,

      When trying to see imaging log, for any choosen date, I have this error message:

      Fatal error: Call to a member function get() on null in /var/www/html/fog/lib/pages/reportmanagementpage.class.php on line 408

      And in apache error log:
      [Fri Dec 02 14:52:52.891372 2016] [:error] [pid 6968] [client 172.20.40.1:48602] PHP Warning: array_pop() expects parameter 1 to be array, null given in /var/www/html/fog/lib/pages/reportmanagementpage.class.php on line 341, referer: http://crim-fog.pu-pm.univ-fcomte.fr/fog/management/index.php?node=report&sub=imaginglog
      [Fri Dec 02 14:52:59.099289 2016] [:error] [pid 6968] [client 172.20.40.1:48602] PHP Fatal error: Call to a member function get() on null in /var/www/html/fog/lib/pages/reportmanagementpage.class.php on line 408, referer: http://crim-fog.pu-pm.univ-fcomte.fr/fog/management/index.php?node=report&sub=imaginglog

      posted in Bug Reports
      C
      Claude Girard
    • RE: Client doesn't add printer that was previously removed

      No I saw this issue before, I don’t know exactly when, and I only ran test today.

      I think it’s a client issue

      posted in Bug Reports
      C
      Claude Girard
    • Client doesn't add printer that was previously removed
      Server
      • FOG Version: 1.3.0-RC-25
      • OS: Debian stable 8.6 (jessie)
      Client
      • Service Version: 0.11.5
      • OS: Win 8.1
      Description

      Sorry for the long message but a lot of tests to try explaining this issue

      When adding a printer on client (Fog managed printers), printer is added the first time, but i f this printer is removed then added again in fog GUI, client log show an error and doesn’t add printer this second time.

      But if I add another printer, and add again the first one, it’s added by client.

      log messages:

      First time I add printer 1:
      0_1479726924227_printer01.jpg

      It’s ok
      Then I remove it:
      0_1479726977488_printer02.jpg

      It’s ok
      Then I add again the same one:
      0_1479727036362_printer03.jpg
      Not added and error message

      Then I add another one (in fact the same but with another driver):
      0_1479727140119_printer04.jpg
      It’s added by client but with error message

      So I add agin the first one without removing the second one:
      0_1479727227291_printer05.jpg

      Now it’ok, 2 printers on host !!!

      I remove one:
      0_1479727354203_printer06.jpg
      It’s removed but with error message.
      I have one printer again on host
      I add again the first one that was deleted before
      0_1479727483179_printer07.jpg :

      It’s ok !!!
      2 printers on host
      Then I remove both:
      0_1479727547777_printer08.jpg

      Ok removed.
      Only printers not managed by fog are on host.
      I add again the first one:
      0_1479727670150_printer09.jpg

      Not added and error message.
      I add the second one:
      0_1479727734466_printer10.jpg
      It’s added but error message about the first one.

      I remove it in fog gui:
      0_1479727900315_printer11.jpg

      And add it again:
      0_1479727969199_printer12.jpg

      Now it’ok, I have my 2 printers.

      All seems ok when there is already one fog managed printer, but not when there is no one.

      posted in Bug Reports
      C
      Claude Girard
    • Error Multicast PXE/1d0c6539
      Server
      • FOG Version: 65 SVN 6018
      • OS: Debian stable 8.6 (jessie)
      Description

      Hi,

      When I try to deploy multicast, client reboot after error IPXE/1d0c6539
      Same screen error than: https://forums.fogproject.org/topic/7872/pxe-boot-error-1d0c6539

      In apache server log, I can see:

      [Fri Nov 18 12:10:35.747856 2016] [:error] [pid 1296] [client 172.20.165.240:22393] PHP Fatal error: Call to undefined function MulticastSessions() in /var/www/html/fog/lib/fog/multicastsessionsassociation.class.php on line 56
      [Fri Nov 18 12:11:21.174003 2016] [:error] [pid 2851] [client 172.20.165.240:1025] PHP Fatal error: Call to undefined function MulticastSessions() in /var/www/html/fog/lib/fog/multicastsessionsassociation.class.php on line 56

      And when I kill multicast task in web interface from, this task is killed after some time, not immediatly, and a new error message appear in log:

      [Fri Nov 18 12:11:36.768267 2016] [:error] [pid 2960] [client 172.20.40.1:47264] PHP Fatal error: Call to undefined method MulticastSessionsManager::get() in /var/www/html/fog/lib/fog/multicastsessionsmanager.class.php on line 48, referer: http://crim-fog.pu-pm.univ-fcomte.fr/fog/management/index.php?node=task&sub=active-multicast

      posted in Bug Reports
      C
      Claude Girard
    • RE: Installation script error phpfpm

      @Tom-Elliott said in Installation script error phpfpm:

      @Claude-Girard And now? (Yes repull and try again.)

      Yes it’s ok now.
      Thank you

      posted in Bug Reports
      C
      Claude Girard
    • RE: Installation script error phpfpm

      Sorry but I said the opposite.
      Your commit changed php5-fpm for php5.6-fpm.
      since this commit debian stable install is broken.

      In Debian stable, package installed is named php5-fpm

      posted in Bug Reports
      C
      Claude Girard
    • Installation script error phpfpm
      Server
      • FOG Version: 41 SVN 6018
      • OS: Debian stable 8.6 (jessie)
      Description

      Hi,

      when updating with install script, installation stop at “Enabling apache and fpm services on boot”
      I found that phpfpm variable is expected to be php5.6-fpm
      But in Debian stable, it should be php5-fpm.

      So script stop when trying to execute “systemctl enable $phpfm”

      posted in Bug Reports
      C
      Claude Girard
    • RE: Imaging log ignore select date range

      @Tom-Elliott
      Yes I confirm
      Thank you

      posted in Bug Reports
      C
      Claude Girard
    • Imaging log ignore select date range
      Server
      • FOG Version: SVN 5982
      • OS: Debian stable
      Description

      When asking for Imaginq Log report, all dates of imaging are displayed.
      Start date and end date are ignored

      posted in Bug Reports
      C
      Claude Girard
    • 1
    • 2
    • 3
    • 4
    • 5
    • 1 / 5