Bug 467946 - network unavailable after booting
network unavailable after booting
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: system-config-network (Show other bugs)
10
All Linux
medium Severity high
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-21 15:54 EDT by Edwin Schepers
Modified: 2009-12-18 01:37 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:37:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Edwin Schepers 2008-10-21 15:54:46 EDT
Description of problem:
Every time I boot, I manually have to activate the network
At the installation I didn't have to setup my network and my network was configured dhcp. Booting gave no problem at all then. Until I changed dhcp to a fixed ip (using system-config-network). Since then, after booting my network is always deactivated. When I change back to dhcp, nothing changes and the network is still deactivated after booting.
I have the option "start network at startup" (translated) checked. 
How reproducible:


Steps to Reproduce:
1. change the default setting dhcp to fixed ip (with system-config-network)
2. reboot
Now, the network interface is disabled.
Comment 1 Marcela Mašláňová 2008-10-24 05:08:17 EDT
I have probably the same problem. I didn't try set fixed ip. Always after start of computer I have to type 'service network restart' for bringing network up. 

Could I provide any debug information for this problem?
The computer was updated from mini-install of F-9 to rawhide, because I wasn't able install from PXE boot because of NM :)

rpm -q NetworkManager
NetworkManager-0.7.0-0.11.svn4201.fc10.x86_64
Comment 2 Dan Williams 2008-10-24 10:30:14 EDT
Could you look and see if you have ONBOOT=no in any of the /etc/sysconfig/network-scripts/ifcfg-* files?  That will cause NetworkManager to only bring up the interface when you tell it to, not on-demand.
Comment 3 Edwin Schepers 2008-10-26 15:50:50 EDT
I have 2 ifcfg-* files, eth0 and lo. Below the contents of the files.

# Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller
DEVICE=eth0
HWADDR=00:18:f3:17:57:62
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none
TYPE=Ethernet
DNS1=10.0.0.138
USERCTL=yes
PEERDNS=yes
IPV6INIT=no
NETMASK=255.255.255.0
IPADDR=10.0.0.101
SEARCH=lan
GATEWAY=10.0.0.138

--------------
DEVICE=lo
IPADDR=127.0.0.1
NETMASK=255.0.0.0
NETWORK=127.0.0.0
# If you're having problems with gated making 127.0.0.0/8 a martian,
# you can change this to something else (255.255.255.255, for example)
BROADCAST=127.255.255.255
ONBOOT=yes
NAME=loopback
Comment 4 Marcela Mašláňová 2008-10-29 03:38:32 EDT
I have also ONBOOT=yes in both files.
Comment 5 Edwin Schepers 2008-10-31 16:26:45 EDT
Well it seemed I didn't have a /etc/rc5.d/S10network anymore. I now used 'chkconfig --level 5 network on' and now it works.
However I'm not able to let the link be removed again now.
Comment 6 Marcela Mašláňová 2008-11-03 03:16:53 EST
Shouldn't be in initscripts spec some line, which reset priorities? During upgrade from fresh minimal F-9 to rawhide, network stop working. I did network install, so the setting network on in level 5 should be preserved.
Comment 7 Bill Nottingham 2008-11-03 14:41:01 EST
NetworkManager is used by default - network is only on if manually enabled. It seems you had an install where that didn't happen?
Comment 8 Marcela Mašláňová 2008-11-04 03:22:54 EST
In this case, let's switch this component back to NetworkManager, which isn't working for me at all.
Comment 9 Marcela Mašláňová 2008-11-21 06:49:13 EST
NM_CONTROLLED=no should be changed to yes. 

Does it mean all users, who update from F-9 to F-10, will be suffering with this problem?
Comment 10 Bill Nottingham 2008-11-21 10:06:07 EST
No, settings should not change on upgrade.
Comment 11 Marcela Mašláňová 2008-11-21 10:30:07 EST
Then the users will be without network. Is it documented or in release notes?
Comment 12 Bill Nottingham 2008-11-21 11:06:32 EST
How will they be without it?  A configuration with:

- network disabled
- NetworkManager enabled
- NM_CONTROLLED=no

wouldn't work before upgrade either. And we don't change the state of either network or NetworkManager on upgrade.
Comment 13 Chris 2008-11-21 18:33:00 EST
This is a problem, definitely.  We can bicker back and forth, but truthfully, the NetworkManager is weak and the networking aspect of Fedora 9 is weak.  Even for solid cabled LAN, the network will stop working or something that uses the network will stop working, like "ping".

I have good example of how weak the Fedora 9 networking handling is.  I had some instances where I've been able use wget and a browser, no problem, running, but then immediately go to a shell and ping to my gateway would fail!  Now, ping and tracert, they should ALWAYS WORK, ALWAYS, LAW OF PHYSICS, if you have network connectivity and your firewalls are off and the routing is right.

