GNU bug report logs - #75205
guix package test failure on i686-linux (kexec-load-file test)

Previous Next

Full log

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

From: Ian Eure <ian <at> retrospec.tv>
To: 75205 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: guix package test failure on i686-linux (kexec-load-file test)
Date: Tue, 31 Dec 2024 20:17:09 -0800

This is failing for me on aarch64-linux also:

   test-name: kexec-load-file
   location: 
   /tmp/guix-build-guix-1.4.0-31.121e96d.drv-0/source/tests/syscalls.scm:688
   source:
   + (test-equal
   +   "kexec-load-file"
   +   EPERM
   +   (catch 'system-error
   +          (lambda ()
   +            (let ((fd1 (open-fdes "/dev/null" O_RDONLY))
   +                  (fd2 (open-fdes "/dev/null" O_RDONLY)))
   +              (kexec-load-file fd1 fd2 "gnu.repl=yes")))
   +          (lambda args (system-error-errno args))))
   expected-value: 1
   actual-value: 38
   result: FAIL

If I downgrade to commit 96cd163c14e68c66c6a4cf0b18261fc454f8c1ba, 
guix tests pass again -- the failing test was added in the next 
commit.  I’m not sure what the issue here, it seems like that 
syscall shouldn’t be arch-dependent, and the errnos in the 
failures are unhelpful.  38 is ERANGE, 14 is EFAULT, neither of 
those seem applicable here.  EPERM is 1, and 38 doesn’t have its 
LSB set, so it can’t be a bitmask.

I’m encountering the issue using Guix as a foreign package manager 
on top of Debian 12 "bookworm" in a VM.  Perhaps there’s an 
implicit dependency on the host system’s kernel in the test, which 
Debian’s fails to meet.

Ludo’, any thoughts?

 -- Ian

Previous Next

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