Path: csiph.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Thomas Korimort Newsgroups: linux.debian.bugs.dist,linux.debian.kernel Subject: Bug#992866: Problem with mounting nfs shares after sudden poweroutage, fstab mount procedure jumbles nfs mounts Date: Tue, 24 Aug 2021 15:30:02 +0200 Message-ID: X-Original-To: submit@bugs.debian.org X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Tue Aug 24 13:27:09 2021 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: -3.501 Reply-To: Thomas Korimort , 992866@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Debian Kernel Team X-Debian-Pr-Message: report 992866 X-Debian-Pr-Package: linux-image-5.10.0-8-amd64 X-Debian-Pr-Source: linux-signed-amd64 X-Ui-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Provags-ID: V03:K1:mDvi7r3/QYLgw0VLzaBP+Ub0XmshNABD2dEb/0/u0fz3DaJibz5 4TKE0o7V/R+X2abhej2FC1+BkxhnUN2z0yeMo4vAVRcMTtGYOR4pLI7jbF0Nupkde9k4UUM I/Oj8o+EJGYkU4c5m4i9hFQhJjSYtrKcYThcU2urmkjETI6fzl7caVyUYeg9TOwLTlPAYlP YSt2i0xBGJUqUhEbf5grg== X-Ui-Out-Filterresults: notjunk:1;V03:K0:f9Q63QoNL5Q=:JUVbHYaUGNZNeMloLmYUI6 lVTUlqnTxw5W0tthf//gR5HetjE05oRLU7I1OLuAst46LmbgguzXByDgjbdheqeL8bIvThwrC 6L95wNYb9IdsV3BAeCk3ANFxG5KYkGPi5dkJKJez3YKDAZ1sLVfefvoPUtiHNNxJdfZuWywB1 H/2cr5z4qpDhRU7cCf9Qu2ms8KLNTa24rFs7VJc0m/QsVNRa5j+dmyG92jlplNBkCQhVgZS6E ZKzGEIOL5IvyYOcGfJyf7BP15rm2zyAofsydfSc6uslKB16I1pDpIbvxrODVolFPHJYigYpcT YbNbtMWpBt5Nn8RoSFZSrRP/lFEfGaLlLRdrGS1IX27a0KrDuOsJt3Ak2rZSWjW0Edhyye+wy wJ3Tu7h1tkCF3191LPjKQo+Izc7A2Ao1XMGgxicKkbY5T8sWbqUMwolOtZwIE9eL7YZ0oraAp Di2+FEdZx925oXa9wv4n6SHD36e7q7g3kNvwTHonFtKxkjQy/WnX2GXE8upKx+YiVDexliB9Z HqrbVttN7fVEMJbDPj4upYT26IXKMDD8Y4ZmaSS2GelF0DeA84WhythluJg7zbzVklwjDNTMj uf306mMPux9vD+KPsv2rQ3hmWdicu75dWVos6whV9V+dD+LulT3oqj2foVNrjoja3xi2EgNJY yDh4bGsqTMeA+FwtKnKSoyDD1S/1y4FVAjIDQ3MXh8x7AfYP0IXCEEm5ye0O6/ugxXd/yFT9Y SUvaa9+NUAOHXJSykQvMllBmJ9XIFMfL2y9B1w3CgIqvfU57VxSTrSycinPebmQvfL+kqtCr2 lgBXfQsiFv8yrhKpyQD2jLSIPeF7E1OS8A20GgoLy8wb9CDEDpWpyLPwbdt/Ul6TuBGxK0MEm X/GivCyaNnH0aei2PP6ff9EMUWiYNZiE7eeC03ESqGn89WzHwp1SOb/djphXOWvRWq1zv2U07 +vnA93u2hO9rjXDYd3W8PSNztz99VEj1i4gI+Nu4cNS7ynZkOwPkTyIBjvEU5+tCcA1obh8rF 04icfasodEjc3bHGi3fCNioAxM4xa7YcsgO3p/3+mtlFLPrsv7qh9gQd10Y9O/GJN9VZQSptp UKFQLYrwbnU+cc6Tb4meFJRDh9OtQ3yUUE3l0GPQWpxHq+7fRMvy1mEyQ== X-Debian-Message: from BTS X-Mailing-List: archive/latest/1674863 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 88 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Tue, 24 Aug 2021 15:03:23 +0200 X-Original-Message-ID: Xref: csiph.com linux.debian.bugs.dist:1068157 linux.debian.kernel:72730 Package: linux-image-5.10.0-8-amd64 Version: 5.10 I am already experiencing this for the second time and i feel that this is a strange issue: I have an AMD Ryzen desktop PC with Debian Bullseye (before Buster) and a JBOD disk tower with four fully occupied slots. On my desktop i mount the 4 disks with ext4 file system as NFS shares via /etc/fstab, which used to work nicely before the most recent sudden power outage. After that the drives had to be checked and the inodes repaired. The file system of one disk in use was destroyed and restored through backup by copying the backup on the repaired disk. I also changed the file permissions and ownership after the copy procedure after a reboot. After that the mount procedure during system startup happening in /etc/fstab did not mount anymore my nfs shares correctly. The kernel mount procedure is waiting for 2 drives to mount and then jumbles the nfs mounts somehow. My /etc/fstab has this four entries related to the nfs shares: 10.10.10.2:/mnt/WD01 =C2=A0=C2=A0=C2=A0 /mnt/WD01=C2=A0=C2=A0=C2=A0 nfs=C2= =A0=C2=A0=C2=A0 rw,auto,nofail=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 0 10.10.10.2:/mnt/WD02=C2=A0=C2=A0=C2=A0 /mnt/WD02=C2=A0=C2=A0=C2=A0 nfs=C2= =A0=C2=A0=C2=A0 rw,auto,nofail=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 0 10.10.10.2:/mnt/WD03=C2=A0=C2=A0=C2=A0 /mnt/WD03=C2=A0=C2=A0=C2=A0 nfs=C2= =A0=C2=A0=C2=A0 rw,auto,nofail=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 0 10.10.10.2:/mnt/WD04=C2=A0=C2=A0=C2=A0 /mnt/WD04=C2=A0=C2=A0=C2=A0 nfs=C2= =A0=C2=A0=C2=A0 rw,auto,nofail=C2=A0=C2=A0=C2=A0 0=C2=A0=C2=A0=C2=A0 0 and the actual mount in /proc/mounts lists like this 10.10.10.2:/mnt/WD04 /mnt/WD04 nfs4 rw,relatime,vers=3D4.2,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,pro= to=3Dtcp,timeo=3D600,retrans=3D2,sec=3Dsys,clientaddr=3D10.10.10.1,local_l= ock=3Dnone,addr=3D10.10.10.2 0 0 10.10.10.2:/mnt/WD03 /mnt/WD03 nfs4 rw,relatime,vers=3D4.2,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,pro= to=3Dtcp,timeo=3D600,retrans=3D2,sec=3Dsys,clientaddr=3D10.10.10.1,local_l= ock=3Dnone,addr=3D10.10.10.2 0 0 10.10.10.2:/mnt/WD02 /mnt/WD02 nfs4 rw,relatime,vers=3D4.2,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,pro= to=3Dtcp,timeo=3D600,retrans=3D2,sec=3Dsys,clientaddr=3D10.10.10.1,local_l= ock=3Dnone,addr=3D10.10.10.2 0 0 10.10.10.2:/mnt/WD03 /mnt/WD01 nfs4 rw,relatime,vers=3D4.2,rsize=3D524288,wsize=3D524288,namlen=3D255,hard,pro= to=3Dtcp,timeo=3D600,retrans=3D2,sec=3Dsys,clientaddr=3D10.10.10.1,local_l= ock=3Dnone,addr=3D10.10.10.2 0 0 One can see that /mnt/WD03 gets mounted under /mnt/WD01 and there is no mount entry for /mnt/WD01. The content of the two mounts seems to be that of /mnt/WD01 (WD01 is a hand-maintained mirror of /mnt/WD02). What is wrong here? Reboot does not change anything. This strange constellation is carried over from reboot to reboot and i don't know where i can find the run state or similar file that is jumbled up and that is transferring the wrong mount information from reboot to reboot. I looked in /var/run, /tmp aso. for files related to the kernel mount procedure and fstab. The mount procedure is waiting for 1,5 minutes for mounting WD01 and WD03 and then jumbles the mounts. The drives itself are okay on my Raspberry Pi 4 (Vanilla Debian Bullseye arm64 via image-specs script some days ago) nfs server 10.10.10.2 and exportfs also lists ok (10.10.10.1 exports are rw, others ro, other export options are sync and no_root_squash for all exports): /mnt/WD01=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10.10.10.1 /mnt/WD02=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10.10.10.1 /mnt/WD03=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10.10.10.1 /mnt/WD04=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10.10.10.1 /mnt/WD01=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 192.168.0.0/24 /mnt/WD01=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 192.168.1.0/24 /mnt/WD01=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 10.10.10.0/24 WD01 is exported into multiple IP adress spaces for my different router and network switch configurations. It was working nicely till yesterday before the sudden power outage and disk recovery. Exactly this problem happened to me with my old Debian Buster desktop installation and led to the same problem, when i had to replace a harddisk and after a power outage. It seems to be a recurring problem over the last decade of years as well as the famous pulseaudio sequencer problem. Greetings, Thomas Korimort.