Some tools have disconnected genome indexes post server updates -- Resolved issue UseGalaxy.org

usegalaxy.org support
, , ,
#1

Original title: Server Indexed File (Human (homo sapiens): hg38) does not appear to be functional

Using bedtools GetFastaBed to get sequences in Server Indexed Files: Human (homo sapiens): hg38 underlying ChIP-seq binding sites in a collection of BED files, all returned files were 0 bytes with warnings saying “WARNING. chromosome (chr1) was not found in the FASTA file. Skipping.” (and many more similar warning lines)
I’m assuming this has something to do with the server maintenance and reloading of Server Indexed Files. When do you think this will be resolved?
Thank you,
Justin

1 Like
#2

tool still unable to find chromosomes (chr1, chrX, etc) in server indexed FASTA file and returns empty files. please help!

#3

Dataset Information
Number: 7947
Name: bedtools GetFastaBed on data 7881
Created: Fri Oct 16 14:11:18 2020 (UTC)
Filesize: 0 bytes
Dbkey: hg38
Format: fasta
Job Information
Galaxy Tool ID: toolshed.g2.bx.psu.edu/repos/iuc/bedtools/bedtools_getfastabed/2.29.0
Galaxy Tool Version: 2.29.0
Tool Version: bedtools v2.29.0
Tool Standard Output: stdout
Tool Standard Error: stderr
Tool Exit Code: 0
History Content API ID: bbd44e69cb8906b5ee719ead5a404447
Job API ID: bbd44e69cb8906b544381b625dcffda9
History API ID: 387a03a1eca44028
UUID: 71eb5c07-de44-44fd-8b5c-457194f301fc
Tool Parameters
Input Parameter Value
BED/bedGraph/GFF/VCF file
7881: STAT5A PLS.BED
Choose the source for the FASTA file preloaded
fasta_id hg38
Use the ‘name’ column in the BED file for the FASTA headers in the output FASTA file True
Report extract sequences in a tab-delimited format instead of in FASTA format False
Force strandedness False
Treat split/spliced BAM or BED12 entries as distinct BED intervals when computing coverage. False
Inheritance Chain
bedtools GetFastaBed on data 7881

#4

This tool had another reported error around this some time frame (at UseGalaxy.org, with hg19).

I’m guessing that you already tried a rerun (to eliminate recent server downtime as a contributing factor).

Testing now – more feedback soon. Thanks for reporting the problem!

#5

Yes, retried several times without success. Thank you!

1 Like
#6

Update 10/21/20 1pm EST: Resolved. Please rerun prior jobs that failed.

Update 10/20/20 7pm EST:

The correction is still pending. Ticket with details https://github.com/galaxyproject/usegalaxy-playbook/issues/311

Once confirmed to be fixed, that ticket will close out. It should be very soon

Correction in progress.

Tools with known issues (are likely more):

BamLeftAlign
GetFastaBed
BWA-MEM and most other mapping tools
Freebayes

Details:

We can confirm the problem and are correcting it right now. It might be Monday before everything is done. Write back if still a problem on Tuesday for an update.

Meanwhile, you can do the same operation at usegalaxy.eu or usegalaxy.org.au.

Copy the link from a dataset’s “disk” icon and paste it into the other server’s Upload tool to move data around. Some servers require that the history/datasets are in a shared state first. Do this under User > Histories > menu (gear) > Share or Publish. Choose the “share by URL” option making sure the box is checked to also share the objects inside of the history (eg datasets). Or, reset all permissions to share objects by default in user-defined ways under User > Preferences.

Each public server has the default data permissions set a bit differently, but these FAQs cover all of the sharing/permissions in case you get stuck: https://galaxyproject.org/support/#data-options

Thanks again for the followup, appreciated

#8

Thank you!

#9

I am currently having this issue too, but with Map with BWA-mem and Freebayes, in both cases trying to use the hg19 genome

1 Like
#10

Resolved. Please rerun failed or empty result jobs that made use of built-in genome indexes.

#11

Thank you, all working now!

1 Like
#12

@deniseharold Great to know! :confetti_ball: