reconfiguration stuck unless using '--no-grafts'

> 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,

> Hi,

>

> Maxim Cournoyer <maxim.cournoyer@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.