Hello,
On my previous laptop I installed Kinoite 44 to test it/play with it, see what it can and can not (yet) do.
I found an issue which surprises me since in all previous versions it just worked.
I mounted an nfs drive through an extra line in fstab: 192.168.x.xxx:/nfs/Xxxxxx /mnt/Nas nfs _netdev,user,rw 0 0
After editing the fstab file I typed sudo mount -a and I could see the contents of my Nas, as was to be expected.
But after a reboot I have to type sudo mount -a again. It seems f44 has a short memory.
Is this caused by a deliberate change and do I need to do something I never had to do before, or is this a bug, or something which is just not ready yet?
I found this in the log file:
Feb 20 20:23:25 fedora-kinoite-44 systemd[1]: Finished NetworkManager-wait-online.service - Network Manager Wait Online.
Feb 20 20:23:25 fedora-kinoite-44 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/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 20 20:23:25 fedora-kinoite-44 systemd[1]: Reached target network-online.target - Network is Online.
Feb 20 20:23:25 fedora-kinoite-44 systemd[1]: Mounting var-mnt-Nas.mount - /var/mnt/Nas...
Feb 20 20:23:25 fedora-kinoite-44 systemd[1]: Starting rpc-statd-notify.service - Notify NFS peers of a restart...
Feb 20 20:23:25 fedora-kinoite-44 sm-notify[1720]: Version 2.8.5 starting
Feb 20 20:23:25 fedora-kinoite-44 systemd[1]: Started rpc-statd-notify.service - Notify NFS peers of a restart.
Feb 20 20:23:25 fedora-kinoite-44 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/systemd" hostname=? addr=? terminal=? res=success'
Feb 20 20:23:26 fedora-kinoite-44 kernel: Key type dns_resolver registered
Feb 20 20:23:26 fedora-kinoite-44 kernel: NFS: Registering the id_resolver key type
Feb 20 20:23:26 fedora-kinoite-44 kernel: Key type id_resolver registered
Feb 20 20:23:26 fedora-kinoite-44 kernel: Key type id_legacy registered
Feb 20 20:23:26 fedora-kinoite-44 mount[1721]: mount.nfs: Network is unreachable for 192.168.1.228:/nfs/Public on /var/mnt/Nas
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: var-mnt-Nas.mount: Mount process exited, code=exited, status=32/n/a
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: var-mnt-Nas.mount: Failed with result 'exit-code'.
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: Failed to mount var-mnt-Nas.mount - /var/mnt/Nas.
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: Dependency failed for remote-fs.target - Remote File Systems.
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.
When I click that link in my main laptop with Kinoite 43, I immediately see the contents of the nas, as it has always been. You wrote:
Okay, when this is true then F43 shows me the contents because I ask for it by clicking the link to the nas.
When I click the link in the older laptop with Kinoite 44 I see: Folder is empty.
I just opened a terminal and typed (directly after boot): ls /mnt/Nasin F44. Result: total 0
I do the same in F43 and I get: total 16K and the listing of the nas contents.
In F44 I need to manually mount it after boot.
I do this now through a boot-up script with the command: mount -a.
In other words, there is a difference between Kinoite 43 and 44.
The way the nas is mounted in fstab in both laptops is exactly the same, with the same line I wrote in my first post.
Do I miss something here or am I right when I say there is something wrong in F44, which is not unthinkable because it is still pre-release software.
Feb 20 20:23:26 fedora-kinoite-44 mount[1721]: mount.nfs: Network is unreachable for 192.168.1.228:/nfs/Public on /var/mnt/Nas
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: var-mnt-Nas.mount: Mount process exited, code=exited, status=32/n/a
Feb 20 20:23:26 fedora-kinoite-44 systemd[1]: var-mnt-Nas.mount: Failed with result 'exit-code'.
So it seems like Kinoite hasn’t forgotten the mount, but it’s unable to reach the remote machine over the network.
But NetworkManager started up without reporting any problems, so I’m not really sure where to go next. Of course it could be a problem on your network rather than a Fedora problem.
Feb 20 20:23:25 fedora-kinoite-44 systemd[1]: Reached target network-online.target - Network is Online.
Feb 20 20:23:26 fedora-kinoite-44 mount[1721]: mount.nfs: Network is unreachable for 192.168.1.228:/nfs/Public on /var/mnt/Nas
Above it, it says Network is Online, so I would think the system should be able to mount the Nas.
It does so in F43, and it also does it when I use the bootscript with the mount -a command in F44. This does happen a bit later though, so I was thinking about a timing issue.
I searched for the error it gives me: Mount process exited, code=exited, status=32/n/a and AI gave me this:
Common Causes and Solutions
Network Unavailable (NFS mounts):
If mounting NFS shares, the error often occurs because the network is not fully ready during boot.
Solution: Use _netdev in /etc/fstab to ensure the mount waits for the network.
Add x-systemd.automount to defer mounting until access is attempted.
For systems using systemd-networkd, ensure systemd-networkd-wait-online.service is enabled and properly configured. If waiting for all interfaces causes timeouts (e.g., on laptops), override it to wait only for specific interfaces.
The option _netdev I have already used and it tells systemd to wait mounting the device until the network is ready. Either this does not work as it should, or the device (Nas) is not mounted.
I have now added the option x-systemd.automount and now after a reboot the Nas is mounted. In the newer laptop with F43 this was/is not needed.
I now have a working Nas attached to the laptop using the x-systemd.automount option in the fstab file but I still think it’s strange that the newer laptop with F43 has no problem mounting the Nas without the option.
I read on the internet on several websites issues with _ntedev not working as expected and came across this: page: Red Hat Bugzzilla where in comment 4 it is said: Oh.. no. The _netdev option is ignored in mount(8) by default. The options is used by initscripts only.
I also read that earlier this morning on other websites but can’t find the sites again.
As a test I removed _netdev in Kinoite 43 and the Nas gets still mounted perfectly.
Will do the same now in Kinoite 44.
In 44 I need to click the link to the Nas twice before I see it getting mounted.
I also removed x-systemd.automount but without it the Nas does not get mounted.
In 43 I don’t have the x-systemd.automount option and still the Nas gets mounted.
Network is the same, Nas is the same.
Older laptop, newer Kinoite, against newer laptop with older Kinoite.
Older laptop needs x-systemd.automount, newer one does not.
Timing issue?
Any ideas?
Thanks.
You may have already mentioned it, but at least to me it’s not entirely clear whether you’ve tried Kinoite 43 and 44 on both laptops.
That is, install Fedora Kinoite 43 and 44 on the old laptop and then install Fedora Kinoite 43 and 44 on the new laptop to observe the behavior and try to reproduce the issue on both machines with both Kinoite versions.
No, I did not write that and I had a reason for that, although now I think I might do half of what you suggest:
On the older laptop with Kinoite 44 I can rebase to Kinoite 43, after I pin the 44 deployment because I think since this is not an official one rebase probably doesn’t work.
I look into that.
Thanks for the tip.
Sorry for my bad wording. I meant to suggest that you try both versions on both laptops, either by rebasing or by switching if you are using bootable containers.
Don’t be sorry, I understood what you wrote, no problem.
It’s just that I prefer not to mess with my newer laptop which runs Kinoite 43. That machine is holly and has to keep running without me having to restore stuff.
But I rebased Kinoite 44 on the older laptop to 43 and there is no change between those 2.
Also now, directly after boot, I have to click twice on the Nas link in Dolphin before I see the contents of the Nas.
So, it must be the older laptop which is slower causing this issue. Probably a timing issue.
In the fstab file in the older laptop I have this:
192.168.1.228:/nfs/Public /mnt/Nas nfs x-systemd.automount,user,rw 0 0
In the fstab file in the newer laptop I have this:
192.168.1.228:/nfs/Public /mnt/Nas nfs user,rw 0 0
When I change fstab in the older laptop, remove x-systemd.automount, the Nas does not get mounted at all. It really needs that option, where the newer one does not need it.
Both on version 43.
Is there anything else you like me to do now that I have both on 43?
I’m still thinking about your suggestion and seeing how easy it was to rebase 44 to 43, I do think I will also do the rebase in the other laptop, from 43 to 44. Hold on. for a minute or more.
Of course there is an update as well, so it will a bit longer.
I now have the newer laptop also on version 44 and also here no change with 43.
Software is identical.
It’s just that the older laptop needs x-systemd.automount as option in the fstab line to mount my Nas.
From the latest update you provide, I assume that this is not a Kinoite 44 regression and therefore we do not need to file a bug report or open an issue.
No, since both versions act the same (per laptop) I would say it’s a difference between the two laptops.
One question about filing a bug for this, I tried to do it as well but I was asked the name of the component causing the issue. When you would file a bug report for this, what would you chose as the components name? In the list of over 41.000 items I could not find something matching this.
Thanks everyone.
You probably mean Red Hat Bugzilla. I’m not entirely sure how closely Atomic Desktops maintainers follow Red Hat Bugzilla.
What I would suggest as a basic workflow for reporting a potential issue is to first ask here, which you are already doing. This particular topic is a good example of why to do it as a first step. If further reporting is needed, a community member will likely direct you where and how to do it.
