GNU bug report logs - #53194
System test partition.img differs in size across hosts(?)

Previous Next

Full log

Message #58 received at 53194 <at> debbugs.gnu.org (full text, mbox):

From: david larsson <david.larsson <at> selfhosted.xyz>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 53194 <at> debbugs.gnu.org,
 bug-Guix <bug-guix-bounces+someone=selfhosted.xyz <at> gnu.org>
Subject: Re: bug#53194: System test partition.img differs in size across
 hosts(?)
Date: Thu, 17 Feb 2022 17:37:49 +0100

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.