[PATCH] nfs-root test is failing

  • Done
  • quality assurance status badge
Details
5 participants
  • Ludovic Courtès
  • Mathieu Othacehe
  • Maxim Cournoyer
  • Mathieu Othacehe
  • Stefan
Owner
unassigned
Submitted by
Mathieu Othacehe
Severity
normal
Merged with
Blocked by
M
M
Mathieu Othacehe wrote on 13 Apr 2021 10:10
nfs-root-fs test is failing
(address . bug-guix@gnu.org)
87zgy2r4e7.fsf@gnu.org
Hello,

I'm working on fixing all the system tests before the release. The
"nfs-root-fs" test is failing this way:

Toggle snippet (55 lines)
mathieu@meije ~/guix [env]$ cat /gnu/store/s1byimibj7ax9b4nqg4qmpvhyf8wlcp8-nfs-root-fs-test/start-nfs-boot-test.log
%%%% Starting test start-nfs-boot-test
Group begin: start-nfs-boot-test
Test begin:
test-name: "nfs services are running"
source-file: "/gnu/store/m2lp9cq1nhhy5bydbzcy4svpb2wgsmx3-nfs-root-fs-test-builder"
source-line: 1
source-form: (test-assert "nfs services are running" (wait-for-file "/var/run/rpc.statd.pid" server-marionette))
Test end:
result-kind: pass
actual-value: 185
Test begin:
test-name: "NFS port is ready"
source-file: "/gnu/store/m2lp9cq1nhhy5bydbzcy4svpb2wgsmx3-nfs-root-fs-test-builder"
source-line: 1
source-form: (test-assert "NFS port is ready" (wait-for-tcp-port 2049 server-marionette))
Test end:
result-kind: pass
actual-value: #t
Test begin:
test-name: "NFS statd port is ready"
source-file: "/gnu/store/m2lp9cq1nhhy5bydbzcy4svpb2wgsmx3-nfs-root-fs-test-builder"
source-line: 1
source-form: (test-assert "NFS statd port is ready" (wait-for-tcp-port 20002 server-marionette))
Test end:
result-kind: fail
actual-value: #f
actual-error: (misc-error #f "nobody's listening on port ~S" (20002) #f)
Test begin:
test-name: "NFS mountd port is ready"
source-file: "/gnu/store/m2lp9cq1nhhy5bydbzcy4svpb2wgsmx3-nfs-root-fs-test-builder"
source-line: 1
source-form: (test-assert "NFS mountd port is ready" (wait-for-tcp-port 20001 server-marionette))
Test end:
result-kind: fail
actual-value: #f
actual-error: (misc-error #f "nobody's listening on port ~S" (20001) #f)
Test begin:
source-file: "/gnu/store/m2lp9cq1nhhy5bydbzcy4svpb2wgsmx3-nfs-root-fs-test-builder"
source-line: 1
source-form: (test-assert "nfs-root-client booted")
Test end:
result-kind: pass
actual-value: "nfs-root-client booted"
Test begin:
test-name: "nfs client deposited file"
source-file: "/gnu/store/m2lp9cq1nhhy5bydbzcy4svpb2wgsmx3-nfs-root-fs-test-builder"
source-line: 1
source-form: (test-assert "nfs client deposited file" (wait-for-file "/export/mounts" server-marionette))
Test end:
result-kind: fail
actual-value: #f
actual-error: (misc-error #f "file didn't show up ~S" ("/export/mounts") #f)

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

Thanks,

Mathieu
L
L
Ludovic Courtès wrote on 16 Apr 2021 22:12
control message for bug #47297
(address . control@debbugs.gnu.org)
87zgxy2dlu.fsf@gnu.org
block 47297 by 47744
quit
S
S
Stefan wrote on 17 Apr 2021 19:19
Re: nfs-root-fs test is failing
(address . bug-guix@gnu.org)
5D1C7300-09CB-49C6-8256-5CD25563FE20@vodafonemail.de
Hi Mathieu!

Toggle quote (5 lines)
> 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?

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
S
S
Stefan wrote on 18 Apr 2021 20:29
(address . bug-guix@gnu.org)
FFED044A-4E8B-48B8-8E5B-EDF8C40D6777@vodafonemail.de
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
M
M
Mathieu Othacehe wrote on 22 Apr 2021 11:30
(name . Stefan)(address . stefan-guix@vodafonemail.de)
87zgxqmzso.fsf@gnu.org
Hello Stefan,

Thanks for having a look!

Toggle quote (2 lines)
> I’m now sure that this test has never been working.

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.

Toggle quote (5 lines)
> 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”:

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
M
M
Mathieu Othacehe wrote on 25 Apr 2021 19:29
control message for bug #47297
(address . control@debbugs.gnu.org)
87wnsqtgrh.fsf@meije.i-did-not-set--mail-host-address--so-tickle-me
unblock 47297 by 47744
quit
M
M
Maxim Cournoyer wrote on 8 Aug 2021 05:54
control message for bug #47744
(address . control@debbugs.gnu.org)
87sfzk382n.fsf@gmail.com
merge 47744 47956
quit
S
S
Stefan wrote on 26 Sep 2021 14:57
nfs-root-fs test is failing
(address . 47744@debbugs.gnu.org)
46C90A67-00D4-462E-AF63-CB677C164205@vodafonemail.de
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
S
S
S
Stefan wrote on 13 Nov 2021 14:57
Adding patch tags
(address . control@debbugs.gnu.org)(name . Ludovic Courtès)(address . ludo@gnu.org)
BD1F8187-4952-4B75-A76E-F06C79A4BCF6@vodafonemail.de
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
M
M
Mathieu Othacehe wrote on 23 Dec 2021 11:01
Re: bug#47744: [PATCH] nfs-root test is failing
(name . Stefan)(address . stefan-guix@vodafonemail.de)(address . 47744-done@debbugs.gnu.org)
874k6z3ain.fsf_-_@gnu.org
Hello Stefan,

Toggle quote (4 lines)
> 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>.

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
Closed
?