GNU bug report logs - #58205
reconfiguration stuck unless using '--no-grafts'

Previous Next

To reply to this bug, email your comments to 58205 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: reconfiguration stuck unless using '--no-grafts'
Date: Fri, 30 Sep 2022 17:18:18 -0400

Hi,

While working on Berlin today from a chroot, and with --no-substitutes
used for guix-daemon, I wasn't able to complete the 'guix system
reconfigure' step; it'd hand on a read call (seen using strace):

--8<---------------cut here---------------start------------->8---
statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) = 152
read(14, "gmlo\0\0\0\0", 8)             = 8
read(14, "\276\0\0\0\0\0\0\0", 8)       = 8
read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
)     = 12
write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for guix-1.3.0-29.9e46320 ...
) = 48
read(14, "gmlo\0\0\0\0", 8)             = 8
read(14, "\255\0\0\0\0\0\0\0", 8)       = 8
read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
\)                = 5
read(14,
--8<---------------cut here---------------end--------------->8---

After passing --no-grafts to 'guix system reconfigure', it could
complete without any error.

-- 
Thanks,
Maxim

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 58205 <at> debbugs.gnu.org
Subject: Re: bug#58205: reconfiguration stuck unless using '--no-grafts'
Date: Sun, 02 Oct 2022 22:19:23 +0200

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> While working on Berlin today from a chroot, and with --no-substitutes
> used for guix-daemon, I wasn't able to complete the 'guix system
> reconfigure' step; it'd hand on a read call (seen using strace):
>
> statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096, f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234, f_files=0, f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
> write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) = 152
> read(14, "gmlo\0\0\0\0", 8)             = 8
> read(14, "\276\0\0\0\0\0\0\0", 8)       = 8
> read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
> )     = 12
> write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for guix-1.3.0-29.9e46320 ...
> ) = 48
> read(14, "gmlo\0\0\0\0", 8)             = 8
> read(14, "\255\0\0\0\0\0\0\0", 8)       = 8
> read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
> \)                = 5
> read(14,

The build process is probably actually grafting things, and while doing
that it doesn’t output anything.  Thus it’s not surprising that the
client is stuck on read(2) waiting for data on the daemon socket.  It
might be that the grafting process is just taking a long time?

The way to debug that would be to run ‘sudo guix processes’, to identify
the build process and hand (the one that builds /gnu/store/kv1hg….drv in
the example above), and to strace that process.

HTH!

Ludo’.

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 58205 <at> debbugs.gnu.org
Subject: Re: bug#58205: reconfiguration stuck unless using '--no-grafts'
Date: Tue, 04 Oct 2022 08:42:31 -0400

Hi,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> While working on Berlin today from a chroot, and with --no-substitutes
>> used for guix-daemon, I wasn't able to complete the 'guix system
>> reconfigure' step; it'd hand on a read call (seen using strace):
>>
>> statfs("/gnu/store", {f_type=BTRFS_SUPER_MAGIC, f_bsize=4096,
>> f_blocks=26843282944, f_bfree=14069128626, f_bavail=14067391234,
>> f_files=0, f_ffree=0, f_fsid={val=[0x4f5822b0, 0xf74cbbd4]},
>> f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
>> write(14, "\t\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0006\0\0\0\0\0\0\0/gnu/sto"..., 152) = 152
>> read(14, "gmlo\0\0\0\0", 8)             = 8
>> read(14, "\276\0\0\0\0\0\0\0", 8)       = 8
>> read(14, "@ build-started /gnu/store/kv1gh"..., 192) = 192
>> )     = 12
>> write(2, "applying 3 grafts for guix-1.3.0"..., 48applying 3 grafts for guix-1.3.0-29.9e46320 ...
>> ) = 48
>> read(14, "gmlo\0\0\0\0", 8)             = 8
>> read(14, "\255\0\0\0\0\0\0\0", 8)       = 8
>> read(14, "@ build-log 17291 151\ngrafting '"..., 176) = 176
>> \)                = 5
>> read(14,
>
> The build process is probably actually grafting things, and while doing
> that it doesn’t output anything.  Thus it’s not surprising that the
> client is stuck on read(2) waiting for data on the daemon socket.  It
> might be that the grafting process is just taking a long time?

I think the CPU was idling at the time, per top.  Note that I was in a
chroot setup per info '(guix) Chrooting', with a pretty basic
'guix-daemon' invocation (non-chroot version), in case it could have
anything to do with it.

> The way to debug that would be to run ‘sudo guix processes’, to identify
> the build process and hand (the one that builds /gnu/store/kv1hg….drv in
> the example above), and to strace that process.

I'll do this next time I encounter this problem, thanks!

-- 
Maxim

Previous Next

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