After update from 8.4 to 9.0 NFS doesn't work

Ok, little bit of progress. I changed in /etc/apt/sources.list.d/debian.sources the URIs, where I replaced ftp.nl.debian.org to deb.debian.org.
I also re-installed the intel microcode:

apt-get reinstall intel-microcode

And that would make the vms start and run again (halleluja!). Now the last problem to fix is to get the nfs mount working again.
No idea yet which packages I need to re-install,

Albert
P.S. Got my imap server running as a vm, contains mail back to 1999, so for me it's important that it is running.
 
  • Like
Reactions: bilou
Maybe you have a similar problem than I had: My NFS did also not work after upgrading. My logfiles looked similar.

I Installed Proxmox on a new SSD and wanted to move the data or reinstall the data from the NFS.
The NFS did not work, because the kernel didn't want to load the NFS modules.
Then I found out, that an old kernel was booted.

Have a look at
Bash: 
uname -a
and
Bash: 
ls /lib/modules

The kernel from the old SSD and installation was booted and the new filesystem was used as root filesystem, So I had Proxmox 9.0 with the Kernel of 8.4.
I had to go to the BIOS and change the boot order, to use the new SSD.
Bash: 
systemctl reboot --firmware-setup

After that NFS was working again.
 
  • Like
Reactions: ravado
Thanks for all the tips and support. Currently I am reinstalling proxmox 9 and restoring from my backup (Proxmox Backup Server, don't wan't to upgrade that one!).

Anyway, the two problems I had, no nfs connection and not able to start a vm where fixed by reinstalling the following:

vm issues:
apt reinstall intel-microcode

nfs issues:
apt reinstall nfs-common libnfsidmap1

Both needed a reboot of course.

