Fedora Account System
Red Hat Associate
Red Hat Customer
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.
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
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.
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
I have also ONBOOT=yes in both files.
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.
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.
NetworkManager is used by default - network is only on if manually enabled. It seems you had an install where that didn't happen?
In this case, let's switch this component back to NetworkManager, which isn't working for me at all.
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?
No, settings should not change on upgrade.
Then the users will be without network. Is it documented or in release notes?
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.
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!
> 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.
Simplest fix would be to assume no NM_CONTROLLED entry to be NM_CONTROLLED=yes, and default that checkbox to on.
(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.
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
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.
(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.
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.
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.
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)
Having the same problem. Each time I restart my PC, I need to go to system-config-network and enable the network device.....
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?
Chad - you can solve your issue simply by enabling the network service.
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
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
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.