Created attachment 829404 [details] dmesg sections from F19 & F20 showing network not active. Description of problem: NAS shares in /etc/fstab external to the machine are not mounting at boot time. Version-Release number of selected component (if applicable): Fedora 20 Beta x86_64 How reproducible: 100% - Install Fedora 20 Beta and the issue is present Steps to Reproduce: 1.Install Fedora 20 Beta x86_64 2.Modify /etc/fstab to include cifs shares 3.reboot Actual results: No cifs shares are mounted as shown by df -h Expected results: cifs shares should be mounted and accessible as shown by df -h Additional info: I will add an attachment file that shows the difference in F19 and F20 dmesg.
Can you please attach a full journalctl section for the boot process? the dmesg extracts are not interesting: all they show are the mounts failing. We know the mounts are failing, and we know why: because they're tried before the network is up. What we need to figure out is _why_ the mounts are being tried before the network is up, and we need more logs for that.
devs, there's some more info in this forum thread: http://forums.fedoraforum.org/showthread.php?t=295456 the reporter does apparently have NetworkManager-wait-online.service enabled, but the mount attempts still happen before the network comes up. So it seems. We'll need the full logs to be sure.
Created attachment 829629 [details] journalctl logs from last re-boot This attachment collected as root by # journalctl -l --no-pager > /home/swelch/Documents/journalctl.last-boot.txt
So...yeah, definitely seems wrong. NM starts up at 3:39:51. Remote mounts are tried at 3:39:52. But the connection doesn't really start coming up until 3:39:53 and it only shows as 'ready' at 3:39:57 and gets an IP and is 'activated' at 3:39:58. I see httpd starts up at 3:39:57 and has problems because the network isn't fully up, too. Definitely something screwy going on. Devs?
CCing dcbw, as NetworkManager-wait-online.service just runs 'nm-online', which is part of NetworkManager.
It seems to be an NM issue, as NM has indicated startup is complete right after finding p6p1: Nov 27 03:39:50 slwfed007.slwdomain NetworkManager[737]: <info> startup complete nm-wait-online looks for this 'startup' property to become true before continuing. NM appears to signal startup is complete, because the p6p1 device is not yet ready for a network connection, and only becomes ready later: Nov 27 03:39:53 slwfed007.slwdomain NetworkManager[737]: <info> (p6p1): link connected Nov 27 03:39:53 slwfed007.slwdomain NetworkManager[737]: <info> (p6p1): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40] were the interface to signal that it had a link earlier, this would not be a problem.
So in the end this is an NM problem; it appears that NM is the first thing to set the interface IFF_UP, and that NM is not waiting long enough for the device to do carrier detection before NM indicates that startup is complete.
So I don't loose track, this is also RHEL7 bug 1030583.
Fixes posted to dcbw/startup-link-wait-rh1030583-rh1034921 branch upstream.
it'd be great to get updates for this for F18, 19 and 20 if possible, thanks!
Created attachment 837816 [details] journalctl logs from install of Final Release 20 These logs show exactly the same issue with NM reporting ready before the NW interface is in-service. Same errors occurring when attemting to mount the cifs NAS shares before the NW interface is up.
NetworkManager-0.9.9.0-21.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-21.git20131003.fc20
Package NetworkManager-0.9.9.0-21.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-21.git20131003.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23593/NetworkManager-0.9.9.0-21.git20131003.fc20 then log in and leave karma (feedback).
NetworkManager-0.9.9.0-22.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-22.git20131003.fc20
Applied the patch: su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-21.git20131003.fc20' and rebooted. The cifs network shares are now mounting correctly and are available. Thanks for a great job.
Thanks, but please don't close it until the update goes stable :) If you can leave some 'karma' (feedback) on the update it'll help it get out.
NetworkManager-0.9.9.0-22.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I do NOT confirm the problem has gone: it is still reproduced in Fedora 20 with NetworkManager-0.9.9.0-30.git20131003.fc20.x86_64 installed. Note I specify 5 windows shares in 'fstab' and sometimes a couple of them are mounted correctly after the system boot.
I'm seeing the same issue too with the latest updates, including this one: nmvega@e6510$ rpm -qi NetworkManager Name : NetworkManager Epoch : 1 Version : 0.9.9.0 Release : 30.git20131003.fc20 Architecture: x86_64 Install Date: Sat 22 Feb 2014 08:26:47 PM EST Group : System Environment/Base Size : 4950661 License : GPLv2+ Signature : RSA/SHA256, Mon 17 Feb 2014 01:26:06 AM EST, Key ID 2eb161fa246110c1 Source RPM : NetworkManager-0.9.9.0-30.git20131003.fc20.src.rpm Build Date : Sun 16 Feb 2014 09:49:19 AM EST Build Host : buildvm-09.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.gnome.org/projects/NetworkManager/ Summary : Network connection manager and user applications
Does "closed errata" mean "we decided that Fedora won't be able to automount CIFS shares, and we'll just document that fact?" Certainly that isn't acceptable to the Fedora community ...
It means the bug we identified in NetworkManager is believed to be fixed. Snarky comments don't help us fix any other bugs that might exist. Detailed descriptions and logs would.