| View previous topic :: View next topic |
| Author |
Message |
vespaman
Guru
Joined: 28 Aug 2002
Posts: 382
Location: Stockholm, Sweden
|
 Posted: Wed Dec 25, 2024 10:20 am Post subject: nfs mount (systemd) fails during boot.[solved] |
 |
|
Hi all (merry Christmas!),
I have some problem with booting a laptop of mine - during boot, I cannot get a nfs mount point to work when I am connecting to network using wifi. This is systemd, and I simply put 'noauto' when I installed this box last spring.
I am not sure how it is supposed to work, so I figured I should ask.
This is what journalctl has to say about it;
| Code: | dec 25 10:47:25 think3 systemd[1]: systemd-rfkill.service: Deactivated successfully.
dec 25 10:47:27 think3 wpa_supplicant[494]: wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=SE
dec 25 10:47:27 think3 NetworkManager[461]: <info> [1735120047.3478] manager: startup complete
dec 25 10:47:27 think3 systemd[1]: Finished Network Manager Wait Online.
dec 25 10:47:30 think3 systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
dec 25 10:47:43 think3 wpa_supplicant[494]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.BSS dbus_property=RSN getter failed
dec 25 10:47:43 think3 wpa_supplicant[494]: dbus: wpa_dbus_get_object_properties: failed to get object properties: (org.freedesktop.DBus.Error.Failed) failed to parse RSN IE
dec 25 10:47:43 think3 wpa_supplicant[494]: dbus: Failed to construct signal
dec 25 10:47:43 think3 wpa_supplicant[494]: dbus: fill_dict_with_properties dbus_interface=fi.w1.wpa_supplicant1.BSS dbus_property=RSN getter failed
dec 25 10:47:50 think3 systemd[1]: systemd-hostnamed.service: Deactivated successfully.
dec 25 10:49:19 think3 systemd-networkd-wait-online[382]: Timeout occurred while waiting for network connectivity.
dec 25 10:49:19 think3 systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
dec 25 10:49:19 think3 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
dec 25 10:49:19 think3 systemd[1]: Failed to start Wait for Network to be Configured.
dec 25 10:49:19 think3 systemd[1]: Reached target Network is Online.
dec 25 10:49:19 think3 systemd[1]: Mounting /mnt/oxygen...
dec 25 10:49:19 think3 systemd[1]: Starting Docker Application Container Engine...
dec 25 10:49:19 think3 mount[534]: mount.nfs: Network is unreachable for oxygen://home/public on /mnt/oxygen
dec 25 10:49:19 think3 systemd[1]: mnt-oxygen.mount: Mount process exited, code=exited, status=32/n/a
dec 25 10:49:19 think3 systemd[1]: mnt-oxygen.mount: Failed with result 'exit-code'.
dec 25 10:49:19 think3 systemd[1]: Failed to mount /mnt/oxygen.
dec 25 10:49:19 think3 systemd[1]: Dependency failed for Remote File Systems.
dec 25 10:49:19 think3 systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.
dec 25 10:49:19 think3 systemd[1]: Starting Permit User Sessions...
dec 25 10:49:19 think3 systemd[1]: Finished Permit User Sessions.
dec 25 10:49:19 think3 systemd[1]: Started Simple Desktop Display Manager.
|
And this is how my fstab looks like;
| Code: | oxygen://home/public /mnt/oxygen nfs _netdev,auto,defaults,noatime 0 0
|
I tried first without _netdev, but I'm not sure that made any significant difference.
The way I see this, is that it might be either bad configuration of network manager (the log seems to suggest this), or something systemd (normally, my computers has systemV).
I don't remember how I configured Wifi on this machine, since it was some time ago, but it works fine after I have kde up, and then I can manually mount the nfs share.
Last edited by vespaman on Fri Dec 27, 2024 1:41 pm; edited 1 time in total |
|
| Back to top |
|
 |
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3929
|
| Posted: Thu Dec 26, 2024 12:53 am Post subject: |
|
|
Is "oxygen" resolvable?
also this is the correct format:
| Code: |
oxygen:/home/public /mnt/oxygen nfs _netdev,defaults,noatime 0 0
|
_________________
 |
