FS#74272 - [linux] NFS 4.2 mount regression with 5.17.1 kernel
Attached to Project:
Arch Linux
Opened by Brian BIdulock (bidulock) - Wednesday, 30 March 2022, 02:58 GMT
Last edited by David Thurstenson (thurstylark) - Monday, 25 April 2022, 20:11 GMT
Opened by Brian BIdulock (bidulock) - Wednesday, 30 March 2022, 02:58 GMT
Last edited by David Thurstenson (thurstylark) - Monday, 25 April 2022, 20:11 GMT
|
Details
Description:
NFS 4.2 mount hang same as Mounting an NFS version 4.2 mount simply hangs. Still ok with last 5.16 kernel and current 5.15 LTS kernel. Additional info: * package version(s) * config and/or log files etc. * link to upstream bug report, if any Steps to reproduce: Attempt to mount a NFS version 4.2 mount with 5.17.1-arch1-1 kernel. |
This task depends upon
Closed by David Thurstenson (thurstylark)
Monday, 25 April 2022, 20:11 GMT
Reason for closing: Fixed
Additional comments about closing: linux 5.17.4-arch1-1
Monday, 25 April 2022, 20:11 GMT
Reason for closing: Fixed
Additional comments about closing: linux 5.17.4-arch1-1
Comment by
Jan Alexander Steffens (heftig) -
Wednesday, 30 March 2022, 08:45 GMT
Comment by
Jan Alexander Steffens (heftig) -
Wednesday, 30 March 2022, 08:51 GMT
Comment by
Brian BIdulock (bidulock) -
Wednesday, 30 March 2022, 12:15 GMT
Comment by
Brian BIdulock (bidulock) - Monday,
11 April 2022, 08:55 GMT
Comment by Andreas (Vardamir) -
Monday, 11 April 2022, 10:48 GMT
You mean 4.1? The previous bug was about broken QNAP servers which
"supported" 4.1, not 4.2.
If we need to patch this again,
https://lore.kernel.org/linux-nfs/20220316222426.82485-1-olga.kornievskaia%40gmail.com/
is probably a better option than reverting trunk discovery.
Yes, 4.2, and also on QNAP.
The trunk discovery mount option patch would work for me.
As a workaround for QNAP, mounting with option vers=3 works