Description of problem: I did a minimal install of Fedora 15 Final TC1 netinst. After boot the system has eth0 enabled, but network is not working. Systemd reports the service as dead. Restarting network service fixes the problem. $ ip a s eth0 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 52:54:00:3b:98:c3 brd ff:ff:ff:ff:ff:ff $ grep ONBOOT /etc/sysconfig/network-scripts/ifcfg-eth0 ONBOOT="yes" $ service network status Configured devices: lo eth0 Currently active devices: lo $ systemctl status network.service network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: inactive (dead) CGroup: name=systemd:/system/network.service $ service network restart Restarting network (via systemctl): [ OK ] $ ip a s eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:3b:98:c3 brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0 inet6 fe80::5054:ff:fe3b:98c3/64 scope link valid_lft forever preferred_lft forever Version-Release number of selected component (if applicable): anaconda-15.30 systemd-units-26-1.fc15.i686 systemd-26-1.fc15.i686 How reproducible: always Steps to Reproduce: 1. do minimal netinst install (or DVD+updates enabled) 2. try network connection Actual results: network doesn't work, although enabled Expected results: network works Additional information: Maybe it's systemd bug?
It wouldn't be me if I hadn't filed at least one blocker bug for the final release. Marking as such.
(In reply to comment #1) > It wouldn't be me if I hadn't filed at least one blocker bug for the final > release. Marking as such. I am not sure if the bug (concerning minimal install) qualifies as final release blocker - what is the respective criterion? https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria Well - James Laska would tell us I guess. I think this should be handled with systemd and postinstall scripts, not in anaconda. NetworkManager enables itself in postinstall script, network service does not (in initscripts package). I suppose systemd has mechanism to enable the network service in case of missing NM service. (Or just in the case, if network service should be set to be enabled by postinstall script.)
In my @minimal text-mode install ... networking is not enabled, I don't think this is a recent change in F15. Of course, we can continue to explore that. Kparal, is the network.service enabled on your system? It isn't on my @minimal install. # chkconfig --list network Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overriden by native systemd configuration. network 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Bill, do you have any advice?
(In reply to comment #2) > I am not sure if the bug (concerning minimal install) qualifies as final > release blocker - what is the respective criterion? I suspected: "All services in a default install must start properly" Because I supposed that network service is crashing on start (systemd reports "dead"). If it is intentionally not started, I'm not sure if it fits in here. EDIT: I overlooked the phrase "default install". Therefore it may not apply to minimal install. We also have the criteria about browser being able to download from the web, but that is more targeted at desktop environment than shell environment (but well, is it? and does it mean "it may be mandatory to restart service in advance"?). Anyway, just proposing. > (Or just in the case, if > network service should be set to be enabled by postinstall script.) Good question, what's the reason to have it off by default? (it's off even for default install, but network works there)
(In reply to comment #3) > Kparal, is the network.service enabled on your system? It isn't on my @minimal > install. > > # chkconfig --list network > > Note: This output shows SysV services only and does not include native > systemd services. SysV configuration data might be overriden by native > systemd configuration. > > network 0:off 1:off 2:off 3:off 4:off 5:off 6:off The same for me. It is also the same for default install.
(In reply to comment #5) > Good question, what's the reason to have it off by default? (it's off even for > default install, but network works there) On default install network works because NetworkManager with enabled NetworkManager.service (which is separate from initscript's network.service if I understand it correctly) is there. It might be correct to have network.service off after install if it is not required by another services, which I can imagine in minimal install but I am not positive about it. In my understanding, NetworkManager.service and network.service should be aggregated somehow so that if network target is required systemd can start appropriate service (based on availability and possible conflicts).
network.service has been disabled by default in favor of NetworkManager since March 2008; this is not new behavior. In fact, there's at least a couple of different bugs (against anaconda?) filed about this. Options are: 1) have anaconda enable the service when necessary (ugly) 2) enable them both (has some interaction issues currently) 3) do nothing We usually fall through to #3.
(In reply to comment #8) > In fact, there's at least a couple of > different bugs (against anaconda?) filed about this. For example bug #693602, bug #557112.
I don't think we have any changes in behavior between F14 and F15 with regards to a @minimal install and the network initscript. I think the changes discussed in comment#8 are ideal, but more a feature/enhancement and not something we should accept for F15 at this stage. I recommend we move this issue to rawhide/F16 and work with anaconda/systemd to find an ideal solution. -1 Blocker, -1 NTH
Discussed in the 2011-05-06 blocker review meeting. Rejected as blocker and NTH because this behavior is not a regression from previous releases and the impact is rather low.
*** Bug 705024 has been marked as a duplicate of this bug. ***
*** Bug 683245 has been marked as a duplicate of this bug. ***
Created attachment 511478 [details] dmesg output The output of the dmesg command
Created attachment 511479 [details] The messages file messages files with debug enabled (of systemd)
Created attachment 511480 [details] systemd dump
Created attachment 511481 [details] output of systemd test
On a fresh f15 installation we encountered this bug report. By default NM is active and network not: # chkconfig --list | grep -i netw network 0:off 1:off 2:off 3:off 4:off 5:off 6:off However, in the messages file we find the line: Jul 6 08:11:36 main dbus: avc: netlink poll: error 4 And, the eth0 (or p3p1) is down. Once booted we can bring up the network without any problems (not using dhcp) with "service network start" (using systemctl). I've added several attachment which could be useful for troubleshooting. I still have the feeling it is an order issue. See comment #14 - comment #17 .
By running: # chkconfig network on the problem is solved.
This is by design on minimal installs.
(In reply to comment #20) Networking broken by design™, a new Fedora's motto. I can live with that, no prob, but at least document this "feature" so that people don't beat their heads against the wall. And I bet this bug report will have new duplicates.
(In reply to comment #20) > This is by design on minimal installs. Brian, 'network' service is disabled by default, correct, as Radek Vykydal and Bill Nottingham described together with its reasons. But it is not "by design" to have networking disabled. Or is it? Could you please point me to some documents showing consensus about having networking disabled by design? Do we have it described somewhere? Do we have it documented? Is it what users expect and desire? (And I don't mean business users here.) Artem described it correctly: "Networking broken by design™, a new Fedora's motto." That's exactly what Anaconda currently does (default minimal install and default DVD install) and I strongly doubt that's something what our major user-base asks for. Kindly requesting re-opening and discussing what we want, not what we have.
The default install ships NetworkManager enabled, and network disabled. This is done in packaging. The minimal install does not include NetworkManager, so you end up with just the network script, disabled. To 'fix' this the way you'd like, we'd either have to have both services enabled (casues some issues) or have a good way to enable network.service IFF NetworkManager isn't installed. We don't have that right now, which causes this situation.
Thanks, Bill, for continuing this conversation. I understand the reasons. I would like to ask a different question: Is there a will (from Anaconda developers) to change this situation in the future? Then it would make sense to leave this bug open to track it. If there is no such will, is there a way to create it? If I investigate status of the same issue in other Linux distribution, will it help the cause? > or have a good way to enable network.service IFF > NetworkManager isn't installed. We don't have that right now, which causes this > situation. Checking whether NetworkManager was installed and running "chkconfig network on" inside Anaconda otherwise is a bad idea? Or could the network.service be enabled by default, but installing NM would disable it in postinst script (since NM replaces the functionality)?
*** Bug 740674 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 693602 ***