From: david larsson <david.larsson@selfhosted.xyz>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: 53194@debbugs.gnu.org,
bug-Guix <bug-guix-bounces+someone=selfhosted.xyz@gnu.org>
Subject: bug#53194: System test partition.img differs in size across hosts(?)
Date: Thu, 17 Feb 2022 17:37:49 +0100 [thread overview]
Message-ID: <686be3f2c1cf4f7251533c521fc7bfa4@selfhosted.xyz> (raw)
In-Reply-To: <874k6akqlx.fsf@nckx>
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
prev parent reply other threads:[~2022-02-17 16:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-11 19:31 bug#53194: System test partition.img differs in size across hosts(?) Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-01-11 19:44 ` Tobias Geerinckx-Rice via Bug reports for GNU Guix
2022-02-04 5:23 ` Leo Famulari
2022-02-04 5:32 ` Leo Famulari
2022-02-04 16:55 ` Leo Famulari
2022-01-25 17:54 ` Maxim Cournoyer
2022-02-06 4:42 ` Maxim Cournoyer
2022-02-06 17:41 ` Leo Famulari
2022-02-07 21:29 ` Maxim Cournoyer
2022-10-31 8:56 ` Mathieu Othacehe
2022-02-04 4:43 ` Leo Famulari
2022-02-04 5:17 ` Leo Famulari
2022-02-17 16:37 ` david larsson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=686be3f2c1cf4f7251533c521fc7bfa4@selfhosted.xyz \
--to=david.larsson@selfhosted.xyz \
--cc=53194@debbugs.gnu.org \
--cc=bug-guix-bounces+someone=selfhosted.xyz@gnu.org \
--cc=me@tobias.gr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).