Bug 22319 - At boot nfs tries to mount before dns has been started
Summary: At boot nfs tries to mount before dns has been started
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 6
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Guillaume Rousse
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-05 14:02 CET by Herman Viaene
Modified: 2020-08-16 15:50 CEST (History)
3 users (show)

See Also:
Source RPM: nfs-utils
CVE:
Status comment:


Attachments

Description Herman Viaene 2018-01-05 14:02:02 CET
Description of problem:
Laptop has been configured with MCC to connect to NFS shares from desktop computer. The latter also act as DNS server for my internal network. So the NFS shares in the laptop have been defined and stored in /etc/fstab with FQDN, not with IP addresses.
When the laptop is booted, the NFS shares are not mounted, and the journal reads during boot for the NFS mounts "<FQDN> could not be resolved. 

Version-Release number of selected component (if applicable):


How reproducible:
Everu time

Steps to Reproduce:
See above

Possible solution: after discussing this in the weekly QA meeting, I added After=nss-lookup.target to /etc/systemd/system/remote-fs.target.wants/nfs-client.target and rebooted.
Now the shares are mounted straight after booting.
Remark : this has been tested on an old slow Dell Latitude D600 laptop. I will try later on a recent Lenovo.
Comment 1 Marja Van Waes 2018-01-07 08:29:59 CET
(In reply to Herman Viaene from comment #0)

> 
> Possible solution: after discussing this in the weekly QA meeting, I added
> After=nss-lookup.target to
> /etc/systemd/system/remote-fs.target.wants/nfs-client.target and rebooted.
> Now the shares are mounted straight after booting.
> Remark : this has been tested on an old slow Dell Latitude D600 laptop. I
> will try later on a recent Lenovo.

Assigning to systemd, then.

I guess you have no idea whether this works  better in cauldron?
(I can't imagine you running cauldron with all the test systems you already run for QA updates testing ;-) )

CC: (none) => marja11, ngompa13
Source RPM: (none) => systemd
Assignee: bugsquad => basesystem

Comment 2 David Walser 2018-01-08 17:18:49 CET
nfs-client.target should be in nfs-utils, not systemd.

Source RPM: systemd => nfs-utils
Assignee: basesystem => guillomovitch

Comment 3 Herman Viaene 2018-01-09 08:51:02 CET
@ Marja : no I don't run cauldron.
@ David : is this a hint that I should try another solution?
Comment 4 Guillaume Rousse 2018-01-09 19:08:37 CET
Herman, just than the fix belongs to nfs-utils package :)

However, wrt to your own setup, it seems a bit overkill to run a DNS server, unless you have really a lot of machines. Just keeping needed entries in /etc/hosts file should be enough. And you'd better mount NFS share on demand, using either autofs (legacy solution) or systemd (new solution) to avoid boot ordering issues, instead of static mount points defined in /etc/fstab. But that's mostly a preference matter.

Status: NEW => ASSIGNED

Comment 5 Herman Viaene 2018-01-10 09:09:25 CET
@ Guiillaume
I understand your remarks, and they are prefectly reasonable. However, I wanted to learn those things and make sure that I know how to keep these alive over different Mageia releases. Just my curiosity. And its great for QA testing.
Comment 6 Guillaume Rousse 2018-01-18 20:27:48 CET
Actually, I'm a bit confused about the semantics of remote-fs.target (belonging to systemd) and nfs-client.target (belonging to nfs-utils). And to add yet more noise, there is even remote-fs-pre.target (belonging to systemd also).

Whereas this is quite evident we need a dependency on nss-lookup.target somewhere, I'm less sure about the best place for it.
Comment 7 Aurelien Oudelet 2020-08-16 15:50:11 CEST
Mageia 6 changed to end-of-life (EOL) status on 2019-09-30. It is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

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

Bug Reporter: Thank you for reporting this issue and we are sorry that we 
weren't able to fix it before Mageia 6's end of life. If you are able to 
reproduce it against a later version of Mageia, you are encouraged to click 
on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a more recent
Mageia release includes newer upstream software that fixes bugs or makes them
obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Best regards,
Aurélien
Bugsquad Team

CC: (none) => ouaurelien
Resolution: (none) => OLD
Status: ASSIGNED => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.