Use install-gpu.sh to install but ran out of space

I want to create a custom ami for fastai (for fun and experiements) on a p2.xlarge so I: started a p2.xlarge instance and, after it was running, ssh’d in and used vi to create the install-gpu.sh and cut and paste the contents in (and checked that the contents were OK):

$ vi install-gpu.sh

then I ran the script and the process started OK:

$ bash install-gpu.sh
Hit:1 http://us-west-2.ec2.archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://us-west-2.ec2.archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Get:3 http://us-west-2.ec2.archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]

(etc.)

it did the earlier parts successfully and downloaded and begin installing Anaconda:

–2017-06-23 21:56:08-- https://repo.continuum.io/archive/Anaconda2-4.2.0-Linux-x86_64.sh
Resolving repo.continuum.io (repo.continuum.io)… 104.16.18.10, 104.16.19.10, 2400:cb00:2048:1::6810:130a, …
Connecting to repo.continuum.io (repo.continuum.io)|104.16.18.10|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 467689464 (446M) [application/x-sh]
Saving to: ‘Anaconda2-4.2.0-Linux-x86_64.sh’

Anaconda2-4.2.0-Linux-x86_64.sh 100%[==================================================================================>] 446.02M 125MB/s in 3.9s

2017-06-23 21:56:12 (114 MB/s) - ‘Anaconda2-4.2.0-Linux-x86_64.sh’ saved [467689464/467689464]

PREFIX=/home/ubuntu/anaconda2
installing: python-2.7.12-1 …
installing: _license-1.1-py27_1 …

it continued on with install Anaconda, but during the install it ran out of space:

installing: pyyaml-3.12-py27_0 …
installing: pyzmq-15.4.0-py27_0 …
installing: qt-5.6.0-0 …
tar: plugins/mediaservice/libgstmediacapture.so: Wrote only 2048 of 10240 bytes
tar: bin/qmllint: Cannot write: No space left on device
tar: include/qt/QtGui/qopenglfunctions_4_1_compatibility.h: Cannot write: No space left on device
tar: include/qt/QtGui/qopenglfunctions_4_2_compatibility.h: Cannot write: No space left on device

Everything after this failed due to lack of space.

It appears that:
p2.xlarge instance is EBS Storage only
A new AWS account on free tier has 5MB of (EBS or S3?)
Also, I created a bucket in S3

Can you please tell me what is the problem and what I need to do to set up AWS so that I can do a complete install and then I can save an ami (probably into S3?)? Thanks very much for your help.

The default size of the root volume is only 8 GB. You’ll need more room than that to install all the tools, so use the options to increase storage size when you are launching an instance. I use 15GB, but I then use a separate EBS volume for all the datasets and actual work.
If you want to do everything on the main volume, you should probably use a minimum of 50 GB.

Hi Ken. Thank you, this worked! When starting my p2.xlarge instance I set it to 15GB and the full install completed, then I saved it as an ami (which I can now change at will, and run as a spot instance). However, when I used this instance to run Jupyter Notebook (and again later when restarting with the ami) I got an ERR_CONNECTION_TIMED_OUT message and was not able to connect with the notebook. See the new post: Can’t connect to Jupyter Notebook (tried 3 different machines) ERR_CONNECTION_TIMED_OUT

Do you think the Jupyter Notebook problem would have anything to do that my instance is built using install-gpu.sh ?

It’s more likely related to your security group settings. Make sure you allow access to port 8888.

I had the same error and this worked for me:

start the notebook like this:

jupyter notebook --no-browser --port=8889

and then in the browser use your Ip address and 8889 as port for example:

54.69.135.221:8889

and that will launch the notebook

I’m suffering the same issue on an Azure NC6-instance. Runs out of space during installation of scikit. Does anybody else experinence this? Thanks in advance

When you run out of space in azure, increase the size of the OS disk. By default it comes with only 30GB with almost 70 - 80% full. This change has happened recently and will break most of your new deployments. Best bet is before you start, stop the VM, goto the attached disk and change the size of the disk to say 1000GB or something similar.