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

Install script fails building disk image - incorrectly reports disk is full #17

Closed
danmactough opened this issue Jan 25, 2016 · 11 comments

Comments

@danmactough
Copy link

Any ideas? I've tried removing the files in $HOME/.dilte and rerunning install. No dice.

⇰ sudo dlite install
Building disk image: ERROR - write /Users/danmactough/.dlite/disk.img: no space left on device
write /Users/danmactough/.dlite/disk.img: no space left on device
[15:44:41] code
⇰ df -h
Filesystem      Size   Used  Avail Capacity  iused   ifree %iused  Mounted on
/dev/disk1     112Gi   89Gi   23Gi    80% 23376429 5946833   80%   /
devfs          183Ki  183Ki    0Bi   100%      634       0  100%   /dev
map -hosts       0Bi    0Bi    0Bi   100%        0       0  100%   /net
map auto_home    0Bi    0Bi    0Bi   100%        0       0  100%   /home
[15:44:51] code
⇰ df -i
Filesystem    512-blocks      Used Available Capacity  iused   ifree %iused  Mounted on
/dev/disk1     234586112 186499456  47574656    80% 23376430 5946832   80%   /
devfs                366       366         0   100%      634       0  100%   /dev
map -hosts             0         0         0   100%        0       0  100%   /net
map auto_home          0         0         0   100%        0       0  100%   /home
[15:44:59] code
⇰ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 709
virtual memory          (kbytes, -v) unlimited
[15:45:07] code
⇰ uname -a
Darwin DanMs-ST-MacBook-Pro.local 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
@nlf
Copy link
Owner

nlf commented Jan 25, 2016

by default DLite attempts to make a 30GB disk image, and since xhyve doesn't currently support sparse images that space is all used immediately. since you only have 23GB of free space on your drive, it's filling the drive attempting to create the disk image.

you can get around this by running the install like sudo dlite install -d 15 to create a 15GB disk image, for example.

@sscarduzio
Copy link

30 GB?? Why so big?

@danmactough
Copy link
Author

Lol. WOW! 30GB!! Thanks, @nlf!

@nlf
Copy link
Owner

nlf commented Jan 25, 2016

because with all the layers that docker creates i found that i was personally filling the 10GB image i was originally creating pretty quickly and having to reset it. not a big deal if you don't mind rebuilding your disk image and re-pulling your docker images if it runs out of space

@drewcrawford
Copy link

Also hit this. Could we get a better diagnostic for this situation?

not a big deal if you don't mind rebuilding your disk image and re-pulling your docker images if it runs out of space

This is true, but since Virtualbox supports sparse images, no sparse images means dlite is arguably not the best way to run Docker on OSX.

@danmactough
Copy link
Author

Could we get a better diagnostic for this situation?

If the error message had additionally stated that it tried to allocated 30GB, I would have believed it instead of thinking the error was spurious and that there was something else wrong.

since Virtualbox supports sparse images, no sparse images means dlite is arguably not the best way to run Docker on OSX.

I think this is just the trade-off. This is definitely the EASIEST way to run docker on OSX. If it's not the most disk space efficient way, I'm happy to make that trade-off. 😄

@drewcrawford
Copy link

If it's not the most disk space efficient way, I'm happy to make that trade-off.

That's fine; I'm simply saying that there is a tradeoff, which is nowhere documented. My suggestion would be:

  • List this in the "Caveats" section of the README
  • Link to a (possibly upstream) bug, to focus the discussion somewhere appropriate

@nlf
Copy link
Owner

nlf commented Jan 26, 2016

good idea @drewcrawford, i'll add a note in the caveats.

also great idea to give a more clear error message in that case, i'll add a check to confirm enough free space exists before i try to allocate the disk image so i can give the user more information

@danmactough
Copy link
Author

List this in the "Caveats" section of the README
Link to a (possibly upstream) bug, to focus the discussion somewhere appropriate

Both great ideas. 👍

@nlf
Copy link
Owner

nlf commented Jan 26, 2016

added a note with links to the readme in the caveats section, see #42 for a tracking issue for a better error message

@dunkelstern
Copy link

Implementor of machyve/xhyve#82 here, i could create another pull request against libxhyve if you want to include it directly, runs stable on my machine so far :) (And I have complete sparse image support, just wanted to create smaller pull requests so they could be easier reviewed, upstream seems rather inactive currently so the work is not directly visible there)

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

5 participants