"Wipe Task" run amok.



  • “List All Hosts”->“Host”->“Host Tasks”->“Advanced”->“Normal Wipe”

    This has set a task which wipes out both the target drive as well as the image associated with the host.

    Further more, this advanced task has wiped out my reference image for a separate host/group i.e. the task appears to be set for all machines.

    Finally, the Task does not show up anywhere in the interface.

    If I run a history report the “wipe task” is listed twice on the original host and is not listed for the next host/image pair that got wiped out.

    This is of course rather frustrating.


  • Senior Developer

    Marking as solved as we have addressed the size-reset to zero issue on client checkin already in dev-branch: https://github.com/FOGProject/fogproject/commit/9ff877627de44309f9eef8b07587efdb918d3d1e



  • @Tom-Elliott just confusing because it was attached to the image screen after the task had run on the host. I see what’s going on now though.


  • Senior Developer

    @vangrimoire that makes sense. That data is just a nice to have. It tries to calculate it during imaging tasks and likely resets it for any task. There is also a service that runs to update the data too. It is not indicative of a problem though.



  • holy crap, it’s just an update to the size registry after a wipe task

    5c218d92-4330-4746-a247-607a2f89d951-image.png



  • actually I"ve still got one

    eca9d6d3-0f8b-4875-99c8-fe1929d6c0e7-image.png

    it reads 0.00 iB


  • Senior Developer

    @vangrimoire none this makes sense at all. Wipe tasks are available but the only piece of that updates the database is checking in, and completing the task. At no point is it referencing an image or making updates to the image table.

    Did you create the task and start it, then upgrade your fog server? I ask this because there is a potential issue of fog server is Ubuntu and you upgrade your server, it will try to install mariadb which creates a new instance of the database.



  • Oh it was terrible, it looks like the images are still there by browsing, but somehow unlinked in the interface. I deleted the hosts involved and recovered my images - hesitant to hit the “wipe task”.


  • Senior Developer

    @vangrimoire I have done some testing with “Normal Wipe” and I can’t replicate anything of what you mentioned. Image still exists in /images/test on my server disk as well as the image definition and association to that host in the web UI. The only thing that got wiped is the disk of the target host as expected.

    Are you absolutely sure there is no other user playing with the web UI while you write this?

    Don’t get me wrong. What you describe sounds terrible and FOG should never do something like this but from what I understand about it it’s almost impossible to make this happen by scheduling and running a wipe task (which essentially is only meant as wipe the target disk but nothing else!)


  • Senior Developer

    @vangrimoire said in "Wipe Task" run amok.:

    This has set a task which wipes out both the target drive as well as the image associated with the host.

    I’d need to do some testing on this. I can hardly believe what you described can happen just from scheduling a wipe task". Give me a bit more time to try and replicate this.

    Are you sure the image itself was removed? Do you mean the host lost the image association or is the image definition itself gone? What about the actual data on disk? Is /images/#IMAGENAME# on your disk still existent?



  • Fog is up to date version 1.5.7


Log in to reply
 

405
Online

7.4k
Users

14.5k
Topics

136.8k
Posts