How good can a Linux distro be if the frigging networking goes out of whack all the time, and changing all kinds of settings doesn't permanently fix it?

Now, about this specific issue of the network unavailable until a user logs in.  What were the developers thinking letting this happen, for any update!  Shame on you!  I mean, with this issue, how can you do serious configs with SSH?  Most of time, you need to do a reboot, right?  You reboot, and then, you can never connect to server again!  I think some of the Fedora Development Contributors need to be told to get a job with Microsoft.

Additionally, and I'll try to be short on this point: Fedora is screwing up with putting out stuff without firmly testing stuff.  And it's the backbone of RHLE!  This doesn't just apply to Fedora, either.  Many distro's are guilty of putting out updates everyday the majorly bust stuff.  Even Microsoft doesn't break systems as often!  Shame on the community.  Microsoft is going to win the server market, too, in the long run, if the Linux community doesn't get its act together about bad updates.  No one will ever trust the software!  Admins already don't update things regularly and wait and wait and research before they apply sometimes crucial security updates.  VERY BAD!

Oh, and last point.  Over all the modern Linux years, everyone touts how efficient Linux is compared to MS Windows.  How bloated the MS products are.  Well you know what?  Look in the mirror!  LOOK!  You have encouraged a product, in Fedora, that is much larger than typical MS XP installation footprint!  The last time I installed Fedora, with just the base things(no development, no extras, just the basics), it was like 4GB install.  Last time I installed Windows, basic options, it was 2.5 GB.

SHAME ON YOU!  SHAME ON YOU!  Linux will die and MS will win in the server market, if we all don't stand up and say, "Enough is enough.  Let's get this stuff cleaned up, fat off and running solid."

Please don't flame this comment or ask me to post configs.  You know what I say is true.  And immediately, we gotta do something about it so we don't have to live with these serious flaws of Fedora 10, cause they will be there!
Comment 14 Bill Nottingham 2008-11-24 14:38:59 EST
> Even
> for solid cabled LAN, the network will stop working or something that uses the
> network will stop working, like "ping".

Then please file bugs. That's unrelated to this specific bug.

> Please don't flame this comment

This was a comment? It sounds like a rant.

> or ask me to post configs.  You know what I say is true.

