Kernel update breaks nemo with autofs or systemd.automount

Ask Fedora
1

The last 3 kernel upgrades in Fedora 35 have caused my cinnamon desktop to display a black screen with only a mouse (which does move). The hard drive light continues to flicker as per a normal boot, and using the keyboard can get activity as well. Just no display.

I would really like some help diagnosing this and fixing it. Or is this a bug? I have not turned anyting up with search engines yet.

I was using autofs to mount NAS NFS4 shares and have shortcuts set in Nemo for easy access.

Under kernel-0:5.16.9-200.fc35, this was working great and has for a few years now.

When the kernel updated to 5.16.11 (I think that was the first), I got the above symptom of a black screen.

I had to power cycle the machine (couldn’t remember the keystrokes for reboot, silly me) and boot into the previous kernel (5.16.9) and all was good.

So I went looking for solutions and saw there were plenty of folk switching from autofs to systemd.automount. So I removed autofs and implemented automount via fstab. Booting into the known working kernel until I got the config right, and all was good. But alas the newer kernel boot had the same problem.

So another 2 kernels later (last one is 5.16.13-200) and the problem persists.

I have currently set the 5.16.9 kernel as the default and versionlocked it so it doesn’t get recycled. Shame the next kernel update resets the default kernel though. I know there is probably a way to stop that behaviour, but haven’t gotten around to finding the answer … I just re-set the default back to the one that works after each dnf up.

TIA

2

Please note: The login screen appears just fine. The black screen is after logging in.

It looks like there might be a timeout issue going on here. If I walk away and leave it for a while (say 5 minutes), when I get back the desktop is on the screen. However, anything that tries to access the automount shares stalls.

When I logged in with the current gnome desktop, I get the desktop (slowly), but it stalls when trying to access the automount shares too.

3

It definitely has an issue with the new kernels and systemd.automount. I removed the automount from the fstab file and rebooted into the new kernel 5.16.9-200.fc35 and the Cinnamon desktop loaded normally on login.

Here is an example fstab entry:

nas03:/WesHome /home/graham/NET/FS/wesHOME nfs4 x-systemd.automount,x-systemd.idle-timeout=15min,rw,sync 0 0

So has something changed in systemd.automount? Or has there been changes to nfs4 mounting under newer kernels?

4

Hi, if you search nfs4 in this forum, you’ll find there a similar problem and how to workaround. Look like there a problem with the kernel driver.

5

Thank you @oprizal that did the trick for now.

The answer for me was to add vers=4.0 to the entries in fstab.

And it looks like this issue is mainly found when connecting to QNAP NASs, but also Synology as well.

See: 2055362 – NFS mount hang on kernel 5.16.10
and: 20220227.2.1 breaks NFS mount for QNAP servers (kernel 5.16.x) · Issue #1121 · coreos/fedora-coreos-tracker · GitHub

1 Like
6

The fix for this issue went into Fedora 5.18 kernels and backported to 5.17.

I have recently tested it on kernel 5.16.19-200.fc35 by removing the vers=4.0 from fstab, and the connection is happening perfectly.

BTW, I limited NFS on the QNAP NAS to “V4 only” to ensure the connection was using the correct version.

QNAP NAS running QTS v5.0.0.1932.

1 Like