SOLVED FOG 1.5.0 RC2 Cannot Delete Image From Storage Node/Group

  • Server
    • FOG Version: 1.5.0 RC2
    • OS: CEntOS 7
    • Service Version: 0.11.12
    • OS: Win10 & Win7

    Just upgraded from 1.4.2 to 1.5.0 RC2. FOG and 2 Storage Nodes, all on CentOS 7, location plug in installed. Each server in its own location and site. Sites separated by firewalls and static VPN WAN paths. Each FOG server is in its own storage storage group.

    I had a bad replica of an image at one site. I attempted to delete the image from that site/storage node with the new UI by selecting the squarish CheckBox and pressing the RED Remove button. The system paused and then posted a dialog box that the image had been updated, but the display remained the same. I then went to a different ‘tab’ on the same image UI (like Members, for example) then back to the Storage Group Tab, but all 3 storage groups remained in the list. While the UI is a bit unintuitive on this screen, it’s clear the squarish CheckBoxes apply to the Remove button given that the only one of the circular RadioButtons can be selected at a time, and the Remove button have ‘Remove Selected Groups’ next to it.

    To be sure the problem really exists, I then went to the Members ‘tab’ and removed any host that was on that site, that might be blocking the deletion of the Storage Group from the Image definition. This had no effect. I could not delete an image from a storage group using the UI.

    I have yet to try to add a new image and see what happens.

    If you need screenshots, just let me know.



  • @mjaskowski Would you care to share a copy of your database with me so I can figure out what the issue is? Don’t post it here, PM me.

  • @tom-elliott I’ve got the same exact problem happening as @Jim-Graczyk and I’ll try to be more descriptive.

    I have an image stored on a storage group “3r” but when I select the image and view its Storage Group two groups are listed “2r” and “3r” with a radio button check mark beside 3r, which I take to mean primary although there is no header text for that column so it’s not clear what that check is for. The available options include check boxes beside Storage Group name and beside each listed node, in this case 2r and 3r, and an Update primary group “Update” button and a Remove selected groups “Remove” button.

    I’ve confirmed that the image does exist in both images folders on both nodes 2r and 3r but I only want it to occupy 3r, the image’s primary storage group. When I directly remove the image by deleting it from the 2r images folder it gets copied back, thereby suggesting an accurately reflected status on the Image Management/Storage Group page. When I select the checkbox beside 2r and click the Remove button an Image Update Success “Image Updated” popup appears but 2r never disappears from the list even after refreshing or navigating away and back again and the image still gets copied back to 2r if deleted directly.

    Each node is set as a Master Node with its own Storage Group; node2r:group2r and node3r:group3r

    I actually have this occurring with several images but not all, most images are fine being listed in only one storage group and existing in the one images folder. It appears something is gummed up with the database records that the GUI cannot correct.

    Additionally, but a separate problem is, I have images in the database listed in 2r that are really in 3r and vise versa and I wish I could just change the reference via the GUI.

  • @Tom-Elliott Update Worked! Location plugin was installed when the update was made. Was able to disassociate several images from several storage groups.

    We can consider this resolved.


  • Senior Developer

    Fix is now in the working branch. I accidentally pushed into the dev-branch as well, so you could just do a pull from dev-branch and reinstall and revel in the success. (Hopefully).

  • Senior Developer

    Definitely not a mysql ACL/permission issue as we were able to delete entries from that table by hand. Tom got a dump now and seems to have found what is causing this. He’s working on a fix.

  • Senior Developer

    @Jim-Graczyk As far as I remember we only did SQL queries but did not try to delete… should have. Please contact me in chat so we can try…

  • @Tom-Elliott

    Sebastian, I know we delete records when we were looking at the install here over the weekend. Would any of the deletes we did apply to what Tom’s talking about?


  • Senior Developer

    @Sebastian-Roth If I were a guessing guy, the user used to “manage” fog at the DB level is allowed to “create/update” but not allowed to DELETE. (just a guess, and the db dump probably wouldn’t be able to tell me this or not.

  • Senior Developer

    @Tom-Elliott I remoted in with Jim the other day. Though we could not fix this issue I might add some information here.

    The imageGroupAssoc looked alright (didn’t check all the others). Using the web UI we were able to add a storage group assoc to an image (one that only had two so far). But we were not able to remove this assoc or any other in his setup using the web UI. As Jim reported removing the location plugin didn’t fix it either. As well I tested with location plugin but still can’t replicate the issue. Hopefully you can find something in the DB dump!

  • Senior Developer

    @Jim-Graczyk Can you get a backup of your sql and send it to me via email (hit me in chat to send me email please)?

    I would like to take a look at the actual DB, and see what/why things are going funky here. I suspect some sort of strangeness left in the DB. That or the DB user isn’t allowed to modify that portion of the database? I’m just speculating. Hopefully the config file would tell me more.

  • @Tom-Elliott Location Plugin is uninstalled but still cannot disassociate an image from a storage group.


  • @Tom-Elliott

    Doing so now. And FYI - I had uninstalled the Locations Plugin and reinstalled it this morning - before I ran into problems. I was AFK some and will be again in 45 mins. I hope Sebastian was able to record what he and I did today over WebEx. I don’t know that I can provide sufficient detail to assist you. I haven’t seen any posts from him since we concluded the WebEx.

    One thing I did want to tell :

    I have a FOG and 2 Storage Node Servers. I have 3 Locations defined and 3 storage groups with one FOG server in each site and storage group. If I shut down one of my Storage Nodes or Make a new storage node, when I click on the storage icon in the UI, the UI goes unresponsive for about 5 mintues. Start the node back up and it the Storage icon response time is about 10 seconds.

    Once I have locations plugin uninstalled, I’ll attempt to disassociate an image from a storage node and report back.


  • Senior Developer

    Can you take the location plugin out of question for the moment?

  • @Jim-Graczyk

    My next test was to add new objects to the existing FOG configuration to see if I could get the results others are getting with object created in this version of FOG.

    I did the following:

    • Created a new location
    • Created a new storage group
    • Created a new Host (fake MAC)
    • Created a new storage node (non-existant IP address). I think I put the new storage node in the new storage groups, but not sure due to problem described next.

    When I hit add on the storage node, I got the storage node added, I got the message Storage Node Added, but then the web UI failed to respond from that point on. The server was fine and not showing a lot of load, but the UI just sat there (for several minutes). I rebooted the server and was able to logon to FOG. the dashboard came up - minus the storage node graphic - and then failed to respond.

    I have disconnected the server from the network, rebooted it and attempted to connect to the fog website via localhost, but I get no response. FOG wed UI may not be bound to the local host IP.

    I’m at a loss. It’s Sunday and I’m off tomorrow, but have people who need FOG up and working tomorrow morning.

    My only choice may be to restore my FOG server 1.4.2 - as it was configured and working before I attempted to upgrade to 1.4.4 and ended up with 1.5.0 RC2 via my system backups and leave it there for now. If I don’t hear from anyone on this, I’ll assume I need to uninstall FOG from my storage nodes and reinstall 1.4.2.


  • Senior Developer

    @Jim-Graczyk said:

    add test items to my system and see if I could at least manage new items (Host, Storage Node, Storage Group and Location).

    Adding these items seems to have completely messed up my installation of FOG. Please see my message to Tom for details.

    What do you mean by messed up? The screenshots you posted look as if you are not able to remove a storage group assoc from an image (as we already know). What else do you think is messed up? Things can be cleaned up in most cases I think.

    Did you check in the mysql db using the query I posted?

  • @Sebastian-Roth


    Tracking message sequence in this website isn’t straight forward. I didn’t see this message before I posted my last with all the screenshots, nor did I see it before I attempted to add test items to my system and see if I could at least manage new items (Host, Storage Node, Storage Group and Location).

    Adding these items seems to have completely messed up my installation of FOG. Please see my message to Tom for details.


  • @Tom-Elliott
    Here are my Locations:

    Note that the SAL2 Location has storage group 101Space.

    Here are my storage groups:

    Note that SAL2FOGL1 is the only storage node at the SAL2 location and therefore primary storage node in the 101Space storage group.
    Here’s an image:
    This image is stored in these Storage Groups:

    Here, I attempt to remove the image from the storage group - I select the storage group and click Remove:


    Next, I list all images:
    Select the same image as before:
    Select the Storage Group Tab:

    The supposedly deleted Storage Group is still listed.

    Am I seeing something different from what you’re seeing? I’m running on CEntOS 7. Could that be an issue?


  • Senior Developer

    @Jim-Graczyk So is this still the case even after the DB cleanup? Then I’d ask you to do another direct mysql query to see if there is anything unexpected. Connect mysql -u root -p:

    mysql> use fog;
    mysql> SELECT * FROM imageGroupAssoc;

    Now compare those numbers in column igaImageID with your image IDs and igaStorageGroupID should match the IDs of your storage groups… Post the full set here in case you need assistance.

  • @Sebastian-Roth

    By Delete I only meant disassociate the image with the storage group. I was only explaining what I was doing that caused me to discover that I couldn’t delete the association of an image with a storage group. I had what appears to be a bad replica of an image at one site. Since I’m using the Locations plugin, there is one storage group defined for each location and there is one storage node in each storage group.

    To remedy the bad replica, I tried to disassociate the Image from the storage node/group at the site, delete the back copy, then re-associate the image with the storage node/group so the Image Replicator would re-copy the image to the site. While doing this, I discovered that I could not alter what storage groups were associated with an image.