| Summary: | At boot nfs tries to mount before dns has been started | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Herman Viaene <herman.viaene> |
| Component: | RPM Packages | Assignee: | Guillaume Rousse <guillomovitch> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | marja11, ngompa13, ouaurelien |
| Version: | 6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | nfs-utils | CVE: | |
| Status comment: | |||
|
Description
Herman Viaene
2018-01-05 14:02:02 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 nfs-client.target should be in nfs-utils, not systemd. Source RPM:
systemd =>
nfs-utils @ Marja : no I don't run cauldron. @ David : is this a hint that I should try another solution? 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 @ 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. 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. 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 |