openhabian (rasbian): NFS funktioniert plötzlich nicht mehr

[X__]

Hi zusammen,

ich habe einen Raspberry 4, den ich als Hausautomatisations-Server laufen habe (OpenHAB, headless).
Zur komfortablen Anpassung habe ich eine NFS-Freigabe, über die ich von meinem Manjaro direkt auf die
Konfigurationsdateien zugreifen kann. Hat seit Monaten auch super funktioniert.

Gestern hatte ich (ich meine, es war nach einem Neustart) plötzlich keinen Zugriff mehr auf die Freigabe.
apt-get update/upgrade ist gemacht und ich habe versucht den NFS-Server neu zu installieren.

Dabei kommt folgende Meldung:

x@y:~ $ sudo apt-get reinstall nfs-kernel-server
[sudo] password for x:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/108 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 68408 files and directories currently installed.)
Preparing to unpack .../nfs-kernel-server_1%3a1.3.4-2.5+deb10u1_armhf.deb ...
Unpacking nfs-kernel-server (1:1.3.4-2.5+deb10u1) over (1:1.3.4-2.5+deb10u1) ...
Setting up nfs-kernel-server (1:1.3.4-2.5+deb10u1) ...
A dependency job for nfs-server.service failed. See 'journalctl -xe' for details.
A dependency job for nfs-server.service failed. See 'journalctl -xe' for details.
invoke-rc.d: initscript nfs-kernel-server, action "restart" failed.
● nfs-server.service - NFS server and services
Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
Active: inactive (dead)

Aug 10 15:29:50 ourhouse systemd[1]: Dependency failed for NFS server and services.
Aug 10 15:29:50 ourhouse systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Aug 10 15:31:10 ourhouse systemd[1]: Dependency failed for NFS server and services.
Aug 10 15:31:10 ourhouse systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Aug 10 15:31:14 ourhouse systemd[1]: Dependency failed for NFS server and services.
Aug 10 15:31:14 ourhouse systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Aug 10 16:10:31 ourhouse systemd[1]: Dependency failed for NFS server and services.
Aug 10 16:10:31 ourhouse systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Aug 10 16:10:34 ourhouse systemd[1]: Dependency failed for NFS server and services.
Aug 10 16:10:34 ourhouse systemd[1]: nfs-server.service: Job nfs-server.service/start failed with result 'dependency'.
Failed to restart nfs-kernel-server, ignoring.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u7+rpi1) ...
Updating FireMotD available updates count ...

Leider bin ich noch nicht so tief in Linux drin, dass ich das Problem selber in den Griff bekomme.

 

[Tiril]

was spuckt journalctl -xe aus?

 

[X__]

Ich hab den betreffenden Inhalt mal hochgeladen.
Ich werd' da nicht so recht schlau draus ..

Ich hab noch weitere Infos, mit denen ich aber auch nicht so richtig weiterkomme:

:~ $ modinfo nfsd
libkmod: ERROR ../libkmod/libkmod.c:586 kmod_search_moddep: could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
modinfo: ERROR: Module alias nfsd not found.

:~ $ lsmod
Module                  Size  Used by

"lsmod" zeigt gar nichts an ?! Ist das normal ?

 

[X__]

Keiner ' ne Idee ?

 

[Sommersocke]

Hallo!

Ich kenne dein OS nicht, aber der Fehler ist klar. Er kann das Kernelmodul offenbar nicht laden. Da kann es viele Möglichkeiten geben, ist aber sehr distributionsspezifisch, da ja jeder irgendwelchen proprietären Müll in den Kernel packt. Als generelle Analyse mal folgendes: Raspi neu starten, kurz warten bis er „voll da ist“, dann wieder per ssh drauf und

journalctl -b -xep 0..4  # alle Warnungen und Fehlerstati seit dem Reboot
modprobe -v nfsd  # Modul zu laden versuchen. Falls keine aussagekräftigen Fehler dabei sind: manuell versuchen

#manuell
insmod /lib/modules/$(uname -r)/kernel/net/sunrpc/sunrpc.ko.zst
insmod /lib/modules/$(uname -r)/kernel/fs/nfs_common/grace.ko.zst
insmod /lib/modules/$(uname -r)/kernel/fs/lockd/lockd.ko.zst
insmod /lib/modules/$(uname -r)/kernel/fs/nfs_common/nfs_acl.ko.zst
insmod /lib/modules/$(uname -r)/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko.zst
insmod /lib/modules/$(uname -r)/kernel/fs/nfsd/nfsd.ko.zst nfs4_disable_idmapping=0

