Unable to Install Packages via apt-get in Singularity Image

2,758 views
Skip to first unread message

Grimey

unread,
Jan 30, 2018, 4:24:05 PM1/30/18
to singularity
Hi,

I have been working at this issue for some time and I cannot seem to figure it out. I am running Singularity in a Vagrant machine on a Mac, installed following the instructions here: http://singularity.lbl.gov/install-mac

Once I have spun up the Vagrant machine, I am running these commands to pull the image for Ubuntu:

$ sudo singularity build --sandbox ubuntu16-04 docker://ubuntu:16.04
$ sudo singularity shell ubuntu16-04

Next I wanted to install dependencies in the image like so:

$ apt-get update
$ apt-get install g++=4:5.3.1-1ubuntu1
$ apt-get install libboost-all-dev=1.58.0.1ubuntu1

The first install works fine, but for the second, I get the following message:

dpkg: unrecoverable fatal error, aborting:
 unable to flush
/var/lib/dpkg/updates/tmp.i after padding: No space left on device
E
: Sub-process /usr/bin/dpkg returned an error code (2)

Running df -h on both the Vagrant machine and within the Singluarity image seems to suggest that I have enough space to install everything, and I have checked inodes, and there are plenty left. The image was made in sandbox mode, so I am not sure why I am hitting this issue. Any help would be greatly appreciated!

Cheers

David Godlove

unread,
Jan 30, 2018, 4:28:17 PM1/30/18
to singu...@lbl.gov
Hi there,

Can you try entering the container with the --writable flag instead?

sudo singularity --writable shell ubuntu16-04

I think that should fix your issue.

Dave

--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.

Grimey

unread,
Jan 30, 2018, 4:42:05 PM1/30/18
to singularity
Hi Dave,

Do you mean create a container with the writable flag? The flag seems to not exist when just starting the image.

Cheers

v

unread,
Jan 30, 2018, 5:06:53 PM1/30/18
to singu...@lbl.gov
Hey Grimey,

Definitely add --writable to the shell! The container is "writable ready" but when you shell inside, you still need to ask for it. Did you try (like Dave suggested)

sudo singularity shell --writable ubuntu16-04

Take it for a spin! If there are still space issues, then we can look further.

Best,

Vanessa

--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.



--
Vanessa Villamia Sochat
Stanford University '16

Grimey

unread,
Jan 30, 2018, 5:46:32 PM1/30/18
to singularity
Yes, this seems to have fixed it! Just to clarify then, sandbox makes the image writable, but to actually write, you need to invoke the shell in writable mode as well?

Cheers,
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.

v

unread,
Jan 30, 2018, 5:58:03 PM1/30/18
to singu...@lbl.gov
Yeah it can definitely be confusing! I always think of sandbox as "make me a folder I can edit if I need" (using sudo). Here is a quick listing:

 -- writable: build an ext3 (filesystem) image that can support writable with sudo [single file]
 -- sandbox: build into a folder that can also support writable with sudo, and it is "click around-able" as you would with these folder things :) [folder]
 
and then of course without any flags you get a squashfs filesystem [single file], which is read only, regardless of how hard you try, or with --writable flags. You could of course export it into something else to get that functionality, but then it wouldn't be squashfs anymore.

To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.

Grimey

unread,
Jan 31, 2018, 11:04:09 AM1/31/18
to singularity
Awesome! This clarifies things.

Thanks again!

David Godlove

unread,
Jan 31, 2018, 1:08:40 PM1/31/18
to singu...@lbl.gov
Yes.  Adding the --writable flag to a sandbox to actually make it writable made sense to us at the time that we added the sandbox option based on historical precedent.  But moving forward I don't think it makes sense at all.  We will probably remove this flag in the future and add another flag to turn off the default writable behavior.  

But for now, yes you must add --writable when _running_ your container.

Dave
Reply all
Reply to author
Forward
0 new messages