"make check-system TESTS=basic" fails on master

Done

Details

4 participants

Chris Marusich
Ludovic Courtès
Tobias Geerinckx-Rice
zimoun

Owner: unassigned

Submitted by: Chris Marusich

Severity: normal

Chris Marusich wrote on 20 Oct 2018 21:09

Recipients:(address . bug-guix@gnu.org)

Message-ID:87k1mcqvt5.fsf@gmail.com

Hi Guix,

The system test "basic" fails on commit

7d1f21c69aa89e4c7c57ace26af80d168157b243 (master). To reproduce, check

out that commit and run:

make check-system TESTS="basic"

For the record, this is on an x86_64-linux GuixSD system using an ext4

root file system. Here's the error (I've sanitized the output, which

apparently contained some unprintable characters, and removed some lines

for brevity):

Toggle snippet (96 lines)qemu-system-x86_64: warning: hub 0 is not connected to host network
[?7l
[0mSeaBIOS (version rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org)
iPXE (http://ipxe.org) 00:03.0 C980 PCI2.10 PnP PMM+0FF91280+0FEF1280 C980
Press Ctrl-B to configure iPXE (PCI 00:03.0)...
                                                                               
Booting from ROM...
[?7l
[2J[    0.000000] Linux version 4.18.15-gnu (nixbld@) (gcc version 7.3.0 (GCC)) #1 SMP 1
[    0.000000] Command line: console=ttyS0 --root=/dev/vda1 --system=/gnu/store/pcjn1bvz1khr8k04qablc62rzwgfbh2b-system --load=/gnu/store/pcjn1bvz1khr8k04qablc62rzwgfbh2b-system/boot panic=1
[... Lines omitted for brevity ...]
[    0.000000] Kernel command line: console=ttyS0 --root=/dev/vda1 --system=/gnu/store/pcjn1bvz1khr8k04qablc62rzwgfbh2b-system --load=/gnu/store/pcjn1bvz1khr8k04qablc62rzwgfbh2b-system/boot panic=1
[... Lines omitted for brevity ...]
GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
GC Warning: Couldn't read /proc/stat
Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.
loading kernel modules...
[    1.425572] usbcore: registered new interface driver usb-storage
[    1.442635] usbcore: registered new interface driver uas
[    1.464201] hidraw: raw HID events driver (C) Jiri Kosina
[    1.469015] usbcore: registered new interface driver usbhid
[    1.470604] usbhid: USB HID core driver
[    1.526453] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[    1.564134] PCI Interrupt Link [LNKC] enabled at IRQ 11
[    1.594052] PCI Interrupt Link [LNKD] enabled at IRQ 10
[    1.623716] PCI Interrupt Link [LNKA] enabled at IRQ 10
[    1.653420] PCI Interrupt Link [LNKB] enabled at IRQ 11
[    1.701890] virtio_blk: probe of virtio4 failed with error -2
[    1.718210] virtio_net: probe of virtio0 failed with error -2
[    1.724827] virtio_console virtio3: Error -2 initializing vqs
[    1.726493] virtio_console: probe of virtio3 failed with error -2
[    1.732626] virtio_rng: probe of virtio1 failed with error -2
[    1.747209] FS-Cache: Loaded
[    1.753755] 9pnet: Installing 9P2000 support
[    1.756817] 9p: Installing v9fs 9p2000 file system support
[    1.758476] FS-Cache: Netfs '9p' registered for caching
[    1.767544] 9pnet_virtio: probe of virtio2 failed with error -2
In gnu/build/linux-boot.scm:
   516:13  2 (_)
    367:8  1 (mount-root-file-system "/dev/vda1" "ext4" # _)
In unknown file:
          [    1.798957] random: fast init done
 0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)
In procedure mount: No such file or directory
[    1.808236] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[    1.808236] 
[    1.810919] CPU: 0 PID: 1 Comm: init Not tainted 4.18.15-gnu #1
[    1.812019] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
[    1.812019] Call Trace:
[    1.812019]  dump_stack+0x63/0x85
[    1.812019]  panic+0xe4/0x244
[    1.812019]  do_exit+0xb1a/0xb20
[    1.812019]  ? wake_up_state+0x10/0x20
[    1.812019]  do_group_exit+0x43/0xb0
[    1.812019]  __x64_sys_exit_group+0x18/0x20
[    1.812019]  do_syscall_64+0x5a/0x120
[    1.812019]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    1.812019] RIP: 0033:0x5ecce6
[    1.812019] Code: Bad RIP value.
[    1.812019] RSP: 002b:00007ffdddceb3e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[    1.812019] RAX: ffffffffffffffda RBX: 0000000000812ff0 RCX: 00000000005ecce6
[    1.812019] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[    1.812019] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffffb0
[    1.812019] R10: 00007f85d01aef88 R11: 0000000000000246 R12: 0000000000a63818
[    1.812019] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003
[    1.812019] Kernel Offset: 0x2a000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    1.812019] Rebooting in 1 seconds..
QEMU runs as PID 4
connected to QEMU's monitor
read QEMU monitor prompt
connected to guest REPL
%%%% Starting test basic  (Writing full log to "basic.log")
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL uname
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL shepherd socket ready
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL shell and user commands
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL special files
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL accounts
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL shepherd services
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL homes
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL skeletons in home directories
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL permissions on /root
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL no extra home directories
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL login on tty1
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL utmpx entry
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL wtmp entry
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL host name resolution
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL locale
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL /run/current-system is a GC root
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL /var/guix/gcroots/profiles is a valid symlink
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL screendump
/gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL screen text
# of expected passes      1
# of unexpected failures  19

Some questions/observations:

1) Where is the "basic.log" file? I checked the Guix checkout and the

retained directory of the failed derivation (i.e., the directory

produced by guix build --keep-failed /gnu/store/...gjmid5-basic.drv),

but I don't see it anywhere.

2) The test seems to have failed becuase of the following issue, which

is mentioned in the output above:

Toggle snippet (4 lines)

0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)

