Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fsl > v 6.0.3: While pulling shub image: Failed to get manifest from Shub: The requested manifest was not found in singularity hub #1

Open
SomePersonSomeWhereInTheWorld opened this issue Dec 19, 2022 · 2 comments

Comments

@SomePersonSomeWhereInTheWorld
Copy link

SomePersonSomeWhereInTheWorld commented Dec 19, 2022

FYI, when trying any version > 6.0.3, e.g., 6.0.4, 6.0.5, et al, you will get:
FATAL: While pulling shub image: Failed to get manifest from Shub: The requested manifest was not found in singularity hub

6.0.6.1 is current as of Dec 2022.

Also if you run the example:
singularity exec --nv singularity-fsl_6.0.3.sif eddy_cuda9.1

singularity exec --nv singularity-fsl_6.0.3.sif eddy_cuda9.1 
***************************************************
The following COMPULSORY options have not been set:
   --imain	File containing all the images to estimate distortions for
   --mask	Mask to indicate brain
   --index	File containing indices for all volumes in --imain into --acqp and --topup
   --acqp	File containing acquisition parameters
   --bvecs	File containing the b-vectors for all volumes in --imain
   --bvals	File containing the b-values for all volumes in --imain
   --out	Basename for output
***************************************************

Part of FSL (ID: 6.0.3:b862cdd5)
eddy 
Copyright(c) 2015, University of Oxford (Jesper Andersson)

Usage: 
eddy --monsoon
@octomike
Copy link
Member

FYI, when trying any version > 6.0.3, e.g., 6.0.4, 6.0.5, et al, you will get:

You are very correct. I updated the README about our use for this repo (and the singularity hub). Thanks for letting me know!

Also if you run the example:

This is just to remind people (and myself) to use the --nv flag, when using eddy_cuda :) It's not running anything in particular, just shows that the binary will find the libraries.

@SomePersonSomeWhereInTheWorld
Copy link
Author

SomePersonSomeWhereInTheWorld commented Dec 20, 2022

. I updated the README about our use for this repo (and the singularity hub).

Looks like a minimum version of Singularity and/or glibc is needed. Version 3.5.3 results in:

Processing triggers for systemd (241-7~deb10u8) ...
Errors were encountered while processing:
 libc-bin
E: Sub-process /usr/bin/dpkg returned an error code (1)
FATAL:   failed to execute %post proc: exit status 100
FATAL:   While performing build: while running engine: while running /moto/opt/singularity-3.5.3/libexec/singularity/bin/starter: exit status 255

Version 3.2.0 fails with:

Storing signatures
singularity image-build: relocation error: /lib/x86_64-linux-gnu/libnss_files.so.2: symbol __libc_readline_unlocked, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
FATAL:   While performing build: while running engine: exit status 127

glibc-2.17-222.el7.x86_64

3.7.1 builds the .sif file correctly. Thanks for updating this so quickly!

I may look into how to make the container writable as on a Mac with multiple monitors and with XQuartz FSLEyes (either from the menu or CLI) opens in such a large window/view that one has to resize the window by dragging from the bottom right to get it to fit on one monitor. Then you can save the layout assuming the container was writable.

Also this may be an issue on Macs, but with no additional monitor, e.g., just the laptop, this error happens which I'll report to the FSL mailing list.

singularity exec fsl-6.0.6.1.sif fsleyes
The program 'fsleyes' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 996 error_code 11 request_code 149 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants