Not sure if this is the right place, but what is the protocol for building something large with yaourt when one's /tmp is in ram?
$ cat /etc/fstab tmpfs /tmp tmpfs defaults,nodev,nosuid,noatime,mode=1777 0 0
I just tried to build FreeCAD and it failed due to lack of space. Is there a way to set the build directory for something one knows is going to be large? This has never happened before, so I'm guessing it's only an issue for something really big, like freecad, which requires opencascade as well.
Thanks for your tips. Perhaps I can add something about this is in the wiki? I didn't see anything mantioned there or the forums.
Last edited by jwhendy (2011-03-22 20:03:45)
As with any filesystem, tmpfs will hold all files you have on it until they are either manually removed or you reboot your system, so if you tried building the package after several others had been built this might have been the problem. One work-around for this would be to dedicate a certain amount of ram to the job temporarily, replacing "mode=1777" with "size=x(K, M, G)" in /etc/fstab, and changing it back afterward. This is useful if all you intend to do is occasionally build one very large package. You could also create a /dev/shm ramfs and dedicate that as your build directory in /etc/yaourtrc, which will clear out as a tempfs and allow enough ram to build packages without the high disk i/o rates.
@anoknusa: thanks for the reply.
- this should have been about the first thing built. I think it's just that big...
- great suggestion about adding a size argument
--- though, is there a possibility the build would be > 2G?
- I'll consider the /dev/shm idea as well
For now, I just manually downloaded the tarball from AUR and it's been building in ~.
I can't see a build being more than 2GB but if I recall correctly the default size is 4GB for tmpfs
Have you tried using the --export <dir> option in yaourt?
f I recall correctly the default size is 4GB for tmpfs
the default, when neither size nor nr_blocks is specified, is size=50%
Arch64/DWM || My Dropbox referral link
@SS4: what does that do? man says:
--export <dir> Export builded packages and their sources (makepkg(8)) to <dir>.
I don't get what that means, though. "Builded" (built?) seems to imply once the packages are built, which would then imply that all the necessary memory to build it has already been used beforehand.
I just set "TMPDIR" in /etc/yaourtrc temporarily to my home directory and on the last fail I got this (among several others like it):
/usr/bin/yaourt: line 166: /home/jwhendy/installed/abs/yaourt-tmp-jwhendy/orphans/installed_after.23949.newonly: No space left on device
which was the same error I got the first time when my build failed. Why would that be happening when building in home?
$ df -H /dev/dm-0[/__active] 80G 28G 53G 35% /
I'm running btrfs -- is it giving false size issues?
I think my issue is something else. I can no longer do anything with yaourt...
$ yaourt evince-gtk 1 aur/evince-gtk 2.32.0-2 (191) Document viewer for multiple document formats (GTK+ version) 2 aur/evince-gtk-synctex 2.26.2-3 (Out of Date) (22) The Evince documentviewer patched to have no gnome deps + inverse and forward search with SyncTex, options to sync to emacs, gvim or kile (edit PKGBUILD to choose editor) ==> Enter n° of packages to be installed (ex: 1 2 3 or 1-3) ==> ------------------------------------------------------- ==> 1 sort: fflush failed: standard output: No space left on device sort: write error sort: write failed: standard output: No space left on device sort: write error ==> Downloading evince-gtk PKGBUILD from AUR... (23) Failed writing body ==> ERROR: evince-gtk not found in AUR. sort: fflush failed: standard output: No space left on device sort: write error sort: write failed: standard output: No space left on device sort: write error
But unlike the other search results for this problem, my drives are not full!
$ df -H Filesystem Size Used Avail Use% Mounted on udev 11M 275k 11M 3% /dev /dev/dm-0[/__active] 80G 25G 55G 32% / shm 1.1G 62k 1.1G 1% /dev/shm /dev/sda1 128M 31M 91M 26% /boot tmpfs 1.1G - - - /tmp
Why the "- - -" for tmpfs? My fstab is above... the only other thing I can think to post is:
$ mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755) /dev/dm-0[/__active] on / type btrfs (rw,noatime) devpts on /dev/pts type devpts (rw) shm on /dev/shm type tmpfs (rw,nosuid,nodev) /dev/sda1 on /boot type ext2 (rw) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,mode=1777) /dev on /opt/arch32/dev type none (rw,bind) /dev/pts on /opt/arch32/dev/pts type none (rw,bind) /dev/shm on /opt/arch32/dev/shm type none (rw,bind) /tmp on /opt/arch32/tmp type none (rw,bind) /home on /opt/arch32/home type none (rw,bind) none on /opt/arch32/proc type proc (rw) none on /opt/arch32/sys type sysfs (rw)
Thoughts? It would be great to resolve this!
Last edited by jwhendy (2011-03-22 19:53:14)
Update: I think this might be a btrfs issue... everything has space, but I get errors with every command about there not being space in /var/something...
$ df -H Filesystem Size Used Avail Use% Mounted on udev 11M 275k 11M 3% /dev /dev/dm-0[/__active] 80G 27G 54G 33% / shm 1.1G 13M 1.1G 2% /dev/shm /dev/sda1 128M 31M 91M 26% /boot tmpfs 1.1G 50k 1.1G 1% /tmp
If no one has any suggestions... I may be looking at a reinstall tonight
OT: I still haven't played with Btrfs much (despite having a whole drive formated to it), but size calculation with it is a little tedious right now; it's one of the three big issues they'd like to work out before finally considering it "stable." Check out the faq on the btrfs homepage for more on that.
But I don't see exactly why that might be affecting yaourt; try just using makepkg for the time being, to narrow own whether it's a yaourt or filesystem issue. The error specifies an issue at a particular point in yaourt's processes (line 166), but I'm not so familiar with bash as to know how that all fits together. You could also check out ncdu, which gives a curses, bar-graph-style analysis of used space, to help troubleshoot.
I'll try that. What bothers me is that sudo is complaining about no disk space. I couldn't even shutdown cleanly. Exiting out of openbox gave me a completely frozen tty. No idea what's going on.
I can't even boot anymore. Wow did this go downhill fast. I can get past the request for encryption password, but then the init freezes at "Mounting Local Filesystems." I let it sit several times, once as long as 30min and no progress. If I boot from the Arch install disk, I can open the encrypted partition with luksOpen and mount the btrfs volume with no problems.
Not sure where to go from here! I'm running out of ideas. Apparently it's not completely bricked since I can mount it manually from an install disk, but something's obviously not working when it tries to boot.
I'm closing this and calling it a btrfs issue, though I can't be sure. I reinstalled last night. Bummer, but not a huge deal. I'm getting good at that...