In procedure mount: No such file or directory

The next steps are probably to look into whether /dev/vda1 or /real-root
exist when that call is made, and if one of them is missing, investigate
why it doesn't exist.

-- 
Chris

Ludovic Courtès wrote on 22 Oct 2018 15:11

Recipients:(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33106@debbugs.gnu.org)

Message-ID:87pnw2jfc5.fsf@gnu.org

Hello,

Chris Marusich <cmmarusich@gmail.com> skribis:

Toggle quote (6 lines)

> The system test "basic" fails on commit

> 7d1f21c69aa89e4c7c57ace26af80d168157b243 (master). To reproduce, check

> out that commit and run:

> make check-system TESTS="basic"

It passes for me as of ff598353c01b1953243ba0ecb87efbd73c66720e, on

x86_64-linux.

[...]

Toggle quote (19 lines)> [    1.701890] virtio_blk: probe of virtio4 failed with error -2
> [    1.718210] virtio_net: probe of virtio0 failed with error -2
> [    1.724827] virtio_console virtio3: Error -2 initializing vqs
> [    1.726493] virtio_console: probe of virtio3 failed with error -2
> [    1.732626] virtio_rng: probe of virtio1 failed with error -2
> [    1.747209] FS-Cache: Loaded
> [    1.753755] 9pnet: Installing 9P2000 support
> [    1.756817] 9p: Installing v9fs 9p2000 file system support
> [    1.758476] FS-Cache: Netfs '9p' registered for caching
> [    1.767544] 9pnet_virtio: probe of virtio2 failed with error -2
> In gnu/build/linux-boot.scm:
>    516:13  2 (_)
>     367:8  1 (mount-root-file-system "/dev/vda1" "ext4" # _)
> In unknown file:
>           [    1.798957] random: fast init done
>  0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)
> In procedure mount: No such file or directory
> [    1.808236] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

Instead of these ‘virtio’ error, I see this (excerpt):

Toggle snippet (26 lines)Welcome, this is GNU's early boot Guile.
Use '--repl' for an initrd REPL.

loading kernel modules...
[    0.652780] usbcore: registered new interface driver usb-storage
[    0.654790] usbcore: registered new interface driver uas
[    0.660951] hidraw: raw HID events driver (C) Jiri Kosina
[    0.661917] usbcore: registered new interface driver usbhid
[    0.662504] usbhid: USB HID core driver
[    0.668512] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[    0.687586] PCI Interrupt Link [LNKC] enabled at IRQ 11
[    0.706161] PCI Interrupt Link [LNKD] enabled at IRQ 10
[    0.724746] PCI Interrupt Link [LNKA] enabled at IRQ 10
[    0.743427] PCI Interrupt Link [LNKB] enabled at IRQ 11
[    0.765047] virtio_blk virtio4: [vda] 143360 512-byte logical blocks (73.4 MB/70.0 MiB)
[    0.766293]  vda: vda1 vda2
[    0.782675] FS-Cache: Loaded
[    0.784778] 9pnet: Installing 9P2000 support
[    0.785387] random: fast init done
[    0.786349] 9p: Installing v9fs 9p2000 file system support
[    0.787101] FS-Cache: Netfs '9p' registered for caching
[    0.788027] random: crng init done
[    0.792200] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null)
loading '/gnu/store/vwyynlbmkrg1mr4d56n6x9vcnfw9hnw2-system/boot'...