Actually, I don't. What I know is that there are reports of network not
working after install, and no one has actually posted configs that
point to a deficiency of NetworkManager - they point to the configuration
being written that *explicitliy disables it* (NM_CONTROLLED=no). Given that sort of configuration (which we don't write by default anywhere), NetworkManager is simply doing what it's told.

After doing some research, it appears to be a configuration issue - if you run system-config-network, it will by default write NM_CONTROLLED=no to the file, even though NM is active, without switching on the network service. End result is broken networking.
Comment 15 Bill Nottingham 2008-11-24 15:52:14 EST
Simplest fix would be to assume no NM_CONTROLLED entry to be NM_CONTROLLED=yes, and default that checkbox to on.
Comment 16 Dan Williams 2008-11-24 16:02:26 EST
(In reply to comment #15)
> Simplest fix would be to assume no NM_CONTROLLED entry to be NM_CONTROLLED=yes,
> and default that checkbox to on.

BUT: also store whether the ifcfg actually had NM_CONTROLLED in it on load, and don't write it out when the file gets saved unless the checkbox was toggled in the UI.  Thus, if the file didn't have NM_CONTROLLED in it originally, it wouldn't get NM_CONTROLLED=yes just because somebody ran s-c-n.
Comment 17 Bug Zapper 2008-11-25 23:05:57 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Jim Haynes 2008-12-17 13:15:16 EST
On my system, fresh install of Fedora 10, I used system->administration->network
to configure the Ethernet card with a fixed IP address.  The ifcfg-eth0
that resulted is quite a bit different from the one that was working in
Fedora 9.

3,4d2
< BOOTPROTO=none
< BROADCAST=192.168.1.255
6,10d3
< IPADDR=192.168.1.4
< IPV6INIT=no
< IPV6_AUTOCONF=yes
< NETMASK=255.255.255.0
< NETWORK=192.168.1.0
12,13c5,6
< NM_CONTROLLED=no
< TYPE=Ethernet
---
> BOOTPROTO=none
> IPADDR=192.168.1.4
16c9,11
< GATEWAY=192.168.1.4
---
> IPV6INIT=yes
> NM_CONTROLLED=yes
> TYPE=Ethernet

You see there is no NETMASK and no NETWORK in the one generated by the
F10 configurator.  (I tried with and without NetworkManager)

In fact when I enter the netmask  by editing in system->administration->network
it doesen't get written to the ifcfg file and the next time I look at it, it
has gone away.
Comment 19 Dan Williams 2008-12-17 13:57:46 EST
(In reply to comment #18)
> On my system, fresh install of Fedora 10, I used
> system->administration->network
> to configure the Ethernet card with a fixed IP address.  The ifcfg-eth0
> that resulted is quite a bit different from the one that was working in
> Fedora 9.
> 
> 3,4d2
> < BOOTPROTO=none
> < BROADCAST=192.168.1.255
> 6,10d3
> < IPADDR=192.168.1.4
> < IPV6INIT=no
> < IPV6_AUTOCONF=yes
> < NETMASK=255.255.255.0
> < NETWORK=192.168.1.0
> 12,13c5,6
> < NM_CONTROLLED=no
> < TYPE=Ethernet
> ---
> > BOOTPROTO=none
> > IPADDR=192.168.1.4
> 16c9,11
> < GATEWAY=192.168.1.4
> ---
> > IPV6INIT=yes
> > NM_CONTROLLED=yes
> > TYPE=Ethernet
> 
> You see there is no NETMASK and no NETWORK in the one generated by the
> F10 configurator.  (I tried with and without NetworkManager)
> 
> In fact when I enter the netmask  by editing in system->administration->network
> it doesen't get written to the ifcfg file and the next time I look at it, it
> has gone away.

Hmm. Lack of a netmask would be a problem, and thus make the connection information invalid.  I suppose NM could try to make up a netmask based on the class of the address, but classful addressing is deprecated and this would have the possibility of getting it wrong.  Perhaps there's a bug in system-config-network?  NM or any of it's components will *never* change or write out an ifcfg-* file, so it must have been either hand-edited, or modified by system-config-network.
Comment 20 Jim Haynes 2008-12-17 15:25:59 EST
Funny thing is, even with the defective ifcfg-eth0 file I can manually do
ifup eth0  and it somehow does the right thing with the netmask and broadcast
address.  But doesn't seem to work with trying to have it come up at boot time.

Anyway, it's pretty clear that system-config-network is throwing away the
netmask that I furnish.
Comment 21 Jim Haynes 2008-12-17 15:53:54 EST
Well, dang, now it is working OK at boot time even with the supposedly
defective ifcfg-eth0 file.  So it appears that not using NetworkManager
the startup script is smart enough to figure out the netmask and broadcast
address.  Still, it is anomalous that system-config-network asks for the
netmask but whatever you put in doesn't make it into ifcfg-eth0.
Comment 22 Jiri Moskovcak 2008-12-18 04:37:21 EST
system-config-network-1.5.95-1.fc10 has been submitted as an update for Fedora
10.
http://admin.fedoraproject.org/updates/system-config-network-1.5.95-1.fc10

Whoever is interested can help to test this updated version - it should fix the NETMASK problem and it has slightly improved NM compatibility (it acts almost as proposed in the Comment #16, but if you change smth and save it NM_CONTROLLED is written to the ifcfg-* file)
Comment 23 Volans 2009-01-13 05:35:47 EST
Having the same problem.

Each time I restart my PC, I need to go to system-config-network and enable the network device.....
Comment 24 Chad Paavola 2009-02-26 15:31:58 EST
I'm having this problem on a patched install of Fedora 10 on which I've removed NetworkManager.  The network service seems to be up and running, but eth0 is not activated at boot.

/etc/sysconfig/network-scripts/ifcfg-eth0 looks like this:

DEVICE=eth0
HWADDR=00:1c:c0:21:8a:11
ONBOOT=yes
SEARCH="arc.nasa.gov"
BOOTPROTO=none
USERCTL=no
IPV6INIT=no
NM_CONTROLLED=no
TYPE=Ethernet
NETMASK=255.255.252.0
IPADDR=143.232.116.114
GATEWAY=143.232.116.1
PEERDNS=yes

On startup network is disabled, I ran:
chkconfig --list network
and got:
network        	0:off	1:off	2:off	3:off	4:off	5:off	6:off

chkconfig --list NetworkManager
Returns:
error reading information on service NetworkManager: No such file or directory
(as expected, as it's been removed)

I tried:
/etc/init.d/network restart
That worked normally:
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]

I can also activate in system-config-network

Any ideas on what I can do about this?  I'm happy to provide additional information if needed.  Should I reinstall NetworkManager and try to run eth0 that way?
Comment 25 Bill Nottingham 2009-02-26 15:48:52 EST
Chad - you can solve your issue simply by enabling the network service.
Comment 26 Chad Paavola 2009-02-26 18:55:50 EST
Ha ha! How embarassing. I thought I had it enabled but I obviously didn't read the chkconfig output. It works perfectly now.

To summarize, my system works now because I removed NetworkManager:
(yum remove NetworkManager)

and used system-config-services to enable the "network" service.

Thanks Bill
Comment 27 Bug Zapper 2009-11-18 02:57:12 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Bug Zapper 2009-12-18 01:37:20 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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