Bug 23863 - Timing of the nfs mount not working?
Summary: Timing of the nfs mount not working?
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Low minor
Target Milestone: ---
Assignee: Base system maintainers
QA Contact:
URL:
Whiteboard:
Keywords: 7beta2
Depends on:
Blocks:
 
Reported: 2018-11-20 23:03 CET by William Kenney
Modified: 2019-01-19 05:06 CET (History)
1 user (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description William Kenney 2018-11-20 23:03:07 CET
Description of problem:

This is a problem that has come up in previous Mageia Cauldrons

Here is the /etc/fstab

# Entry for /dev/sda5 :
UUID=4856ae35-209b-4f8d-b0be-2b9085726e87 / ext4 defaults 1 1
# Entry for /dev/sda1 :
UUID=72CB-1664 /boot/EFI vfat defaults,umask=000 0 0
# Entry for /dev/sda7 :
UUID=80df249f-b61e-4946-aab3-58bd0144f12f /home ext4 defaults 1 2
none /proc proc defaults 0 0
192.168.0.3:/home/wilcal/databank /home/wilcal/sherman nfs rsize=8192,wsize=8192,nosuid,soft 0 0
# Entry for /dev/sda6 :
UUID=fd941015-b5ca-4aed-b6a9-15094d776883 swap swap defaults 0 0

This 192.168.0.3 nfs share works every single time on all my M6 machines.
Seems if my memory is right we had problems with timing in M4 with this.
Well it's back. Once the machine has booted to the Plasma GUI you have
to open an SU Terminal and type:

[root@localhost wilcal]# mount -a

the remote nfs share then properly mounts and can be used. The way I
make sure my mounts are working after power up is to use a wallpaper
on the 192.168.0.3 nfs server. So when the desktop comes live it will
display that wallpaper. If the nfs mount does not work I get a functional,
but black screen with icons, desktop.

Seems that at one time we had to put some delays in the boot up sequence
to make sure all nfs shares were mounted before presenting the Plasma/KDE
desktop.
Comment 1 Marja Van Waes 2018-11-22 09:47:22 CET
Fiddling with the boot sequence is for the base system maintainers, right?

CC: (none) => marja11
Assignee: bugsquad => basesystem

Comment 2 William Kenney 2018-11-22 14:11:25 CET
I believe that is where it was fixed before.
Comment 3 William Kenney 2018-11-24 00:03:45 CET
Previous NFS mount bugs

https://bugs.mageia.org/show_bug.cgi?id=22319
Summary: At boot nfs tries to mount before dns has been started

Summary: Nfs client slow picking up NFS shares after boot
https://bugs.mageia.org/show_bug.cgi?id=20823

Summary: NFS mount function is not working
https://bugs.mageia.org/show_bug.cgi?id=17931

Summary: no nfs share mount after upgrade M4.1 -> M5RC i586
https://bugs.mageia.org/show_bug.cgi?id=15686

Summary: Incorrect nfs-util install error message
https://bugs.mageia.org/show_bug.cgi?id=14403
Comment 4 William Kenney 2018-12-13 19:28:30 CET
I'm going to change the Priority and Severity of this bug to release_blocker and major. It's on every M7 install and test I have run.

Severity: normal => major
Priority: Normal => release_blocker

William Kenney 2018-12-20 21:33:41 CET

Keywords: (none) => 7beta1

Comment 5 William Kenney 2019-01-19 05:06:39 CET
Todays Vbox client and Intel real hardware installs indicate that this issue has been resolved.
Changing status to: Resolved

Keywords: 7beta1 => 7beta2
Resolution: (none) => FIXED
Priority: release_blocker => Low
Status: NEW => RESOLVED
Severity: major => minor


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