I could be a QEMU or a kernel error. Does it still manifest with

today’s master?

Toggle quote (31 lines)> %%%% Starting test basic  (Writing full log to "basic.log")
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL uname
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL shepherd socket ready
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL shell and user commands
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL special files
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL accounts
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL shepherd services
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL homes
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL skeletons in home directories
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL permissions on /root
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL no extra home directories
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:1: FAIL login on tty1
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL utmpx entry
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL wtmp entry
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL host name resolution
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL locale
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL /run/current-system is a GC root
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL /var/guix/gcroots/profiles is a valid symlink
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL screendump
> /gnu/store/b1f0pn2zp33b0q06cp39yk9p1qasxzqi-basic-builder:2: FAIL screen text
> # of expected passes      1
> # of unexpected failures  19
>
>
> Some questions/observations:
>
> 1) Where is the "basic.log" file?  I checked the Guix checkout and the
> retained directory of the failed derivation (i.e., the directory
> produced by guix build --keep-failed /gnu/store/...gjmid5-basic.drv),
> but I don't see it anywhere.

The ‘basic.log’ file is in the output of this derivation. The

derivation is built with #:keep-failed? #t, so the output is still

around upon failure and ‘make check-system’ prints it upon completion

with something like:

TOTAL: 1

FAIL: /gnu/store/gmsv8dlxd88p37qc74pdn5jgiikbyxwv-basic

Thanks for your report,

Ludo’.

Chris Marusich wrote on 23 Oct 2018 10:58

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 33106@debbugs.gnu.org)

Message-ID:87lg6pujj8.fsf@garuda.local.i-did-not-set--mail-host-address--so-tickle-me

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (3 lines)

> It passes for me as of ff598353c01b1953243ba0ecb87efbd73c66720e, on

> x86_64-linux.

I rebuilt Guix from a clean checkout of commit

ff598353c01b1953243ba0ecb87efbd73c66720e, and then I ran the test again.

It still failed. The error messages are the same as before.

Toggle quote (3 lines)

> I could be a QEMU or a kernel error. Does it still manifest with

> today’s master?

I just did a Git pull; the master branch head currently points to

a89f731b1506b3b560f4a179da2889408dfa881d. I'm rebuilding Guix from a

fresh checkout of this commit. Once it's done, I'll let you know

whether the system test passes.

Toggle quote (13 lines)>> 1) Where is the "basic.log" file?  I checked the Guix checkout and the
>> retained directory of the failed derivation (i.e., the directory
>> produced by guix build --keep-failed /gnu/store/...gjmid5-basic.drv),
>> but I don't see it anywhere.
>
> The ‘basic.log’ file is in the output of this derivation.  The
> derivation is built with #:keep-failed? #t, so the output is still
> around upon failure and ‘make check-system’ prints it upon completion
> with something like:
>
>   TOTAL: 1
>   FAIL: /gnu/store/gmsv8dlxd88p37qc74pdn5jgiikbyxwv-basic

Understood! I was confused and looking in the wrong place.

Chris

Chris Marusich wrote on 24 Oct 2018 03:49

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 33106@debbugs.gnu.org)

Message-ID:871s8gp10g.fsf@gmail.com

Chris Marusich <cmmarusich@gmail.com> writes:

Toggle quote (5 lines)

> I just did a Git pull; the master branch head currently points to

> a89f731b1506b3b560f4a179da2889408dfa881d. I'm rebuilding Guix from a

> fresh checkout of this commit. Once it's done, I'll let you know

> whether the system test passes.

It still fails, with similar error messages. For what it's worth, here

is the output of my "uname -a":

Linux garuda.local 4.18.13-gnu #1 SMP 1 x86_64 GNU/Linux

I'm not sure how to proceed. For now, I'll try this: do a "guix pull"

