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
Fiddling with the boot sequence is for the base system maintainers, right?
I believe that is where it was fixed before.
Previous NFS mount bugs
Summary: At boot nfs tries to mount before dns has been started
Summary: Nfs client slow picking up NFS shares after boot
Summary: NFS mount function is not working
Summary: no nfs share mount after upgrade M4.1 -> M5RC i586
Summary: Incorrect nfs-util install error message
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.
Todays Vbox client and Intel real hardware installs indicate that this issue has been resolved.
Changing status to: Resolved