On 2022-01-11 20:31, Tobias Geerinckx-Rice via Bug reports for GNU Guix wrote: > 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 I hope Im not totally off here, so Im just hoping this is worth mentioning: Are the hosts using the same version of https://github.com/guix-mirror/guix/blob/master/gnu/system/image.scm#96 ? It might produce different sizes if the hosts are on different guix commits - or is this not a possibility at all if the derivations have the same hashes? ...because I just happened to notice that recently the guix system image command produces images that are exactly the additional size of the root offset and the esp-partition compared to what's specified with the --image-size option. I think this has changed from 1-2 years back (since Marius B. blog post reg. Ganeti). I think so because when I set up Ganeti according to that blog post I could (IIRC) create guix instances with the ganeti-instance-guix create script without problem - and it produces images with guix system image --image-size=X command - but when I did so again 1-2 weeks ago they failed with the error that Ganeti disks were too small. The size issue could be resolved by removing from the instance create-script the exact number of bytes to the --image-size=X option that corresponded to the root offset and the esp-partition sizes as defined in (gnu system image). Maybe some commit has changed the size output of guix system image? Best regards, David