I’ve been getting the same error message with Bowtie2 and BWA-MEM since yesterday. I ran mapping stats with Bowtie2 and I am getting a high alignment percentage for most of my fastqs (>90%) and a .bam file is created but it says it is unable to finish the job and I noticed it cannot create a .bai file.
Any help would be much appreciated! Please let me know if I can share my history with you somehow.
I am getting the same EXACT issuues as @Athina has mentioned. My alignment percentage is like ~98% but I get the same error message. I’ve tried using different parameters for both BWA and Bowtie for days and still get the same error.
Thanks all for writing in about the problem. Direct bug reporting from the web interface at https://usegalaxy.org is still problematic. More updates soon about that.
Let’s try another way. Send a direct message to me (@jennaj) with:
A share link to the history that contains the problematic BAM result(s). Be sure to check the box for sharing “objects” in the history. Unshare/reshare the link if you are not sure if this box was checked. The function for “Share or Publish” is listed in the history menu.
Dataset number(s) for the BAM results
Please do not delete the BAM results or any of the inputs used to create it from your history
Direct messages (sent, received, etc) can be found here in the Galaxy Help web interface:
As a short-cut to send a new direct message, click on the “@” for the person you want to send to. An “envelope” icon will be in the pop-up. Clicking on the envelope will initiate a direct message.
There is likely either a server-side issue, the BAMs are too large to index, or some combination of the two. A few examples will help to clarify. We just updated the server – fixing any issues is a priority.
@jennaj Thank you for you reply. I now noticed that every time I logout and in again, the first run of Bowtie2 works fine, then the second crushes. For the same dataset. I am now trying to share everything with you as you suggested above.
@Jamal_Williams Definitely will post back the results, however it turns out. But need an example first, as I haven’t been able to reproduce it on my own.
@Athina Interesting pattern, I didn’t try that. Also, I don’t see a direct message from you yet but will keep eye out for it
@jennaj This is going to sound a bit ridiculous I am sure but I am unable to find the sharing “objects” box and how to actually create a link for you. Could you please help me with that too? Thanks!
@Jamal_Williams By the way I just wanted to say that Bowtie2 has now started working fine for me. Just this morning I checked again. Five consecutive runs of Bowtie2 and it is good. Not sure what changed.
@Jamal_Williams Sounds like the problem resolved itself. Good! We updated the server last week and had a bit of trouble initially but most of that has been sorted out. Reporting bugs directly via the web interface is still problematic but is on our priority to-do list.
@Athina For future reference, to share a history, look under the History menu (gear icon) for the option “Share or Publish”. That option is also available for Workflows (in the pull-down menu, per workflow).
The interface has changed a bit since this FAQ and the video were created but it has the basics correct. It is on my list to update that – am waiting for the final round of UI changes to stabilize first.
What is new is the presence of an option when sharing histories to check whether to “share the objects” included in history or not (meaning: grant access to the datasets themselves so they can be reviewed/downloaded). In most cases, including for troubleshooting reasons and in publications/blogs/etc, you’ll want to check that box – unless you really just want to just share the analysis but not the actual data for some reason.
Screenshot: Objects set to be shared before clicking on the button to generate the history share link. If you can’t remember if you checked the box or not, just unshare, check the settings, adjust as wanted, and regenerate the link.
In short, until resolved (when the ticket closes out), set the destination cluster on the tool form as described in the ticket and the linked workaround Galaxy Help post: HISAT2 Not working
I never received an example Bowtie2 error but was able to reproduce the issue in directed testing. The last round of the testing is in a shared history link in the Github ticket if interested.
Mapping jobs will route to available cluster resources. My guess is that initially for both of you that the jobs were routed to one cluster, then later on the other. One works, the other does not at present. This will be a priority correction.
@jennaj Hi, I used the solution you suggested and first time it worked fine, second time I got this error:
“Failed to write job script ‘/galaxy-repl/main/jobdir/025/126/25126033/tool_script.sh’, could not verify job script integrity”
@nibhelim It looks like your jobs are running Ok now, the same as @Athina’s are.
There were a few spikes of a job handler problems, Sunday and early Monday, now resolved. Jobs are running again and are executing in the order queued (by everyone).
@jennaj today I have the same problem with job not running with the same unexpected error. never had a single one of these issues before the update. thanks for the help
Try a rerun now and be sure to specifically target the “Galaxy cluster” in the “Job Resources” tool form option. The Jetstream cluster is still problematic for mapping jobs, and jobs could be sent there if default form settings are used (confirmed again earlier today in this test history https://usegalaxy.org/u/jen/h/test-mappers-and-clusters).