[PATCH] nfs-root test is failing

Hello,

I'm working on fixing all the system tests before the release. The

"nfs-root-fs" test is failing this way:

Danny, Stefan, do you think you could have a look?

Thanks,

Mathieu

block 47297 by 47744

quit

Hi Mathieu!

I remember that I did the sketch for this test, mainly copying from the other nfs tests. But in the end my Raspberry was too weak for testing or even compiling everything necessary. A bit later Danny improved the test and I got the impression that it was running.

I’ll try to take a look tomorrow, let’s see.

Bye

Stefan

Hi Mathieu and Danny!

I’m now sure that this test has never been working.

To get it working, first of all we need a change in (gnu system vm) to not discard a root file-system of type “nfs”. I did this change. I also cleaned up the test itself. See the attached patch.

The test needs two virtual machines communicating over TCP. The NFS client machine needs the linux command line argument “ip=dhcp“ (or a static IP setting) or some other code inside the initrd to bring the network interface up and running before mounting its root file-system over NFS. And finally some QEMU networking needs to be setup to have the NFS server and client talk to each other with proper IP addresses.

Unfortunately I have no clue how to achieve these two prerequisites. The kernel argument “ip=dhcp” does not help, as the driver for the network interface is not part of the linux-libre kernel. And also adding the initrd-module e1000 comes too late. On my Raspberry Pi I’m using a modified kernel with a build-in network driver and the “ip=dhcp” argument.

It seems to me that the base-initrd is missing an argument to add some arbitrary expression, or an option to configure the network interface, or the shepherd service which is provisioning 'networking. For network booting the initrd in Guix currently seems to be useless – however, getting rid of it is not trivial either.

With the attached changes, the NFS server side tests are passing, but the NFS client is missing an own IP address when trying to mount its root file-system, which results in this error when executing “make check-system TESTS=nfs-root”:

Welcome, this is GNU's early boot Guile.

Use '--repl' for an initrd REPL.

loading kernel modules...

[ 27.250034] e1000: Intel(R) PRO/1000 Network Driver

[ 27.250975] e1000: Copyright (c) 1999-2006 Intel Corporation.

[ 28.026651] PCI Interrupt Link [LNKC] enabled at IRQ 11

[ 28.377771] e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 52:54:00:12:34:56

[ 28.388012] e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection

[ 28.706203] usbcore: registered new interface driver usb-storage

[ 28.839354] usbcore: registered new interface driver uas

[ 28.922481] hid: raw HID events driver (C) Jiri Kosina

[ 28.942031] usbcore: registered new interface driver usbhid

[ 28.943247] usbhid: USB HID core driver

[ 29.425330] isci: Intel(R) C600 SAS Controller Driver - version 1.2.0

[ 30.100062] PCI Interrupt Link [LNKD] enabled at IRQ 10

[ 30.724003] PCI Interrupt Link [LNKA] enabled at IRQ 10

[ 31.335165] PCI Interrupt Link [LNKB] enabled at IRQ 11

[ 32.129714] virtio_blk virtio3: [vda] 143360 512-byte logical blocks (73.4 MB/70.0 MiB)

[ 32.167257] vda: vda1 vda2

[ 32.526742] random: crng init done

[ 32.624351] FS-Cache: Loaded

[ 32.675399] 9pnet: Installing 9P2000 support

[ 32.692551] 9p: Installing v9fs 9p2000 file system support

[ 32.695268] FS-Cache: Netfs '9p' registered for caching

configuring QEMU networking...

[ 32.842717] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX

[ 32.859236] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

In gnu/build/linux-boot.scm:

599:12 3 (_)

423:8 2 (mount-root-file-system ":/export" "nfs" # _ #:flags _ # ?)

In unknown file:

1 (mount ":/export" "/real-root" "nfs" 1 "addr=127.0.0.1")

In ice-9/boot-9.scm:

1669:16 0 (raise-exception _ #:continuable? _)

In procedure mount: No such device

[ 33.616971] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000

Bye

Stefan

Hello Stefan,

Thanks for having a look!

I also share the impression that this test never worked. Plus the actual

version has a lot of FIXME and commented lines that scare me off.

I think I'll remove the "nfs-root-fs" test for now. To fulfil their role

its important that the system test are functional. Otherwise its hard to

distinguish a test failing because of a regression from a test that has

always been broken.

Any objections?

Thanks,

Mathieu

unblock 47297 by 47744

quit

merge 47744 47956

quit

Hi!

A solution for the failing nfs-root test is part of http://issues.guix.gnu.org/48314.

I think this ticket can be closed.

Bye

Stefan

Hi!

Sorry, that was not quite correct. I sent a patch months back, which did not make it into this ticket, which solved this ticket but depends on http://issues.guix.gnu.org/48314.

Here it is again.

Bye

Stefan

tags 47744 + patch

tags 48314 + patch

block 47744 by 48314

retitle 48314 [PATCH] Install guix system on Raspberry Pi

retitle 47744 [PATCH] nfs-root test is failing

quit

Hi Ludovic!

Just for your information: The nfs-root test is kind of fixed, it was once blocking some other issue that you linked.

Bye

Stefan

Hello Stefan,

I turned the nfs-root-fs test into an nfs-full test that is based on

your patch. It spawns a VM with an NFS server and another VM that mounts

it.

It should now be possible to reintroduce an nfs-root-fs test so that the

client VM uses an NFS as its root directory.

Thanks,

Mathieu