The failed services with this are:

home.automount                                                                           loaded failed failed    home.automount                                                               
● home.mount                                                                               loaded failed failed    /home                                                                                                                                
● systemd-hostnamed.service                                                                loaded failed failed    Hostname Service            

But my machine seems happy again is I after boot:

systemctl restart home.automount
systemctl restart home.mount
systemctl restart systemd-hostnamed.service
systemctl restart chronyd.service
systemctl restart udisks2.service

but this is a nasty workaround.

It seems if you don't restart udisk2, mounting of drives from nautilus fails.

Any update on this?

I think I'm seeing the same thing with F33.

This person provided a solution,

https://webby.land/2020/09/29/no-nfs-on-boot/

Editing this file, as root, /lib/systemd/system/remote-fs-pre.target

and add the following under [Unit],

Wants=network-online.target
After=network-online.target

fixed the issue for me.  All of my fstab nfs4 entries had the following config,

nfs4	defaults,soft,_netdev,comment=systemd.automount 0 0

Fantastic. This seems to resolve the issue for me too!

And the associated failures of the systemd-hostnamed.service, chronyd.service and udisks2.service.

Now RH can you look at this fix!

Being a RH customer, I dutifully try things out in Fedora so they hopefully don't make it into RHEL...

Does seem a no brainer that a remote fs would want network online (or telepath :)

I wonder if this is a regression, I'm sure I've dealt with this before.

F34 seems to have the same bug. Please update Version to 34 since I can't do that.

Changed to F34, but the fix from before doesn't seem to be working for me :(

It does not work for me either.

Strangely, I'm not seeing this as a problem on F34, but it's a different machine.

And that is with the defaults in /lib/systemd/system/remote-fs-pre.target

that is, no Wants= or After=

'systemctl status mnt-tmp.mount' says:

Apr 29 16:41:44 localhost.localdomain systemd[1]: Mounting /mnt/tmp...
Apr 29 16:41:44 localhost.localdomain mount[875]: mount.nfs: Network is unreachable
Apr 29 16:41:44 localhost.localdomain systemd[1]: mnt-tmp.mount: Mount process exited, code=exited, status=32/n/a
Apr 29 16:41:44 localhost.localdomain systemd[1]: mnt-tmp.mount: Failed with result 'exit-code'.
Apr 29 16:41:44 localhost.localdomain systemd[1]: Failed to mount /mnt/tmp.

It seems that systemd is not waiting for network...

Ok: I see this behavior on only one system after upgrading from F33. No idea why it happens after upgrading. Before it worked without any problem. However I worked it out. Adding the following to /etc/fstab makes mounting on startup possible working again: 'noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev'

E.g: 192.168.1.1:/xxxx/xxx         /mnt/xxx        nfs     noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev   0 0


Found here: https://bbs.archlinux.org/viewtopic.php?id=254735

I now have in my fstab:

server.lan:/home				/home		nfs	noauto,x-systemd.automount,x-systemd.mount-timeout=30,_netdev	0 0