nfs4_disable_idmapping=0 steht drin, weil ich meine das in deinem Log gesehen zu haben. Ansonsten ohne probieren.

modprobe macht nichts anderes, als die Kernelmodule in Abhängigkeit nacheinander zu laden und das Verzeichnis zu ermitteln. Das müsstest du bei dir noch prüfen, auf meinen Maschinen liegen die Dateien da. (Einfach ls -lha anstatt insmod verwenden)
Es gäbe auch noch modprobe -f für force. Das sind alles temporäre Methoden, wenn also irgendwas schiefgeht: Neu starten.

Da solltest du entsprechende Fehlermeldungen bekommen, die weiterhelfen. Neu installieren bringt übrigens in 99,9% der Fälle rein gar nichts, da die Konfigurationen erhalten bleiben und Pakete selbst nicht kaputt gehen (Festplattenfehler, etc. seien ander Stelle ausgenommen). Das ist so wie neu starten: Das repariert nix, außer solche temporären settings, wie manuell eingefügte Module — falls rmmod nicht funktioniert.

Der langen Rede kurzer Sinn: Ich mutmaße mal eine verstellte Konfiguration oder Kernelaktualisierung.

 

[X__]

@Sommersocke
Vielen Dank schon mal. Ich werde das morgen mal in Ruhe probieren und melde mich dann.

 

[X__]

Kleine Info vorweg:
In einen anderen Forum hatte ich von einem gleichgearteten Problem
gelesen und war die Ursache wohl auch einen Kernel-Inkompatibilität.
Dort war das ausführen von

sudo rpi-update 0642816ed05d31fb37fc8fbbba9e1774b475113f

Teil der Lösung. Hatte bei mir aber so nicht den gewünschten Effekt
ist aber von mir ausgeführt worden.
Ich bin mir jetzt aber nicht sicher, ob das Auswirkungen hatte, denn
der Hash bezieht sich auf kernel: Bump to 5.4.79, wenn ich das richtig verstehe.
Bei mir scheint ja (siehe unten) die Version 5.10.17 noch aktiv zu sein.

Also zu deinen Vorschlägen:

Spoiler: journalctl -b -xep 0..4

-- Logs begin at Mon 2021-08-09 18:41:59 CEST, end at Sat 2021-08-14 10:05:47 CEST. --
Aug 14 09:59:29 ourhouse kernel: Kernel parameter elevator= does not have any effect anymore.
                                 Please use sysfs to set IO scheduler for individual devices.
