Description of problem: My main desktop is sharing out some NFS shares. It is an M5 fully updated. On testing the M6's, i always test the setting up of the NFS client in MCC, that works OK very time (up to now). But when I reboot such an M6, and go immediately for the NFS shares, I draw a blank - no files or folders displayed. If I don't do that so quickly, and give it a minute or two, then the NFS shares show up completely and quickly enough for my taste. I have no performance complaints. This is the same for my two testing laptops, the old i586 with 2.4Ghz wifi connection and the new x86-64 with 5Ghz wifi connection. I will include a systemd-analyze plot of such start up (i586 laptop) I notice nfs-client kicking in at about 26 sec., and actual mounts at about 69 sec. Version-Release number of selected component (if applicable): M6 rc (various versions) How reproducible: Every time Steps to Reproduce: 1. 2. 3.
Created attachment 9293 [details] output of systemd-analyze plot
CC: (none) => wilcal.int
On real hardware, M6, KDE, 64-bit Package(s) under test: nfs-utils default install of nfs-utils [root@localhost wilcal]# urpmi nfs-utils Package nfs-utils-1.3.4-2.mga6.x86_64 is already installed Let me share how I test/use nfs-utils. Because this package has had a long history every time I turn on any of my workstations it requires that the clients nfs share mount works properly. On my main server, that is on all the time, I have a nfs shared directory that contains many things one of which are a selection of KDE/Plasma desktop backgrounds. A nice image that includes text that tells me what kind of a client platform is being booted. In this case: Mageia 6 64-bit HW It also has images like: Mageia 6 32-bit Vbox So when the workstation KDE/Plasma client boots it would load the background image from the shared directory and I would know immediately that the share had been mounted. If nfs does not work then the Mageia default desktop background is used. If there is any delay the shared background wouldn't get loaded. I haven't seen that in a long time.
(In reply to William Kenney from comment #2) > If there is any delay the shared background wouldn't get loaded. I haven't > seen > that in a long time. If you were to click on the View link in the attachment details and search for network-up you might notice it is taking 40+ seconds just to get network access on Herman's hardware. That is what is causing the delay and should have been the bug summary and in the description.
CC: (none) => bittwister2
Copying from QA-ml BitTwister's responses: "Just as I expected, the delay is the 40+ second delay by network-up.service. I run with dual nic harware and was getting ~20 second delay per nic when running network service with NetworkManager not enabled/used. My solution was to disable both and use systemd-networkd and systemd-resolved services. It gets the network up in about 247ms and systemd-resolved is active ~40ms later. You might check the results from grep -i delay /etc/sysconfig/network-scripts/ifcfg-* " The grep as stated above does not return anything. I made a guess and searched on if* instead and there I got responses from ifup. Is that what BT is getting after?? And BT's solution is beyond me, I would need some handholding there.
(In reply to Herman Viaene from comment #4) > Copying from QA-ml BitTwister's responses: > "Just as I expected, the delay is the 40+ second delay by network-up.service. > > You might check the results from > grep -i delay /etc/sysconfig/network-scripts/ifcfg-* " > > The grep as stated above does not return anything. I made a guess and > searched on if* instead and there I got responses from ifup. Is that what BT > is getting after?? As I misunderstand it, there are three possible network services, network, networkmanager, and systemd-networkd. First there was network which used configuration files from /etc/sysconfig/network-scripts/. Example delay snippet: $ grep -i delay /etc/sysconfig/network-scripts/ifcfg-* /etc/sysconfig/network-scripts/ifcfg-enp2s0:LINK_DETECTION_DELAY=10 /etc/sysconfig/network-scripts/ifcfg-enp3s5:LINK_DETECTION_DELAY=6 The wired nic config file /etc/sysconfig/network-scripts/ifcfg-en* is normally created/configured during network setup upon install. Upon boot, network service scripts would check link status and if failed, delay, and try again. Then along came networkmanager and finally systemd-networkd. I have no idea where networkmanager stores its configuration files. You may be able to find your nic config file using locate. Example using my setup. $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.11.1 0.0.0.0 UG 0 0 0 enp3s0 192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0 $ locate enp3s0 /etc/sysconfig/network-scripts/ifcfg-enp3s0 /usr/lib/systemd/network/10_xx__enp3s0.network 10_xx__enp3s0.network is the systemd-network configuration file I create using my install scripts. > And BT's solution is beyond me, I would need some hand holding there. # man systemd.network # http://www.freedesktop.org/software/systemd/man/systemd.network.html And you would have to manually create/edit/maintain it yourself. Network control center in MCC would not support it. Get a free Usenet account at http://www.eternal-september.org/, install an Internet news reader client, subscribe to alt.os.linux.mageia, post with a subject like How do I configure systemd-networkd provide the nic configuration file and I will work with you. Oh yeah, after getting your id/pw from esept, subscribe to local.test and post/reply a test message to verify you have configured your Usenet news client correctly and know how to use it. http://www.eternal-september.org/index.php?showpage=faq Thunderbird can be configured to read/reply to Usenet groups. knode does not render posted scripts reliably and not supported on Cauldron, I use slrn myself.
route -n returns as interface wlp0s29f7u4 and there is a ifcfg-wlp0s29f7u4 file in /etc/sysconfig/network-scripts/, but that one has no "delay" string. Manually maintaining network setup is out for me. I want to use/test Mageia as it is delivered to the users. I value greatly what you're doing (see below), but things should work "properly" without such interventions. I am on that Usenet group since "ages". In the past you have helped me out on various questions. Posts signed with "Herman" are mine.
(In reply to Herman Viaene from comment #6) > route -n > returns as interface wlp0s29f7u4 and there is a ifcfg-wlp0s29f7u4 file in > /etc/sysconfig/network-scripts/, but that one has no "delay" string. Ok, there is your problem, wireless taking 40+ seconds to connect and get network access for nfs client. Not a nfs client problem at all. > Manually maintaining network setup is out for me. I want to use/test Mageia > as it is delivered to the users. Last line of comment 4 suggested otherwise, to me. > I value greatly what you're doing (see > below), but things should work "properly" without such interventions. Well it is working, just very slowly for you in wireless only network.
(In reply to Herman Viaene from comment #0) > Description of problem: > My main desktop is sharing out some NFS shares. It is an M5 fully updated. > On testing the M6's, i always test the setting up of the NFS client in MCC, > that works OK very time (up to now). > > But when I reboot such an M6, and go immediately for the NFS shares, I draw > a blank - no files or folders displayed. If I don't do that so quickly, and > give it a minute or two, then the NFS shares show up completely and quickly > enough for my taste. I have no performance complaints. > This is the same for my two testing laptops, the old i586 with 2.4Ghz wifi > connection and the new x86-64 with 5Ghz wifi connection. > > I will include a systemd-analyze plot of such start up (i586 laptop) > I notice nfs-client kicking in at about 26 sec., and actual mounts at about > 69 sec. > But that's still right before prefdm.service is started.... or aren't you talking about a delay seeing your NFS shares in your _Desktop_Environment_? Can you attach journal.txt that is the result of, as root: journalctl -ab > journal.txt Please fetch it from your new laptop (old laptops tend to be slow, even without bugs).
CC: (none) => guillomovitch, mageiatools, marja11Keywords: (none) => NEEDINFOSource RPM: (none) => nfs-tools?, drakx-net?
Too late, I could not replicate the problem anymore with the latest (14/5) RC. I will reopen the bug if it would crop up again.
Status: NEW => RESOLVEDResolution: (none) => FIXED