bug#53194: System test partition.img differs in size across hosts(?)

[david larsson]

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