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: --8<---------------cut here---------------start------------->8--- 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 #) 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.. --8<---------------cut here---------------end--------------->8--- 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: > 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