from a89f731b1506b3b560f4a179da2889408dfa881d, reconfigure my GuixSD

system, and try again. I'll let you know how it goes.

Chris

Ludovic Courtès wrote on 24 Oct 2018 14:14

Recipients:(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33106@debbugs.gnu.org)

Message-ID:87k1m75ypf.fsf@gnu.org

Chris Marusich <cmmarusich@gmail.com> skribis:

Toggle quote (16 lines)> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> I just did a Git pull; the master branch head currently points to
>> a89f731b1506b3b560f4a179da2889408dfa881d.  I'm rebuilding Guix from a
>> fresh checkout of this commit.  Once it's done, I'll let you know
>> whether the system test passes.
>
> It still fails, with similar error messages.  For what it's worth, here
> is the output of my "uname -a":
>
>     Linux garuda.local 4.18.13-gnu #1 SMP 1 x86_64 GNU/Linux
>
> I'm not sure how to proceed.  For now, I'll try this: do a "guix pull"
> from a89f731b1506b3b560f4a179da2889408dfa881d, reconfigure my GuixSD
> system, and try again.  I'll let you know how it goes.

Hmm, super weird. Does the machine support KVM properly? Any hints in

‘dmesg’ or /var/log/messages? Is this GuixSD running on the bare metal?

Thanks,

Ludo’.

Chris Marusich wrote on 26 Oct 2018 07:11

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 33106@debbugs.gnu.org)

Message-ID:875zxppa1a.fsf@gmail.com

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (3 lines)

> Hmm, super weird. Does the machine support KVM properly? Any hints in

> ‘dmesg’ or /var/log/messages? Is this GuixSD running on the bare metal?

I haven't seen any KVM-related problems in the past. I checked dmesg,

messages, and a couple other log files for obvious problems, but I

couldn't find any. This GuixSD is running on bare metal (a Lenovo X200

with Libreboot, to be precise).

I'm still waiting for my "guix system reconfigure" to finish. I ran it

overnight, it failed while updating substitutes [1], and now I'm running

it again without substitutes. I'll update this bug report when I have

more information.

Footnotes:

[1] https://debbugs.gnu.org/33159

Chris

Ludovic Courtès wrote on 26 Oct 2018 11:44

Recipients:(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33106@debbugs.gnu.org)

Message-ID:87lg6lnit2.fsf@gnu.org

Chris Marusich <cmmarusich@gmail.com> skribis:

Toggle quote (10 lines)> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Hmm, super weird.  Does the machine support KVM properly?  Any hints in
>> ‘dmesg’ or /var/log/messages?  Is this GuixSD running on the bare metal?
>
> I haven't seen any KVM-related problems in the past.  I checked dmesg,
> messages, and a couple other log files for obvious problems, but I
> couldn't find any.  This GuixSD is running on bare metal (a Lenovo X200
> with Libreboot, to be precise).

Did it work before on this machine? I have a vague recollection that

there were KVM issues on the X200. This is x86_64?

Thanks,

Ludo’.

Chris Marusich wrote on 26 Oct 2018 18:14

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 33106@debbugs.gnu.org)

Message-ID:87lg6kn0s2.fsf@gmail.com

Hi,

I've reconfigured my system after running "guix pull":

root@garuda ~# guix describe

Generation 6 Oct 23 2018 19:29:12 (current)

guix a89f731

repository URL: https://git.savannah.gnu.org/git/guix.git

commit: a89f731b1506b3b560f4a179da2889408dfa881d

GUIX_PACKAGE_PATH="/home/marusich/custom-guix-packages"

root@garuda ~#

The problem still occurs, but now there are no 9p-related errors:

Toggle snippet (49 lines)loading kernel modules...
[    1.350969] usbcore: registered new interface driver usb-storage
[    1.366341] usbcore: registered new interface driver uas
[    1.385533] hidraw: raw HID events driver (C) Jiri Kosina
[    1.389538] usbcore: registered new interface driver usbhid
[    1.391152] usbhid: USB HID core driver
[    1.443626] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
[    1.480467] PCI Interrupt Link [LNKC] enabled at IRQ 11
[    1.510120] PCI Interrupt Link [LNKD] enabled at IRQ 10
[    1.539737] PCI Interrupt Link [LNKA] enabled at IRQ 10
[    1.569364] PCI Interrupt Link [LNKB] enabled at IRQ 11
[    1.618251] virtio_blk virtio4: [vda] 143360 512-byte logical blocks (73.4 MB/70.0 MiB)
[    1.667705] random: fast init done
[    1.669014] random: crng init done
[    1.671153] FS-Cache: Loaded
[    1.677011] 9pnet: Installing 9P2000 support
[    1.679743] 9p: Installing v9fs 9p2000 file system support
[    1.681353] FS-Cache: Netfs '9p' registered for caching
In gnu/build/linux-boot.scm:
   516:13  2 (_)
    367:8  1 (mount-root-file-system "/dev/vda1" "ext4" # _)
In unknown file:
           0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)
In procedure mount: No such file or directory
[    1.727459] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000
[    1.727459] 
[    1.728372] CPU: 0 PID: 1 Comm: init Not tainted 4.18.16-gnu #1
[    1.728372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
[    1.728372] Call Trace:
[    1.728372]  dump_stack+0x63/0x85
[    1.728372]  panic+0xe4/0x244
[    1.728372]  do_exit+0xb1a/0xb20
[    1.728372]  ? wake_up_state+0x10/0x20
[    1.728372]  do_group_exit+0x43/0xb0
[    1.728372]  __x64_sys_exit_group+0x18/0x20
[    1.728372]  do_syscall_64+0x5a/0x120
[    1.728372]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[    1.728372] RIP: 0033:0x5ecce6
[    1.728372] Code: Bad RIP value.
[    1.728372] RSP: 002b:00007ffcd54c8318 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
[    1.728372] RAX: ffffffffffffffda RBX: 0000000000812ff0 RCX: 00000000005ecce6
[    1.728372] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
[    1.728372] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffffb0
[    1.728372] R10: 00007f8613be5f88 R11: 0000000000000246 R12: 0000000000a63818
[    1.728372] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003
[    1.728372] Kernel Offset: 0x27000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[    1.728372] Rebooting in 1 seconds..

I took a closer look at my dmesg output. I now notice that the

following line gets emitted when the error occurs moments before the

error occurs in the test:

[ 909.759703] kvm [1279]: vcpu0, guest rIP: 0xffffffffb1068bec disabled perfctr wrmsr: 0xc2 data 0xffff

I'm not sure exactly what it means, or if it's bad. Both the QEMU and

the dmesg output seem to mention a RIP value, and they both occur close

in time, so it seems suspicious. Looking back in my /var/log/messages,

which I haven't rotated or truncated in quite some time, it seems there

are many entries like this. The earliest such entry appears to be from

March 20th of 2017. I don't know if I ran the system tests successfully

after that point in time on this machine.

ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (3 lines)

> Did it work before on this machine? I have a vague recollection that

> there were KVM issues on the X200. This is x86_64?

This is x86_64, and the test did pass in the past (but I'm not sure when

I was last able to do so successfully).

Chris

Ludovic Courtès wrote on 27 Oct 2018 16:37

Recipients:(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33106@debbugs.gnu.org)

Message-ID:87ftwra21x.fsf@gnu.org

Hello,

Chris Marusich <cmmarusich@gmail.com> skribis:

Toggle quote (27 lines)> The problem still occurs, but now there are no 9p-related errors:
>
> loading kernel modules...
> [    1.350969] usbcore: registered new interface driver usb-storage
> [    1.366341] usbcore: registered new interface driver uas
> [    1.385533] hidraw: raw HID events driver (C) Jiri Kosina
> [    1.389538] usbcore: registered new interface driver usbhid
> [    1.391152] usbhid: USB HID core driver
> [    1.443626] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0
> [    1.480467] PCI Interrupt Link [LNKC] enabled at IRQ 11
> [    1.510120] PCI Interrupt Link [LNKD] enabled at IRQ 10
> [    1.539737] PCI Interrupt Link [LNKA] enabled at IRQ 10
> [    1.569364] PCI Interrupt Link [LNKB] enabled at IRQ 11
> [    1.618251] virtio_blk virtio4: [vda] 143360 512-byte logical blocks (73.4 MB/70.0 MiB)
> [    1.667705] random: fast init done
> [    1.669014] random: crng init done
> [    1.671153] FS-Cache: Loaded
> [    1.677011] 9pnet: Installing 9P2000 support
> [    1.679743] 9p: Installing v9fs 9p2000 file system support
> [    1.681353] FS-Cache: Netfs '9p' registered for caching
> In gnu/build/linux-boot.scm:
>    516:13  2 (_)
>     367:8  1 (mount-root-file-system "/dev/vda1" "ext4" # _)
> In unknown file:
>            0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)
> In procedure mount: No such file or directory

Could you launch QEMU by hand (grab the command line from the derivation

builder or something like that) to get to the initrd REPL when this

error occurs, and from there inspect what’s in /dev?

I don’t have any better idea. :-/

Thanks,

Ludo’.

Ludovic Courtès wrote on 14 Nov 2018 11:23

control message for bug #33106

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87tvkkj6ua.fsf@gnu.org

tags 33106 moreinfo

Tobias Geerinckx-Rice wrote on 30 Nov 2020 22:36

"make check-system TESTS=basic" fails on master

Recipients:

Message-ID:87r1oawmqg.fsf@nckx

Chris!

Is this 2+-year-old bug still relevant? Do you still have the

hardware to reproduce it?

Kind regards,

T G-R

-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCX8Vl5w0cbWVAdG9iaWFz

LmdyAAoJEA2w/4hPVW15PrABAJdm1Q41bAV2RGJkpVnvyzXRtZyXNb5XPqTCDSd7

CUu2AQDfvzCJnWp99IBUK1A40g77YLQ++0s6BJo+YNb0uvBKDA==

=oAsc

-----END PGP SIGNATURE-----

zimoun wrote on 19 Dec 2020 10:08

Recipients:(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33106@debbugs.gnu.org)

Message-ID:86czz6rwne.fsf@gmail.com

Hi Chris,

This bug#33106 is old with last activity 2+ years ago and tagged

’moreinfo’ also 2+ years ago. Tobias asked [1] if it is possible to

reproduce now?

1: http://issues.guix.gnu.org/issue/33106#10

On Sat, 20 Oct 2018 at 12:09, Chris Marusich <cmmarusich@gmail.com> wrote:

Toggle quote (11 lines)> The system test "basic" fails on commit
> 7d1f21c69aa89e4c7c57ace26af80d168157b243 (master).  To reproduce, check
> out that commit and run:
>
>     make check-system TESTS="basic"
>
> For the record, this is on an x86_64-linux GuixSD system using an ext4
> root file system.  Here's the error (I've sanitized the output, which
> apparently contained some unprintable characters, and removed some lines
> for brevity):