Aug 14 09:59:29 ourhouse kernel: usb_phy_generic phy: supply vcc not found, using dummy regulator
Aug 14 09:59:29 ourhouse kernel: mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
Aug 14 09:59:29 ourhouse kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Aug 14 09:59:29 ourhouse kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Aug 14 09:59:29 ourhouse kernel: mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
Aug 14 09:59:29 ourhouse kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Aug 14 09:59:29 ourhouse systemd-fstab-generator[94]: Checking was requested for "192.168.178.48:/volume1/homes/habu", but it is not a device.
Aug 14 09:59:29 ourhouse systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
Aug 14 09:59:29 ourhouse systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
Aug 14 09:59:29 ourhouse kernel: sd 0:0:0:0: [sda] No Caching mode page found
Aug 14 09:59:29 ourhouse kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
Aug 14 09:59:29 ourhouse blkmapd[141]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Aug 14 09:59:29 ourhouse kernel: sda: p2 size 30583808 extends beyond EOD, enabling native capacity
Aug 14 09:59:29 ourhouse kernel: sda: p2 size 30583808 extends beyond EOD, truncated
Aug 14 09:59:30 ourhouse systemd-udevd[159]: could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
Aug 14 09:59:30 ourhouse systemd-udevd[159]: could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
Aug 14 09:59:30 ourhouse systemd-udevd[167]: could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
Aug 14 09:59:30 ourhouse systemd-udevd[175]: could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
Aug 14 09:59:31 ourhouse systemd-udevd[175]: could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
Aug 14 09:59:33 ourhouse systemd[1]: firemotd.timer: Refusing to start, unit to trigger not loaded.
Aug 14 09:59:33 ourhouse systemd[1]: Failed to start FireMotD system updates check (randomly execute between 0:00:00 and 5:59:59).
-- Subject: A start job for unit firemotd.timer has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit firemotd.timer has finished with a failure.
--
-- The job identifier is 62 and the job result is failed.
Aug 14 09:59:33 ourhouse avahi-daemon[332]: open("/services/phpmyadmin.service", O_RDONLY): No such file or directory
Aug 14 09:59:33 ourhouse avahi-daemon[332]: Failed to load service group file /services/phpmyadmin.service, ignoring.
Aug 14 09:59:33 ourhouse systemd[1]: hciuart.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit hciuart.service has entered the 'failed' state with result 'exit-code'.
Aug 14 09:59:33 ourhouse systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
-- Subject: A start job for unit hciuart.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit hciuart.service has finished with a failure.
--
-- The job identifier is 132 and the job result is failed.
Aug 14 09:59:33 ourhouse avahi-daemon[332]: socket() failed: Address family not supported by protocol
Aug 14 09:59:33 ourhouse avahi-daemon[332]: socket() failed: Address family not supported by protocol
Aug 14 09:59:38 ourhouse dhcpcd[344]: ipv6_addaddr1: Operation not supported
Aug 14 09:59:38 ourhouse dhcpcd[344]: received SIGPIPE
Aug 14 09:59:38 ourhouse dhcpcd[344]: ipv6nd_startrs1: Address family not supported by protocol
Aug 14 09:59:38 ourhouse dhcpcd[344]: received SIGPIPE
Aug 14 10:00:04 ourhouse /etc/mysql/debian-start[1273]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Aug 14 10:00:04 ourhouse /etc/mysql/debian-start[1273]: Looking for 'mysql' as: /usr/bin/mysql
Aug 14 10:00:04 ourhouse /etc/mysql/debian-start[1273]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Aug 14 10:00:04 ourhouse /etc/mysql/debian-start[1273]: Version check failed. Got the following error when calling the 'mysql' command line client
Aug 14 10:00:04 ourhouse /etc/mysql/debian-start[1273]: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)
Aug 14 10:00:04 ourhouse /etc/mysql/debian-start[1273]: FATAL ERROR: Upgrade failed
Aug 14 10:05:14 ourhouse systemd[1]: packagekit.service: Main process exited, code=killed, status=15/TERM
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit packagekit.service has exited.
--
-- The process' exit code is 'killed' and its exit status is 15.
Aug 14 10:05:46 ourhouse rpcbind[3736]: cannot create socket for udp6
Aug 14 10:05:46 ourhouse rpcbind[3736]: cannot create socket for tcp6
Aug 14 10:05:46 ourhouse rpc.statd[3748]: Flags: TI-RPC
Aug 14 10:05:47 ourhouse rpc.statd[3748]: Failed to create listener xprt (statd, 1, udp6)
Aug 14 10:05:47 ourhouse rpc.statd[3748]: Failed to create listener xprt (statd, 1, tcp6)
Aug 14 10:05:47 ourhouse kernel: nfs: Deprecated parameter 'intr'

 $ modprobe -v nfsd
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
modprobe: FATAL: Module nfsd not found in directory /lib/modules/5.10.17-v7l+

$insmod /lib/modules/$(uname -r)/kernel/net/sunrpc/sunrpc.ko.zst
insmod: ERROR: could not load module /lib/modules/5.10.17-v7l+/kernel/net/sunrpc/sunrpc.ko.zst: No such file or directory

"No such file or directory" ! -> Diese Verzeichnisse existieren:

5.10.52+/     5.10.52-v7+/  5.10.52-v7l+/ 5.10.52-v8+/  5.4.79+/      5.4.79-v7+/   5.4.79-v7l+/  5.4.79-v8+/

Liegt da der Hund (zumindest zum Teil) begraben ?

 

[Sommersocke]

…

sudo rpi-update 0642816ed05d31fb37fc8fbbba9e1774b475113f

…
Liegt da der Hund (zumindest zum Teil) begraben ?

Ich glaube da liegt sogar das ganze Rudel.

Wenn du die Warnung beim rpi-update gelesen hast: früher stand da immer, dass man das nicht machen soll, außer es ist unbedingt und zwingend erforderlich (hab ich aber auch immer ignoriert )

