Help removing hg38 genome


I am a fairly new administrator for a Galaxy Server in a Biomedical company. My users informed me we have a genome called hg38 loaded into Galaxy in such a way that the users are unable to run BWA_MEM for hg38 ending with a message saying it was unable to locate the index files. They have asked I remove the genome entries and they will add it again in the same manor as other genomes (which all work). I have not located an obvious way to do this. Here are some details:

You can hopefully see from the image that hg38 appears to be loaded 3 times. 2 of those times are references using “/cvmfs”. All 3 use the same dbkey so I suspect the nature of the issue is related to that. When the users originally reported about the missing indexes there were only two loaded and both were “/cvmfs”. Since reporting they have attempted to correct the issue themselves by reloading using the local file system, hence now 3 entries.

Its installed on Ubuntu 18.04.2 LTS. I’m reasonably confident this is for Galaxy version 19.09 but I’m not sure how to tell confidently so I used the “git log” command in the installation directory and all the top entries are for 19.09. The install was done on 26Jan2020 by me. I did not know at the time I should record the version on the welcome page. :frowning: Appreciate any thoughts or pointers to documentation steps to remove a genome. Cheers.

Unfortunately it’s not supported to modify tool data tables this way through the admin interface directly.

One possibility would be to find the .loc file for that data table in the admin interface’s Data Tables link, and modify or remove the one with the incorrect entries. Others more familiar with data tables might have additional ideas that work better.

Much gratitude for the reply. I can certainly clone the server and associated PostgreSQL DB user, then fiddle with that. I need clone it anyway to upgrade to the latest version (first to 20.01 then to latest) so I can test there once I prove the upgrades will go smoothly before doing them on prod. I’m comfortable going into PostgreSQL with SQL too if that becomes a possibility.

You shouldn’t need to do anything to the database, all the index files and their locations are stored on disk.
This wiki page should give you much useful information on how that system is structured: