Hi Yarl,
Yarl <[email protected]> writes:
Ian Eure <[email protected]> writes:
I know /tmp running out of space can cause this, so I have 24gb
of
swap added:
$ free -m
total used free shared
buff/cache available
Mem: 902 197 115 0
677
704
Swap: 24191 49 24142
I ran `watch -n 1 df -h' while building the image, neither /
nor /tmp
usage increases appreciably, and nothing is filling up.
Hi,
I personnaly ask the daemon to build outside of /tmp on such
hardware. For example on a foreign distro with systemd, I have a
line
like this
Environment=LC_ALL=C.UTF-8 TMPDIR=/mnt/tmp
in /usr/lib/systemd/system/guix-daemon.service
https://www.kernel.org/doc/html/latest/filesystems/tmpfs.html on
sizing:
The default is half of your physical RAM without swap. If you
oversize
your tmpfs instances the machine will deadlock since the OOM
handler
will not be able to free that memory.
Thank you for the suggestion; I know tmpfs uses main RAM, but I
assumed it would use swap as well.
Unfortunately, I get the same "Disk full" error after telling
guix-daemon to use /var/tmp/guix. I made the directory with the
correct 1777 permissions and root:root ownership; verified it’s on
my
root filesystem; and confirmed via /proc/$PID/environ that the
daemon’s TMPDIR is pointed there. The issue is actually totally
unrelated to /tmp storage.
The procedure which raises the error is `make-vfat-image', from
(gnu
build image), and it’s running:
mcopy -bsp -i
/gnu/store/735nmj7g2b16nvnsrjkb1ihx4ygsk15y-partition.img \
tmp-root/gnu ::gnu
I understand what this is doing -- it’s asking to copy
tmp-root/gnu on the local filesystem to the gnu directory of the
specified image -- but I have no idea *why* it’s doing that.
The partition image is the 2gb vfat one, for /boot/efi. It
shouldn’t have a store on it, the 14gb ext4 for the root should.
So why is it trying to copy store items into the wrong place?
Worse, I looked inside the image file, and it *already* has a
bunch of the wrong files in it:
$ mdir -i
/gnu/store/1c1pvr29zkf87mxxxfh0lpdin93309fy-partition.img
Volume in drive : is EFI
Volume Serial Number is 2E60-83B7
Directory for ::/
bin <DIR> 2026-05-24 20:43
boot <DIR> 2026-05-24 20:43
etc <DIR> 2026-05-24 20:43
gnu <DIR> 2026-05-24 20:43
4 files 0 bytes
47 710 208 bytes free
So, yeah, that’s just flat wrong. I suspect what’s actually
happening is that the image code can’t match up the declared
partitions with the declared file-systems, and puts all files into
the first partition in the list. And since that’s the 2gb vfat
partition, the whole process fails.
Happy to be proven wrong about this.
-- Ian