Du kannst Kernelmodule nur laden, wenn sie passend zum Kernel kompiliert wurden. Wenn du also das nfsd-Modul für Kernel 1.2.3 hast und der Kernel jetzt 1.2.4 ist, dann wird das nicht geladen. Mir ist gerade der Mechanismus entfallen, der das prüft, könnte ich bei Interesse an der Modulprogrammierung aber nachlesen.

Für dich bedeutet das, du musst nun einen Kernel, inklusive Header und passender Module vollständig installieren und diesen beim Systemstart auch laden. Mehrere Kernel nebeneinander sind kein Problem, daher wird ja mittels uname -r das entsprechende Verzeichnis aufgerufen, das dem aktuell geladenen Kernel entspricht. Das fehlt aber bei dir, ergo hast du gar keine Module zur Verfügung.

Ich habe eben mal auf meinem Raspi nachgesehen, da liegt wirklich viel alter Schlonz rum Bei mir sind da 16 Kernel drin.

Laut Raspi-OS-Dokumentation kannst du mit

sudo apt-get update
sudo apt install --reinstall libraspberrypi0 libraspberrypi-{bin,dev,doc} raspberrypi-bootloader raspberrypi-kernel

den Vorgang vom rpi-update rückgängig machen.

 

[X__]

Ich glaube da liegt sogar das ganze Rudel.

Wenn du die Warnung beim rpi-update gelesen hast: früher stand da immer, dass man das nicht machen soll, außer es ist unbedingt und zwingend erforderlich (hab ich aber auch immer ignoriert )
...

Ok, ich habe leider grade andere Sachen an der Hacke (Hausrenovierung 🙄), werde mich aber sobald wie möglich darum kümmern.

Trotzdem aber nochmal der Hinweis (nicht, das da Missverständnisse aufkommen ):
Das Problem trat schon vor dem Aufruf von rpi-update auf.
Und die durch RPI angeforderte Version ist ja weder als Verzeichnis, noch als aktiver Kernel zu sehen.

Ursächlich vermute ich inzwischen, dass da dann vorher schon die regulären Update-Mechanismen Murks gebaut haben.
Aber egal, Hauptsache ich bekomme das ohne Neuinstallation hin - geht ja auch um den Lerneffekt

Ich meld mich...

Korrektur: 5.4.79 ist als Verzeichnis vorhanden. Also scheint der "rpi-update" doch in die richtige Richtung zu gehen, oder ?
Oder soll ich lieber doch den reinstall auführen ?
Da wäre ich mir jetzt aber nicht sicher, wo der mich hinführt, denn den durch rpi-update angeforderten 5.4.79 hat er ja anscheinend gar nicht geladen 🧐

 

[X__]

So, ich habe

sudo apt-get update
sudo apt install --reinstall libraspberrypi0 libraspberrypi-{bin,dev,doc} raspberrypi-bootloader raspberrypi-kernel

ausgeführt. Er hat zwar ganz viel gemacht und irgendwo hatte ich auch eine Zeile gesehen,
aus der für mich hervorging, dass er den Kernel mit der derzeitigen Version mit den Kernel der gleichen Version überbügelt..

In jedem Fall ist die Situation jetzt die gleiche:

$ modprobe -v nfsd
modprobe: ERROR: ../libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file '/lib/modules/5.10.17-v7l+/modules.dep.bin'
modprobe: FATAL: Module nfsd not found in directory /lib/modules/5.10.17-v7l+

$ insmod /lib/modules/$(uname -r)/kernel/net/sunrpc/sunrpc.ko.zst
insmod: ERROR: could not load module /lib/modules/5.10.17-v7l+/kernel/net/sunrpc/sunrpc.ko.zst: No such file or directory

$ insmod /lib/modules/5.
5.10.52+/     5.10.52-v7+/  5.10.52-v7l+/ 5.10.52-v8+/  5.4.79+/      5.4.79-v7+/   5.4.79-v7l+/  5.4.79-v8+/

 

[Sommersocke]

Existiert das Verzeichnis /lib/modules/5.10.17-v7l+[i/] denn?

ls -lha /lib/modules/$(uname -r)/{,kernel,kernel/fs}  # Verzeichnis(se) anzeigen
dpkg -l | grep -E 'rasp|nfs'  # Ausgabe Pakete kernel+nfs
dpkg -l | grep -Ev '^ii'  # Alle mit nicht installiert-Status (Reste & Co)

 