[...]

Toggle quote (15 lines)> 1) Where is the "basic.log" file?  I checked the Guix checkout and the
> retained directory of the failed derivation (i.e., the directory
> produced by guix build --keep-failed /gnu/store/...gjmid5-basic.drv),
> but I don't see it anywhere.
>
> 2) The test seems to have failed becuase of the following issue, which
> is mentioned in the output above:
>
> 0 (mount "/dev/vda1" "/real-root" "ext4" 1 #<undefined>)
> In procedure mount: No such file or directory
>
> The next steps are probably to look into whether /dev/vda1 or /real-root
> exist when that call is made, and if one of them is missing, investigate
> why it doesn't exist.

If no moreinfo, this bug will be closed in the coming days.

All the best,

simon

PS: Chris, I hope that everything is fine on your side because I have

not read something from you since long time.

zimoun wrote on 22 Dec 2020 15:13

Recipients:(name . Chris Marusich)(address . cmmarusich@gmail.com)(address . 33106-done@debbugs.gnu.org)

Message-ID:865z4u7wu1.fsf@gmail.com

Hi,

On Sat, 19 Dec 2020 at 10:08, zimoun <zimon.toutoune@gmail.com> wrote:

Toggle quote (14 lines)> This bug#33106 is old with last activity 2+ years ago and tagged
> ’moreinfo’ also 2+ years ago.  Tobias asked [1] if it is possible to
> reproduce now?
>
> 1: <http://issues.guix.gnu.org/issue/33106#10>
>
> On Sat, 20 Oct 2018 at 12:09, Chris Marusich <cmmarusich@gmail.com> wrote:
>
>> The system test "basic" fails on commit
>> 7d1f21c69aa89e4c7c57ace26af80d168157b243 (master).  To reproduce, check
>> out that commit and run:
>>
>>     make check-system TESTS="basic"

[...]

Toggle quote (2 lines)

> If no moreinfo, this bug will be closed in the coming days.

I am closing. Feel free to reopen if I misunderstood something.

All the best,

simon

Closed

Your comment

This issue is archived.

To comment on this conversation send an email to 33106@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 33106

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date