|
| Back to top |
|
|
vespaman
Guru
Joined: 28 Aug 2002
Posts: 382
Location: Stockholm, Sweden
|
| Posted: Thu Dec 26, 2024 1:18 pm Post subject: |
|
|
| alamahant wrote: |
Is "oxygen" resolvable?
|
Yes, from hosts file.
| Quote: |
also this is the correct format:
| Code: |
oxygen:/home/public /mnt/oxygen nfs _netdev,defaults,noatime 0 0
|
|
OK, I tested to remove 'auto' (I had it since I put noauto in order to not get stuck during boot), but that did not make any difference.
What happens, is that, during boot, unless I have an ethernet cable plugged, there's a 2 minute delay/hang, which makes me think that the solution is to make sure wifi is up before entering kde, which is not the case now. If I have ethernet cable plugged, there's no delay, and the remote share is mounted as it should. |
|
| Back to top |
|
|
steve_v
Guru
Joined: 20 Jun 2004
Posts: 416
Location: New Zealand
|
| Posted: Thu Dec 26, 2024 4:02 pm Post subject: |
|
|
I don't use systemd (or networkmangler for that matter) myself, but from the log I'd say this is fairly obviously a wireless connection issue.
Does NetworkManager have acces to the wireless keys before user login? (IIRC that means it has to be set as a "System" connection or "store password for all users", depending on the frontend).
If connectivity can't be relied on at boot, fstab may not be the best place to set up an NFS mount. Used to use autofs for this, but I hear systemd has similar functionality built-in these days.
_________________
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy. |
|
| Back to top |
|
|
vespaman
Guru
Joined: 28 Aug 2002
Posts: 382
Location: Stockholm, Sweden
|
| Posted: Fri Dec 27, 2024 1:40 pm Post subject: |
|
|
Thank you, with your suggestions, I found the setting "All users may connect to this network", which I enabled. (The interface was already set as "Infrastructure").
This gave me a better result; the wifi seems to come up, the mount point is mounted, but there's still a long, minute delay after (afaict) the wifi connection has succeeded.
I removed the _netdev argument from fstab, it does not seem to make any difference here.
Then I disabled the 'systemd-networkd-wait-online.service', probably something I have added (?), well without it, I don't get the 2 minute delay, and everything works now. |
|
| Back to top |
|
|
rab0171610
Guru
Joined: 24 Dec 2022
Posts: 445
|
| Posted: Fri Dec 27, 2024 2:24 pm Post subject: |
|
|
Glad you were able to figure it out. Some additional info that might help anyone that stumbles across this with the same issue . . .
If you are using NetworkManager, you can mask/disable the systemd-networkd.service and systemd-networkd-wait-online.service.
For me:
| Code: | | systemctl is-enabled NetworkManager-wait-online.service NetworkManager.service systemd-networkd-wait-online.service systemd-networkd.service |
Returns:
| Code: | enabled
enabled
masked
disabled |
systemd-networkd-wait-online.service will almost always fail and timeout if NetworkManger is being used to manage network interfaces rather than systemd-networkd. They are conficting services. As to your comment, I don't think it likely you explicitly enabled them. When initially installing systemd on Gentoo per the handbook, in the section "Preset services" states:
| Quote: |
Most services are disabled when systemd is first installed. A "preset" file is provided, and may be used to enable a reasonable set of default services. |
Followed by the command:
| Code: | | systemctl preset-all |
This enables a default set of systemd services. Those services are loaded from the file '/usr/lib/systemd/system-preset/90-systemd.preset'.
That file contains these two lines:
| Code: | enable systemd-networkd.service
enable systemd-networkd-wait-online.service |
There is no mention of NetworkManager.service in that file. I guess it is assumed that if and when later setting up NetworkManager, the user will disable the default networkd service they indirectly enabled and then subsequently enable the NetworkManager service. I did not understand that and figured it out later when troubleshooting long boot times waiting for systemd services to timeout. In my case, when using 'systemd-analyze blame' it was due to the systemd-networkd-wait-online.service. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
