Description of problem: I used system-config-network to add a second IP address to my eth0, running on a server with the latest Fedora. The "activate" and "deactivate" buttons in this GUI are greyed out. Also, the new IP address is listed as "inactive". So I restart the network. I get: > service network restart Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: SIOCGIFADDR: Cannot assign requested address SIOCSIFBROADCAST: Cannot assign requested address SIOCSIFBRDADDR: Cannot assign requested address SIOCSIFFLAGS: Cannot assign requested address [ OK ] [root@csrv log]# system-config-network It seems that things are working (both IP addresses reach the server) although ifconfig reports just one entry for eth0, and it has the second (child?) address as it's IP address. Instead, I was expecting to see a listing for eth0:0 and eth0:1 or something. Version-Release number of selected component (if applicable): Linux csrv.econ.ubc.ca 2.6.27.25-170.2.72.fc10.x86_64 #1 SMP Sun Jun 21 18:39:34 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Here are some maybe relevant files: > cat ifcfg-eth0 # Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) DEVICE=eth0 BOOTPROTO=none HWADDR=00:15:17:82:dc:f0 ONBOOT=yes SEARCH="econ.ubc.ca" NETMASK=255.255.255.0 IPADDR=137.82.185.170 GATEWAY=137.82.0.1 TYPE=Ethernet USERCTL=no PEERDNS=yes IPV6INIT=no NM_CONTROLLED=yes DNS1=137.82.1.1 DNS2=142.103.1.1 DOMAIN='econ.ubc.ca ubc.ca' > cat ifcfg-eth0:1 # Please read /usr/share/doc/initscripts-*/sysconfig.txt # for the documentation of these parameters. GATEWAY=137.82.0.1 TYPE=Ethernet DEVICE=eth0:2 BOOTPROTO=none NETMASK=255.255.255.0 IPADDR=137.82.185.168 USERCTL=no PEERDNS=yes IPV6INIT=no ONPARENT=yes NM_CONTROLLED=yes > service network status Configured devices: lo eth0 Currently active devices: lo eth0 eth1 > ifconfig eth0 Link encap:Ethernet HWaddr 00:15:17:82:DC:F0 inet addr:137.82.185.168 Bcast:137.82.185.255 Mask:255.255.255.0 inet6 addr: fe80::215:17ff:fe82:dcf0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5336254 errors:0 dropped:0 overruns:0 frame:0 TX packets:4885391 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2228993254 (2.0 GiB) TX bytes:3388945589 (3.1 GiB) Memory:ba820000-ba840000 eth1 Link encap:Ethernet HWaddr 00:15:17:82:DC:F1 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Memory:ba800000-ba820000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3203461 errors:0 dropped:0 overruns:0 frame:0 TX packets:3203461 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1416457314 (1.3 GiB) TX bytes:1416457314 (1.3 GiB)
NM_CONTROLLED=yes controlled by Network-Manager should be off filename/devicename ifcfg-eth0:1 but you switched alias to :2 DEVICE=eth0:2
Thanks for the suggestions. I know this is not a help forum, and I should not have difficulty simply setting up a fixed IP network, but making your change of network-managed to off results in a disaster, in which there is absolutely no name service, ie cannot find any internet names, and in fact cannot even ping a machine by ip address "can't reach network", although the outside world can get in by name. SEcondly, I didn't switch the alias to ":2", so it looks like another bug. Changing this to ":1" makes no difference to anything I can observe, including the errors which initiated this bug report. Thanks, Chris
In addition, to focus on possible problems in either the functionality or interface, I believe I have done nothing but (1) set up the network during the installation and (2) run the system-config-network since then, so I should not have to edit these text files by hand, nor should I have to turn off or on the parallel network management thing. Is the problem due to my having two IP addresses on one device? To my having two wired devices, one of them (eth1) currently unused?
Actually you did a mistake - you forgot to uncheck "Controlled by NetworkManager" when you were creating the aliases - if you want to use the network service, you should switch NM off or you can try to set the fixed IP using NM and don't use s-c-n because s-c-n is for use with network service.
Thanks. I've followed the advice I can find, and I don't see details in the Fedora installation guide. Would you be so kind to point me to some documentation, if there is any, or a draft of it I could help with? I don't understand your concise advice and I suspect this isn't the place for it anyway. It still sounds like there are some serious usability issues here. Should "turning NM off" (I am not sure what that means) be done or suggested always if someone is using fixed IP? I'd be happy to report back if I could find some documentation to follow. thanks again
turnign NM off means "turning of the NetworkManager service" by running one of the following commands: $ service NetworkManager stop or if you want to do it permanently: $ chkconfig NetworkManager off You need to understand, that "NetworkManager" and "network" are two separate services with the same purpose - to control your network interfaces. system-config-network is designed to work with the "network" service, so every change you make using s-c-n will work only if you use "network" service instead of NetworkManager. You shouldn't use them both in the same time, because they will collide trying to set-up network interfaces. As for setting fixed IP - you can use nm-applet to setup fixed IP using NetworkManager service. Jirka
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.