Systemd-logind and firewalld issues

General system Kernel, boot, graphics & hardware
1

Very bad weekend, after system upgrades, I had 4 client systems out of service this morning.
Seems related to the systemd upgrades where during boot systemd-logind and firewalld balk all of a sudden, starting with the console indications here:

20250922_091915
20250922_0919151000×750 171 KB

after digging out an EndeavourOS live usb, I finally tried commenting out the NFS4 mounts in /etc/fstab… that got things booted, then finally it came down to the /home mount (yes, we use NFS home since a real long time).

I’ve spent the day trying to find others having the issue, nada.

The line causing the problem in /etc/fstab is commented out in the following

#smicro:/home   /home  nfs4  _netdev,acl,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14 0 0
smicro:/dossiers   /export/dossiers  nfs4  _netdev,acl,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14 0 0
smicro:/pub   /export/pub  nfs4  _netdev,acl,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14 0 0
smicro:/var/pacman-x86_64-ENDEAVOUROS /var/cache/pacman  nfs4  _netdev,x-systemd.automount,x-systemd.idle-timeout=10min 0 0

the rest seem to work fine, still.

Anybody else having this?

Is it reasonable to strobe systemd-logind to wait for remote-fs.target?

Why firewalld?

$ inxi -b
System:
  Host: pn51-2 Kernel: 6.12.47-1-lts arch: x86_64 bits: 64
  Console: pty pts/1 Distro: EndeavourOS
Machine:
  Type: Mini-pc System: ASUSTeK product: MINIPC PN51-E1 v: 0505 serial: <superuser required>
  Mobo: ASUSTeK model: PN51-E1 serial: <superuser required> UEFI: ASUSTeK v: 0505
    date: 09/02/2022
2

I would test and see if systemd 258-3, currently in testing, fixes it. There seems to have been quite few issues with the new systemd.

3

no, unfortunately, no change.
tried to see if I could work around it in two steps by mounting the nfs home share to /export/home followed by a bind mount to /home.. the first works, but when I try the bind mount, exactly the same result.

It seems quite unusual that such a regression is still outstanding…

4 
[2025-09-26T08:13:20+0200] [ALPM] upgraded systemd-libs (258-3 -> 258-4)
[2025-09-26T08:13:23+0200] [ALPM] upgraded systemd (258-3 -> 258-4)
[2025-09-26T08:13:25+0200] [ALPM] upgraded systemd-resolvconf (258-3 -> 258-4)
[2025-09-26T08:13:25+0200] [ALPM] upgraded systemd-sysvcompat (258-3 -> 258-4)

well, perhaps a deeper look is needed as this morning’s upgrade is a bit worse…

Here’s a simple extraction of the /home probleme…

$ journalctl -b -1 |grep home
sept. 26 08:19:29 envyx systemd-fstab-generator[502]: '/export/home' is not a device path, ignoring x-systemd.device-timeout= option.
sept. 26 08:19:29 envyx systemd[1]: Set up automount export-home.automount.
sept. 26 08:19:29 envyx systemd[1]: home.automount: Directory /home to mount over is not empty, mounting anyway.
sept. 26 08:19:29 envyx systemd[1]: Set up automount home.automount.
sept. 26 08:19:30 envyx systemd-tmpfiles[670]: Detected autofs mount point /home during canonicalization of home.
sept. 26 08:19:30 envyx systemd-tmpfiles[670]: Skipping /home
sept. 26 08:19:30 envyx systemd-tmpfiles[670]: Detected autofs mount point /home during canonicalization of home.
sept. 26 08:19:30 envyx systemd-tmpfiles[670]: Skipping /home
sept. 26 08:19:34 envyx systemd[1]: home.automount: Got automount request for /home, triggered by 719 ((uetoothd))
sept. 26 08:20:28 envyx systemd[1]: sysinit.target: Found ordering cycle: dbus.socket/stop after dbus-broker.service/stop after basic.target/stop after NetworkManager-wait-online.service/stop after network-online.target/stop after export-home.mount/stop after home.mount/stop after local-fs.target/stop after systemd-boot-random-seed.service/stop after sysinit.target/stop - after dbus.socket
sept. 26 08:20:28 envyx systemd[1]: basic.target: Found ordering cycle: NetworkManager-wait-online.service/stop after network-online.target/stop after export-home.mount/stop after home.mount/stop after local-fs.target/stop after systemd-tmpfiles-setup.service/stop after dbus-broker.service/stop after basic.target/stop - after NetworkManager-wait-online.service
sept. 26 08:20:28 envyx (d-logind)[724]: systemd-logind.service: Failed to set up mount namespacing: /home: No such device
sept. 26 08:20:28 envyx (or-proxy)[723]: iio-sensor-proxy.service: Failed to set up mount namespacing: /home: No such device
sept. 26 08:20:28 envyx (irewalld)[722]: firewalld.service: Failed to set up mount namespacing: /home: No such device
sept. 26 08:20:28 envyx (uetoothd)[719]: bluetooth.service: Failed to set up mount namespacing: /home: No such device
sept. 26 08:20:28 envyx systemd[1]: home.automount: Deactivated successfully.
sept. 26 08:20:28 envyx systemd[1]: Unset automount home.automount.
sept. 26 08:20:28 envyx systemd[1]: export-home.automount: Deactivated successfully.
sept. 26 08:20:28 envyx systemd[1]: Unset automount export-home.automount.

I’ll try with the device-timeout option removed….

5

People are getting frantic here… I find no mention either of deprecating NFS4 /home directories nor of others encountering the issue… am I the only one using it in fstab with the systemd automounter?

I can do an rbind mound with zfs based home directories no problem on the server machine, so it doesn’t seem to be related directly to the ‘bind’ mount but to the nfs mount.

Please advise where to file the issue… every time I try on arch they say I’m not on arch but endeavouros.

6

I mount NFS volumes in fstab using a systemd-automount and am not seeing any issues.

7

what do I do differently/wrong, only the /home mount balks…

smicro:/home   /home  nfs4  _netdev,acl,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14 0 0

on the server in /etc/exports

/export/home    192.168.0.0/23(rw,insecure,no_subtree_check,hide,sync)

not to mention that it always worked until a week ago

8

So your other mounts work OK? It is only the one for /home that fails?

9

exactly, I can also mount smicro:/home to /export/home with no problem.. then the problem is with the bind(or rather, rbind) mount.

10

If downgrading systemd fixes the issue, I would report it to systemd.

11

I presume all four packages

[2025-09-21T10:01:20+0200] [ALPM] upgraded systemd-libs (257.9-1 -> 258-2)
[2025-09-21T10:01:25+0200] [ALPM] upgraded systemd (257.9-1 -> 258-2)
[2025-09-21T10:01:44+0200] [ALPM] upgraded systemd-resolvconf (257.9-1 -> 258-2)
[2025-09-21T10:01:44+0200] [ALPM] upgraded systemd-sysvcompat (257.9-1 -> 258-2)

257.9-1 is no longer in my cache, is there a convenient place to find them (for x86_64)?

12

The ALA: https://archive.archlinux.org/

13
1 Like