#47744 [PATCH] nfs-root test is failing

Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: Mathieu Othacehe <othacehe@gnu.org>

To: bug-guix@gnu.org

Cc: Stefan <stefan-guix@vodafonemail.de>, Danny Milosavljevic <dannym@scratchpost.org>

Subject: nfs-root-fs test is failing

Date: Tue, 13 Apr 2021 10:10:40 +0200

Hello,

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

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

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

Thanks,

Mathieu

Message #10 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: Stefan <stefan-guix@vodafonemail.de>

To: Mathieu Othacehe <othacehe@gnu.org>, Danny Milosavljevic <dannym@scratchpost.org>

Cc: bug-guix@gnu.org

Subject: Re: nfs-root-fs test is failing

Date: Sat, 17 Apr 2021 19:19:03 +0200

Hi Mathieu!

> 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

Message #13 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: Stefan <stefan-guix@vodafonemail.de>

To: Mathieu Othacehe <othacehe@gnu.org>, Danny Milosavljevic <dannym@scratchpost.org>

Cc: bug-guix@gnu.org

Subject: Re: nfs-root-fs test is failing

Date: Sun, 18 Apr 2021 20:29:40 +0200

[Message part 1 (text/plain, inline)]

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

[0001-NFS-root-for-virtual-machines.patch (application/octet-stream, attachment)]

Message #16 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: Mathieu Othacehe <othacehe@gnu.org>

To: Stefan <stefan-guix@vodafonemail.de>

Cc: Danny Milosavljevic <dannym@scratchpost.org>, bug-guix@gnu.org

Subject: Re: nfs-root-fs test is failing

Date: Thu, 22 Apr 2021 11:30:47 +0200

Hello Stefan,

Thanks for having a look!

> 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.

> 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

Message #23 received at 47744@debbugs.gnu.org (full text, mbox, reply):

From: Stefan <stefan-guix@vodafonemail.de>

To: 47744@debbugs.gnu.org

Subject: nfs-root-fs test is failing

Date: Sun, 26 Sep 2021 14:57:47 +0200

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

Message #26 received at 47744@debbugs.gnu.org (full text, mbox, reply):

From: Stefan <stefan-guix@vodafonemail.de>

To: 47744@debbugs.gnu.org

Subject: Re: nfs-root-fs test is failing

Date: Tue, 28 Sep 2021 00:34:13 +0200

[Message part 1 (text/plain, inline)]

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

[nfs-root-for-virtual-machines.patch (application/octet-stream, attachment)]

Message #37 received at 47744-done@debbugs.gnu.org (full text, mbox, reply):

From: Mathieu Othacehe <othacehe@gnu.org>

To: Stefan <stefan-guix@vodafonemail.de>

Cc: 47744-done@debbugs.gnu.org

Subject: Re: bug#47744: [PATCH] nfs-root test is failing

Date: Thu, 23 Dec 2021 11:01:36 +0100

Hello Stefan,

> 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

Send a report that this bug log contains spam.