[X__]

Existiert das Verzeichnis /lib/modules/5.10.17-v7l+[i/] denn?

Nein, es existieren nur folgende Verzeichnisse

$ ...
5.10.52+/     5.10.52-v7+/  5.10.52-v7l+/ 5.10.52-v8+/  5.4.79+/      5.4.79-v7+/   5.4.79-v7l+/  5.4.79-v8+/

$ dpkg -l | grep -E 'rasp|nfs'
ii  libnfsidmap2:armhf                 0.25-5.1                              armhf        NFS idmapping library
ii  libraspberrypi-bin                 1:1.20210805-1                        armhf        Miscellaneous Raspberry Pi utilities
ii  libraspberrypi-dev                 1:1.20210805-1                        armhf        EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers)
ii  libraspberrypi-doc                 1:1.20210805-1                        armhf        EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers)
ii  libraspberrypi0                    1:1.20210805-1                        armhf        EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV
ii  nfs-common                         1:1.3.4-2.5+deb10u1                   armhf        NFS support files common to client and server
ii  nfs-kernel-server                  1:1.3.4-2.5+deb10u1                   armhf        support for NFS kernel server
ii  raspberrypi-bootloader             1:1.20210805-1                        armhf        Raspberry Pi bootloader
ii  raspberrypi-kernel                 1:1.20210805-1                        armhf        Raspberry Pi bootloader
ii  raspberrypi-net-mods               1.3.0                                 all          Network configuration for the Raspberry Pi UI
ii  raspberrypi-sys-mods               20210706                              armhf        System tweaks for the Raspberry Pi
ii  raspbian-archive-keyring           20120528.2                            all          GnuPG archive keys of the raspbian archive
ii  raspi-copies-and-fills             0.13                                  armhf        ARM-accelerated versions of selected functions from string.h
ii  raspi-gpio                         0.20191001                            armhf        Dump the state of the BCM270x GPIOs
ii  raspinfo                           20190624-1                            all          Dump information about the Pi

$ dpkg -l | grep -Ev '^ii'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                               Version                               Architecture Description
+++-==================================-=====================================-============-===============================================================================
rc  triggerhappy                       0.5.0-1                               armhf        global hotkey daemon for Linux

 

[Sommersocke]

Das sieht alles soweit einwandfrei aus, du scheinst aber auch noch den testing-Kernel zu haben (raspberrypi-kernel/testing,now 1:1.20210805-1 armhf)

Wo der 5.10.17 herkommt, kann ich dir aber auch nicht sagen. Da die Kernel nicht so einfach einzeln anwählbar sind, würde ich zunächst versuchen nochmal rpi-update laufen zu lassen — dann bist du wenigstens auf 5.10.52-v7+, der zumindest komplett installiert scheint. Ich habe den auch gerade draufgezogen, NFS funktioniert da; ist allerdings ein alter 3er Rev1

 

[X__]

Vielleicht habe ich was Missverstanden aber kapieren tu' ich es grade nicht:

rpi-update scheint 5.10.52 zu installieren:

$ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
#############################################################
WARNING: This update bumps to rpi-5.10.y linux tree
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=288234
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   168  100   168    0     0   2545      0 --:--:-- --:--:-- --:--:--  2545
100  121M  100  121M    0     0  7400k      0  0:00:16  0:00:16 --:--:-- 10.0M
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 5.10.52-v8+
 *** depmod 5.10.52-v7+
 *** depmod 5.10.52+
 *** depmod 5.10.52-v7l+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to ad5406d7597e017298474a96323ced593da01457
 *** A reboot is needed to activate the new firmware

Trotzdem bleibt nach einen Reboot der aktive Kernel 5.10.17 :

$ uname -r
5.10.17-v7l+

Muss ich zusätzlich noch was machen ?

Ergänzung (15. August 2021)

Jippieh, es geht wieder

Ich habe jetzt noch mal mit

 sudo rpi-update b63a7cb64dfe45ad1d0b3921529f7cbe6203ecdb

explizit den letzten Stand aus dem Stable-Zweig installiert und siehe da : Alles läuft wieder.
Der 5.10.52 ist der aktiver Kernel und NFS funktioniert auch wieder.

Wo der 5.10.17 hergekommen ist versteh ich aber auch nicht.

@Sommersocke Vielen Dank