Hi! util-linux had two test failures on i686. From : --8<---------------cut here---------------start------------->8--- fdisk: invalid input tests ... FAILED (fdisk/oddinput) [...] misc: rev ... OK misc: setarch ... FAILED (misc/setarch) [...] --------------------------------------------------------------------- 2 tests of 170 FAILED --------------------------------------------------------------------- Makefile:12013: recipe for target 'check-local-tests' failed make[3]: *** [check-local-tests] Error 1 make[3]: Leaving directory '/tmp/guix-build-util-linux-2.27.drv-0/util-linux-2.27' --8<---------------cut here---------------end--------------->8--- On my laptop, commit v0.9.0-1181-gafe9f40, I’ve successfully run: ./pre-inst-env guix build util-linux -K -s i686-linux --rounds=3 which leads: /gnu/store/l1v12p64hv4373m1z7a16ar9s5cw1lwi-util-linux-2.27 SHA256: 18axyw2qhr7sq1jd15r6l02nkx9rijzws0xqlcl07d95v8xwbwj7 However, I’ve noticed that these tests consume quite few tens of MB in disk images: --8<---------------cut here---------------start------------->8--- ./ts/libfdisk/gpt:27:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/fdisk/oddinput:28:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/fdisk/bsd:89:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/fdisk/gpt:44:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/fdisk/mbr-dos-mode:52:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/fdisk/mbr-nondos-mode:48:TEST_IMAGE_NAME=$(ts_image_init 20) # 20 MiB ./ts/fdisk/id:29:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/fdisk/mbr-sort:50:TEST_IMAGE_NAME=$(ts_image_init 20) # 20 MiB ./ts/fdisk/sunlabel:40:TEST_IMAGE_NAME=$(ts_image_init 10) ./ts/libmount/context-py:140:img=$(ts_image_init) ./ts/libmount/context:138:img=$(ts_image_init) ./ts/losetup/losetup:42:BACKFILE=$(ts_image_init 10) ./ts/mount/regfile:19:IMAGE=$(ts_image_init) --8<---------------cut here---------------end--------------->8--- So the fdisk test failure above could well be due to that. The ‘setarch’ failure is less clear. It could be due to an old kernel that does not support this personality(2) call on the host machine. I’ve restarted the build from hydra.gnu.org, where it was scheduled on hydra.gnunet.org, and it passed this time (with the same content hash as above.) So we can keep building ‘core-updates’. :-) Ludo’.