Guix, This is weird. On berlin: --8<---------------cut here---------------start------------->8--- $ guix build /gnu/store/91wjmydy556ibl38xydpb8yisp3gvx8w-partition.img.drv […] Creating filesystem with 351 1k blocks and 40 inodes […] /gnu/store/q18ca3ilma0h5hpn4s39xhzn0kc7jm5x-partition.img --8<---------------cut here---------------end--------------->8--- On my laptop: --8<---------------cut here---------------start------------->8--- $ guix build /gnu/store/91wjmydy556ibl38xydpb8yisp3gvx8w-partition.img.drv […] Creating filesystem with 242 1k blocks and 32 inodes […] Copying files into the device: ext2fs_symlink: Could not allocate inode in ext2 filesystem while creating symlink "system" __populate_fs: Could not allocate inode in ext2 filesystem while writing symlink"system" mke2fs: Could not allocate inode in ext2 filesystem while populating file system --8<---------------cut here---------------end--------------->8--- This happens with both a tmpfs and a bcachefs /tmp. The same make check-system TESTS="openvswitch" fails for Marius as well, although I don't know the exact output. They tested btrfs and tmpfs, and suggested a kernel regression. I don't understand how that would cause this, but I'm forced to agree: something spooky is going on in the chroot and the kernel is a big variable. The attached patch was written before I was aware of above weirdness and only works around the issue. Kind regards, T G-R