Description of problem: Network mounts (CIFS) fail since fstab entries mounted before network initialization is complete Version-Release number of selected component (if applicable): upstart-0.3.9-13.fc9.i386 How reproducible: every boot Steps to Reproduce: 1. boot system 2. 3. Actual results: fstab cifs file systems not mounted. Have to manually mount -a after system is up. Expected results: fstab cifs file systems normally mounted during upstart transactions Additional info: dmesg output: IA-32 Microcode Update Driver: v1.14a <tigran.co.uk> ip6_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (16384 buckets, 65536 max) ip_tables: (C) 2000-2006 Netfilter Core Team RPC: Registered udp transport module. RPC: Registered tcp transport module. CIFS VFS: Error connecting to IPv4 socket. Aborting operation CIFS VFS: cifs_mount failed w/return code = -101 Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.9 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 sky2 eth0: enabling interface ADDRCONF(NETDEV_UP): eth0: link is not ready sky2 eth0: Link is up at 1000 Mbps, full duplex, flow control both ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready eth0: no IPv6 routers present
This is not really an upstart bug, this is a netfs/NetworkManager interaction problem.
Disaabled network manager service, enabled network service and problem is resolved. Will let Mr. Nottingham assign properly. Thanks for pointing out real issue.
There's a hack fix for this in initscripts-8.68-1 - it enables netfs to be run as a NetworkManagerDispatcher service.
Network service has to be enabled for this to work. Is that correct? If not, then the hack did not work for me.
No. It will re-run the netfs scripts whenever NM gets a working connection. (You'll still get a 'FAILED' on startup from netfs ; that part hasn't been fixed yet.)
Ok, then shouldn't this bug be reopened since network mounts in fstab fail, but not a blocker since a workaround (at least for me, I don't know about other cases) exists? Thanks and regards....
They shouldn't fail, they should work as soon as the network is available.
True, they will come up, but they aren't automatically mounted with the other devices in fstab. You have to remember to do a manual mount -a after your desktop or tty session is available. It is that reason that made me wonder if the bz should be left open but not as a blocker.
I think we're talking past each other. You should *not* have to manually mount anything with the fixes in 8.68-1.
My bad....I had assumed that since I updated rawhide this afternoon that I had the new initscripts. Not true. Got it from koji and now all is well. Sorry for all the noise.