Since I buggered up my cluster (let's call this the panic mode) and since I don't trust the current Proxmox 9 upgrade installation (what else should be reinstalled), I started by first testing if the machines still work (with it's disk on nfs). Then I did a fresh install on one of the nodes, not putting it in a cluster yet, and reinstalling all vms from the backup. That all seems to work, so I will freshly install the second node as well.
As I used the Proxmox Backup Server as a qnode for the cluster, I have to look into that as well before I re-establish a new cluster.

Makes me wonder why the upgrade gave all these problems. Was the fact that I had ftp.nl.debian.org as the URI in de apt sources files the problem (I assume that would not make a difference). Did I run apt upgrade instead of apt dist-upgrade? As far as I remember I used dist-upgrade, don't know 100% sure by now. And would that be able to create such weird upgrades?

Luckily I had my backups (I use the PBS, but a separate USB drive would have worked too).

But for the moment I refrain from upgrading the PBS to version 4, as you can imagine.

Thanks to all the people for all the help and suggestions, specially to titou10 as he pointed me into the direction of the intel-microcode bit, and fiona for the nfs hints.

Regards,
Albert
 
Last edited:
  • Like
Reactions: uzumo
I tried everything here still problem.

NFS network is fine tested no issues, after boot NFS is mounted I can browse directory, no NFS restrictions private network, worked fine with 8 when I try to start an LXC it just hangs. Says not responding but network is accessible. The proxvm mount goes inactive after I try to start a VM/LXC

Feb 04 13:35:52 nypve17 kernel: nfs_file_fsync+0x9b/0x1b0 [nfs]
Feb 04 13:36:16 nypve17 kernel: nfs: server alphabeta-1-data not responding, still trying
Feb 04 13:36:16 nypve17 kernel: nfs: server alphabeta-1-data not responding, still trying
Feb 04 13:37:55 nypve17 kernel: nfs_file_fsync+0x9b/0x1b0 [nfs]
Feb 04 13:39:57 nypve17 kernel: nfs_file_fsync+0x9b/0x1b0 [nfs]
Feb 04 13:42:00 nypve17 kernel: nfs_file_fsync+0x9b/0x1b0 [nfs]
Feb 04 14:25:20 nypve17 nfsidmap[10082]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'englab.juniper.net'
Feb 04 14:25:20 nypve17 nfsidmap[10083]: nss_name_to_gid: name 'root@defaultv4iddomain.com' does not map into domain 'englab.juniper.net'
Feb 04 14:27:05 nypve17 systemd[1]: Stopping nfs-blkmap.service - pNFS block layout mapping daemon...
Feb 04 14:27:05 nypve17 systemd[1]: Stopped target nfs-client.target - NFS client services.
Feb 04 14:27:05 nypve17 systemd[1]: Stopping nfs-client.target - NFS client services...
Feb 04 14:27:05 nypve17 systemd[1]: Reached target nfs-client.target - NFS client services.
Feb 04 14:27:05 nypve17 systemd[1]: nfs-blkmap.service: Deactivated successfully.
Feb 04 14:27:05 nypve17 systemd[1]: Stopped nfs-blkmap.service - pNFS block layout mapping daemon.
Feb 04 14:27:05 nypve17 systemd[1]: Starting nfs-blkmap.service - pNFS block layout mapping daemon...
Feb 04 14:27:05 nypve17 blkmapd[10715]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Feb 04 14:27:05 nypve17 systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon.
Feb 04 14:29:07 nypve17 systemd[1]: Stopping nfs-blkmap.service - pNFS block layout mapping daemon...
Feb 04 14:29:07 nypve17 systemd[1]: nfs-blkmap.service: Deactivated successfully.
Feb 04 14:29:07 nypve17 systemd[1]: Stopped nfs-blkmap.service - pNFS block layout mapping daemon.
Feb 04 14:30:52 nypve17 umount[11294]: umount.nfs: /mnt/pve/proxvm: device is busy
Feb 04 14:30:52 nypve17 systemd[1]: Stopped target nfs-client.target - NFS client services.
Feb 04 14:36:35 nypve17 systemd[1]: Starting nfs-blkmap.service - pNFS block layout mapping daemon...
Feb 04 14:36:35 nypve17 systemd[1]: Reached target nfs-client.target - NFS client services.
Feb 04 14:36:35 nypve17 blkmapd[2008]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory
Feb 04 14:36:35 nypve17 systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon.
Feb 04 14:36:50 nypve17 nfsidmap[2566]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'englab.juniper.net'
Feb 04 14:36:50 nypve17 nfsidmap[2567]: nss_name_to_gid: name 'root@defaultv4iddomain.com' does not map into domain 'englab.juniper.net'
Feb 04 14:36:50 nypve17 nfsrahead[2568]: setting /mnt/pve/proxbackup readahead to 128
Feb 04 14:36:50 nypve17 nfsrahead[2627]: setting /mnt/pve/proxvm readahead to 128
Feb 04 14:36:50 nypve17 nfsrahead[2638]: setting /mnt/pve/proxtemplate readahead to 128

root@nypve17:/mnt/pve# pvesm status
Name Type Status Total (KiB) Used (KiB) Available (KiB) %
local dir disabled 0 0 0 N/A
proxbackup nfs active 16106127360 14164473472 1941653888 87.94%
proxtemplate nfs active 1073741824 319445056 754296768 29.75%
proxvm nfs active 32212254720 20653502272 11558752448 64.12%
root@nypve17:/mnt/pve#

root@nypve17:/mnt/pve# nfsstat -m
/mnt/pve/proxbackup from alphabeta-2-data:/proxbackup
Flags: rw,relatime,vers=4.2,rsize=65536,wsize=65536,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.82.128.73,local_lock=none,addr=10.82.128.111

/mnt/pve/proxvm from alphabeta-1-data:/proxvm
Flags: rw,relatime,vers=3,rsize=65536,wsize=65536,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.82.128.110,mountvers=3,mountport=635,mountproto=udp,local_lock=none,addr=10.82.128.110

/mnt/pve/proxtemplate from alphabeta-1-data:/proxtemplates
Flags: rw,relatime,vers=4.2,rsize=65536,wsize=65536,namlen=255,hard,fatal_neterrors=none,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.82.128.73,local_lock=none,addr=10.82.128.110
 
You must log in or register to reply here.
Top Bottom
Back