fastqc and Apple

[erinyoung]

I am putting this here so that more people know about it.

There was an issue brought up in the Cecret github issues (UPHL-BioNGS/Cecret#88) that there may be an issue with the fastqc container and docker on some Apple products.

Is this related to the Apple M1 chip I am using? I've attempted to use Option 1 and Option 2 to run from Docker and Singularity and I encounter an issue with the StaphB FastQC Docker container:

FATAL: Unable to pull docker://staphb/fastqc:latest: conveyor failed to get: no descriptor found for reference "5d67fad373325a597d0eb75d0986ad7dd78f8b2b67e78435d9176c434a8cec04"

Is this an issue with the Apple M1 chips?

If this is an issue with the Apple M1 chips, we may want to include sort of disclaimer.

[jrichardsz]

Is the issue related to build a Dockerfile on a mac or build a Dockerfile with apple dependencies on a linux machine?

[MillironX]

This issue isn't specific for Mac/M1: I have gotten this error multiple times on a mix of local Fedora+CentOS and Slurm CentOS HPC nodes. It's mainly related to the way Nextflow interacts with the singularity pull command. See:

• singularity parallel pull error of docker images nextflow-io/nextflow#1210
• Error: unable to build: conveyor failed to get: no descriptor found for reference apptainer/singularity#4555

Anecdotally, I've found the issue is less prevalent on Singularity 3.8.x vs. earlier releases, but I don't have any numbers to back that, and there might be other factors involved.

Also anecdotally, I've had better success specifying the domain for all images, e.g. docker.io/staphb/fastqc:latest rather than just staphb/fastqc:latest.

In any case, this can usually be resolved by running singularity pull docker://staphb/fastqc:latest (or whatever container name is giving trouble) prior to executing the Nextflow pipeline. Singularity will then pick up on the cached image and transfer it to Nextflow.