(it's so obvious when you say it  :) )


And tried with and without /lib/systemd/system/remote-fs-pre.target having: 

Wants=network-online.target
After=network-online.target

Neither works for me sadly.

Maybe try using the server's ip address instead of its host name?  maybe it's a race condition related to name resolution?  I just tested this on F34 and it works fine.

192.168.1.111:/data/household	/data/household	nfs	defaults,soft,_netdev,comment=x-systemd.automount 0 0
192.168.1.111:/data/audio	/data/audio	nfs	defaults,soft,_netdev,comment=x-systemd.automount 0 0
192.168.1.111:/data/photos	/data/photos	nfs	defaults,soft,_netdev,comment=x-systemd.automount 0 0
192.168.1.111:/data/osd		/data/osd	nfs	defaults,soft,_netdev,comment=x-systemd.automount 0 0

Did you need the change to the  /lib/systemd/system/remote-fs-pre.target unit file?

In my case I don't need it.

I didn't need to do it on my F34 setup, that was only on F33.  this was the output from 'journalctrl -b' on my fresh F34 install,

May 03 06:17:05 doont systemd[1]: Finished Network Manager Wait Online.
May 03 06:17:05 doont audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-wait-online comm="systemd" exe="/usr/li>
May 03 06:17:05 doont systemd[1]: Reached target Network is Online.
May 03 06:17:05 doont systemd[1]: Reached target Remote File Systems (Pre).
May 03 06:17:05 doont systemd[1]: Mounting /data/audio...
May 03 06:17:05 doont systemd[1]: Mounting /data/household...
May 03 06:17:05 doont systemd[1]: Mounting /data/osd...
May 03 06:17:05 doont systemd[1]: Mounting /data/photos...
May 03 06:17:05 doont systemd[1]: Starting Notify NFS peers of a restart...
May 03 06:17:05 doont sm-notify[1306]: Version 2.5.3 starting
May 03 06:17:05 doont systemd[1]: Started Notify NFS peers of a restart.
May 03 06:17:05 doont audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rpc-statd-notify comm="systemd" exe="/usr/lib/systemd/>
May 03 06:17:05 doont kernel: FS-Cache: Loaded
May 03 06:17:05 doont kernel: FS-Cache: Netfs 'nfs' registered for caching
May 03 06:17:05 doont kernel: Key type dns_resolver registered
May 03 06:17:06 doont kernel: NFS: Registering the id_resolver key type
May 03 06:17:06 doont kernel: Key type id_resolver registered
May 03 06:17:06 doont kernel: Key type id_legacy registered
May 03 06:17:06 doont systemd[1]: Mounted /data/osd.
May 03 06:17:06 doont systemd[1]: Mounted /data/photos.
May 03 06:17:06 doont systemd[1]: Mounted /data/household.
May 03 06:17:06 doont systemd[1]: Mounted /data/audio.
May 03 06:17:06 doont systemd[1]: Reached target Remote File Systems.

Still fails for me if using the IP.

May 03 14:30:56 tstf34 mount[962]: mount.nfs: Network is unreachable
May 03 14:30:56 tstf34 systemd[1]: home.mount: Mount process exited, code=exited, status=32/n/a
May 03 14:30:56 tstf34 systemd[1]: home.mount: Failed with result 'exit-code'.
May 03 14:30:56 tstf34 systemd[1]: Failed to mount /home.

Though I am using IPv6.

Please change Version to 35, since I can't do that.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This is still broken in F37.
Still takes a long time to boot (with an NFS homedir partition mount in /etc/fstab) and chronyd fails to start. udisks2 despite claiming to load doesn't work. 

In case anyone else needs I'm working around with this nasty:

In /etc/systemd/system/fixbrokenhomedir.service:

[Unit]
Description=Fix broken mount of homedir on boot and restart services that this hurt
Requires=network-online.target

[Service]
Type=oneshot
ExecStart=/bin/systemctl restart home.automount
ExecStart=/bin/systemctl restart home.mount
ExecStart=/bin/systemctl restart chronyd.service
ExecStart=/bin/systemctl restart systemd-hostnamed.service
ExecStart=/bin/systemctl restart udisks2.service

And then a timer to launch this after boot:

In /etc/systemd/system/fixbrokenhomedir.timer:

[Unit]
Description=Fix broken mount of homedir on boot and restart services that this hurt

[Timer]
OnBootSec=200

[Install]
WantedBy=timers.target

Enabled with

systemctl enable fixbrokenhomedir.timer

Just to note (in case there is now a preferable option):
nfssrv.lan:/home				/home		nfs	noauto,x-systemd.automount,x-sy
stemd.mount-timeout=30,_netdev	0 0

This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug is still present in Fedora 39.

Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

As already mentioned, thebug is still present in Fedora 39. I don't really know how to reopen the report though.

The issue seems to be a kind-of dependency loop involving home.mount, the remote fs target, network-pre.target, systemd-homed and the account-daemon service and NetworkManager. Probably also the network-online target.
I'm not really sure how to obtain detailed information about the cycle, as the system does not boot at all when /home is specified as a nfs mount in fstab.

None of the workarounds mentioned here was working for me. However, in my case I'm also booting from a NFS root filesystem. This means that the initramfs already setup the network anyway and the network is fully up when systemd starts the boot process. Because of that, waiting for network-pre in the NetworkManager unit seemed pointless. With that removed, the system is at least able to boot.

Here's what I found with some debugging:

Polkit seems to start only after home has been mounted, although there is no systemd dependency. This is the dependency chain:
home.automount (not a systemd dependency) => polkit.service => firewalld.service => network-pre.target => NetworkManager.service => network.target => gssproxy.service => rpc-gssd.service => nfs-client.target => remote-fs-pre.target => remote-fs.target => home.mount


So as there's no real dependency in the systemd graph, systemd does not detect the cycle and can't break it. Various units in that cycle however do simply not start and time out. Systemd then increases the timeout and the boot never succeeds.
I guess the simplest workaround is to remove the network-pre.target dependency on firewalld. I'm not sure whats the real solution here though. Maybe polkit should not require /home or maybe it should somehow be possible to avoid triggering the auto mount early in the boot process.


As a workaround, using a normal mount for home instead of an automount also fixes this. Compared to the workaround I suggested previously it significantly speeds up the boot process (10s vs 45s in the critical chain) and it should also work if your netup is not already set up by the initramfs.