MG1971
Contributor
Contributor

AppVolumes 4.2 (2009) can´t delete unassigned package

Hello everybody,

I have an issue to delete a Package in AppVolume 4.2. The delete button is gray.

delete_package.png

 

 

0 Kudos
14 Replies
Ray_handels
Virtuoso
Virtuoso

Yep, your answer is in the screenshot 🙂 :).

Look at attachments, it says 1. No idea where it is attached to but you cannot remove a package if it is still attached to a machine.

make sure to unattach it (if you assigned it, make sure the user that had the attachments logs out) and then you will see that you can remove it.

0 Kudos
bw-man
Contributor
Contributor

and what is if this attachment is not visible in attachments ?

You can not unattach what you can not see.

And then ?

0 Kudos
Ray_handels
Virtuoso
Virtuoso

If it still sees it as attached it could be that the database is not yet cleaned and thus still thinks it is attached. 

What happens if you go to the attachment tab? Or could it be that it is still attached to a package machine maybe?

0 Kudos
MG1971
Contributor
Contributor

It´s not attached to any machine. The packaging machines are offline.

0 Kudos
pieterheijms
Enthusiast
Enthusiast

How did you solve this problem?

We have the same issue.

0 Kudos
Markus_Gundelac
Contributor
Contributor

Is not resolved until now

0 Kudos
pieterheijms
Enthusiast
Enthusiast

Thanks

0 Kudos
scythe944
Contributor
Contributor

I'm having the same problem with an Adobe acrobat package.  It's not assigned to anyone, I see no attachments, but the system still thinks that there's something attached and doesn't let me delete it.  Any pointers on how to clear the "attachment" so I can delete this old package?

0 Kudos
Micheal_A
VMware Employee
VMware Employee

If the package is locked by a system that no-longer exists, you will have to put a support request in to have GSS run some ruby rails console commands to delete the package for you.

I would not try this your self, because this could corrupt your AppVol database.

 

 

“Set your Intention in the direction of your destiny and not the distraction of this moment.”
@StevenFurtick
VMware Docs | VMware EUC BLOG | VMware EUC Community | VMware Support |


0 Kudos
Lieven
Enthusiast
Enthusiast

I had the same issue.

I solved it by doing the following:

1. creating a new Application. (I named it TO_DELETE)

2. Moved the application I could not delete to this new application TO_DELETE

3. Wait 1 day

4. Deleted the application TO_DELETE together with the package it contained

 

Version I am using is App Volumes 4.5 (2111.1)

0 Kudos
scythe944
Contributor
Contributor

Funny thing then, VMware support has had my case for about 3-4 weeks and just responded a few days ago that updating to app volumes 2111 would resolve the issue.  It appears that you're using this version and still need to wrangle with a fix.  I was hoping to upgrade our appvolumes servers this weekend when no one was using them to see if it worked.

thanks for your suggestions, Lieven

0 Kudos
Micheal_A
VMware Employee
VMware Employee

I would suggest, if you still are having the deletion issue, to have GSS run the Ruby Rails commands to delete this package. this will confirm that all traces of the this package will be deleted from the database.

@Lievenworkaround is not supported by GSS and we cannot confirm if there is still a possible bug that needs to be repo'd.

I work closely with the AppVolumes VMware engineering team and they want to know of these problems ASAP.

“Set your Intention in the direction of your destiny and not the distraction of this moment.”
@StevenFurtick
VMware Docs | VMware EUC BLOG | VMware EUC Community | VMware Support |


0 Kudos
Ray_handels
Virtuoso
Virtuoso

Hey @Micheal_A that's strange because we have the exact same issue and they are stating that it is being checked by by engineering.

I do have another workaround which is not supported, at least that's my guess. Will point out here that I am not a VMware employee and use at your own risk :).

When you run a select * from snapvols command towards the database there is a column there that is called Attachment_count, this holds the info if a snapvol is indeed attached. If you manually change that to 0 you are able to remove the application and it will remove the packages as well.

As a cross check I would also make sure to also use the following 

select * from snapvol_attachment where snaopvol_id = <ID of the snapvol>. This should not return any results, otherwise it actually does have an attachment towards some machine but at least you'll know which one it is.

But to me this seems to be a bug in how Appvolumes registrates the attachments in the database. It should normally run a check for every snapvol (which actually is a package) if it still has attachments in the snapvol_attachments table.

0 Kudos
aflopez
Contributor
Contributor

We upgraded to 2111 and the issue still persists. I opened a ticket after the upgrade and haven't received any traction on a fix for the issue.

0 Kudos