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.
Fiddling with the boot sequence is for the base system maintainers, right?
CC: (none) => marja11Assignee: bugsquad => basesystem
I believe that is where it was fixed before.
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
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 => majorPriority: Normal => release_blocker
Keywords: (none) => 7beta1
Todays Vbox client and Intel real hardware installs indicate that this issue has been resolved. Changing status to: Resolved
Keywords: 7beta1 => 7beta2Resolution: (none) => FIXEDPriority: release_blocker => LowStatus: NEW => RESOLVEDSeverity: major => minor