Bug 702261 - network service not running on minimal install
Summary: network service not running on minimal install
Keywords:
Status: CLOSED DUPLICATE of bug 693602
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL: RejectedBlocker, RejectedNTH
Whiteboard:
: 683245 705024 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-05 08:11 UTC by Kamil Páral
Modified: 2011-10-13 18:29 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-07-14 16:04:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg output (123.23 KB, text/plain)
2011-07-06 11:37 UTC, Gratien D'haese
no flags Details
The messages file (380.91 KB, text/plain)
2011-07-06 11:39 UTC, Gratien D'haese
no flags Details
systemd dump (287.05 KB, text/plain)
2011-07-06 11:43 UTC, Gratien D'haese
no flags Details
output of systemd test (308.88 KB, text/plain)
2011-07-06 11:45 UTC, Gratien D'haese
no flags Details

Description Kamil Páral 2011-05-05 08:11:36 UTC
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?

Comment 1 Kamil Páral 2011-05-05 08:12:11 UTC
It wouldn't be me if I hadn't filed at least one blocker bug for the final release. Marking as such.

Comment 2 Radek Vykydal 2011-05-05 12:13:49 UTC
(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.)

Comment 3 James Laska 2011-05-05 12:23:01 UTC
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

Comment 4 Radek Vykydal 2011-05-05 12:29:30 UTC
Bill, do you have any advice?

Comment 5 Kamil Páral 2011-05-05 12:32:38 UTC
(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)

Comment 6 Kamil Páral 2011-05-05 12:33:20 UTC
(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.

Comment 7 Radek Vykydal 2011-05-05 13:10:09 UTC
(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).

Comment 8 Bill Nottingham 2011-05-05 16:04:43 UTC
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.

Comment 9 Jiri Popelka 2011-05-06 08:48:08 UTC
(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.

Comment 10 James Laska 2011-05-06 13:42:10 UTC
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

Comment 11 Tim Flink 2011-05-06 17:14:19 UTC
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.

Comment 12 Radek Vykydal 2011-05-16 13:02:43 UTC
*** Bug 705024 has been marked as a duplicate of this bug. ***

Comment 13 Radek Vykydal 2011-05-23 16:28:17 UTC
*** Bug 683245 has been marked as a duplicate of this bug. ***

Comment 14 Gratien D'haese 2011-07-06 11:37:55 UTC
Created attachment 511478 [details]
dmesg output

The output of the dmesg command

Comment 15 Gratien D'haese 2011-07-06 11:39:06 UTC
Created attachment 511479 [details]
The messages file

messages files with debug enabled (of systemd)

Comment 16 Gratien D'haese 2011-07-06 11:43:15 UTC
Created attachment 511480 [details]
systemd dump

Comment 17 Gratien D'haese 2011-07-06 11:45:54 UTC
Created attachment 511481 [details]
output of systemd test

Comment 18 Gratien D'haese 2011-07-06 13:38:41 UTC
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 .

Comment 19 Gratien D'haese 2011-07-14 07:20:26 UTC
By running:
# chkconfig network on
the problem is solved.

Comment 20 Brian Lane 2011-07-14 16:04:05 UTC
This is by design on minimal installs.

Comment 21 Artem S. Tashkinov 2011-07-14 16:22:08 UTC
(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.

Comment 22 Kamil Páral 2011-07-15 07:30:17 UTC
(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.

Comment 23 Bill Nottingham 2011-07-15 15:19:48 UTC
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.

Comment 24 Kamil Páral 2011-07-16 12:22:47 UTC
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)?

Comment 25 Bill Nottingham 2011-09-23 18:32:23 UTC
*** Bug 740674 has been marked as a duplicate of this bug. ***

Comment 26 Adam Williamson 2011-10-13 18:29:59 UTC

*** This bug has been marked as a duplicate of bug 693602 ***


Note You need to log in before you can comment on or make changes to this bug.