Description of problem: I happen to have a bit unusual layout of network devices with configuration data in ifcfg-eth0, ifcfg-eth0:0, ifcfg-eth1, ifcfg-eth1:0 where actually active on boot is only eth1 and that one is on DHCP. Other addresses are all static. After the latest initscripts update an attempt to bring up a network ends up with things of that sort: ifup eth1 SIOCGIFXQLEN: No such device SIOCGIFXQLEN: No such device SIOCGIFXQLEN: No such device SIOCGIFXQLEN: No such device Error for wireless request "Set Encode" (8B2A) : SET failed on device eth1 ; No such device. Determining IP information for eth1...SIOCSIFADDR: No such device eth1: unknown interface: No such device eth1: unknown interface: No such device failed. The reason why I think that this is initscript fault is that before they were updated there was no problem. Also if I will _hide_ all 'ifcfg*' files and later bring interfaces manually in a right order then there is no trouble. The whole networking can be configured as previously - aliases and all. When trying to trace what shell is doing I see fragments like that: + REALDEVICE=eth1 + '[' eth1 '!=' eth1 ']' + ISALIAS=no + '[' -n 00:02:b3:a3:60:e4 ']' ++ echo 00:02:b3:a3:60:e4 ++ awk '{ print toupper($0) }' + HWADDR=00:02:B3:A3:60:E4 + '[' -n '' ']' + '[' '' = yes ']' + '[' dhcp = bootp -o dhcp = dhcp ']' + DYNCONFIG=true + is_available eth1 + LC_ALL= + LANG= + ip -o link SIOCGIFXQLEN: No such device and later ++ ip -o link SIOCGIFXQLEN: No such device ++ grep -v link/ieee802.11 ++ awk -F ': ' -vIGNORECASE=1 '/00:02:B3:A3:60:E4/ { print $2 }' + curdev=eth1:0 + '[' -n eth1:0 ']' + rename_device eth1 00:02:B3:A3:60:E4 eth1:0 + local target=eth1:0 + /sbin/ip link set eth1:0 name eth1 with 'rename_device' a clear misunderstanding. This device does exist and I am even communicating through it right now after a configured it myself. Unfortunately I do not have the previous version of initscripts to check what change caused all this. I would suspect some quoting as also "hiding" files ifcfg-eth0:0 and ifcfg-eth1:0 is "fixing" the issue too. Version-Release number of selected component (if applicable): initscripts-8.31.2-1 How reproducible: always
can you attach all your ifcfg files for reference?
Created attachment 126577 [details] a network configuration file Sure, I can attach these. But I think that the trouble is that names are messing up new version of script and not that there is something funny with a content.
Created attachment 126578 [details] ifcfg-eth0:0
Created attachment 126579 [details] ifcfg-eth1 - this one actually is used on boot
Created attachment 126580 [details] ifcfg-eth1:0
Saw this also with the initscripts from updates testing (0:8.31.2-1); the version from FC5 (8.31.1-1) works fine. I also have alias devices (eth2:1). (thl)
Okay, I looked a little bit closer. The alias device seems to be the troublemaker. Some details about the hardware fist: eth0: ipw2200, not configured eth1: b44, dhcp I reconfgigured the network settings completely from scratch with neat. With the old initscripts everything works as expected. With the new one from updates testing: Only eth1 configured with dhcp -> works fine Adding eth1:1 with a static ip (needed for VPN) and rebooting afterwards -> boom. Already "lo" won't get configured and will complain during startup with: SIOCGIFXQLEN: No such device SIOCGIFXQLEN: No such device eth1:1: error fetching interface information: Device not found Same error happens when trying to bring up eth1 when eth1:1 is configured.
Created attachment 126670 [details] thl's config for eth1
Created attachment 126671 [details] thl's config for eth1:1
Apologies for the delay. Michal - what happens if you add the hwaddr for the device to ifcfg-eth0, and remove it from ifcfg-eth1:1? Similarly, Thorsten - what happens if you remove the HWADDR from ifcfg-eth1:1?
> what happens if you add the hwaddr for the > device to ifcfg-eth0, and remove it from ifcfg-eth1:1? If I have HWADDR set for all "primaries" and it is absent for all "aliases" then indeed everything can be configured like before changes in question. Two issues though. Once you have seen this SIOCGIFXQLEN then it looks like that you cannot recover by changing ifcfg-eth* files and doing 'service network restart'. Apparently a device named 'eth1:0' was created and I could not find a way to remove it or rename save a reboot. It appears that this line from a configuration run: rename_device eth1 00:02:B3:A3:60:E4 eth1:0 tries to "recover" but fails. Is that ip which changed in a nasty way? The other is that all these configuration files were created one time or another with system-config-network and it was not enforcing, and I do not think that it is doing that now, any rules where HWADDR can and cannot be placed.
You can rename a device name only if it's not up. So if you end up with a wrong IP up, it might need some whacking and renaming by hand. I'll file a bug against s-c-n for HWADDR.
Bug filed as 197401.
> You can rename a device name only if it's not up. Well, yes, of course. But the problem is not that it is not up. After all its configuration failed so it is not up. The problem is that there is no apparent way to talk to it. This includes attempts to bring it down - whatever that may mean in the context. Also restricting how s-c-n does HWADDR in the future is not much help on already existing configurations in the field.
So, the reason that the device goes into wacky mode is a combination of userspace bugs (parsing /proc/net/dev and stopping at the first colon) and kernel bugs (it seems to respond to ioctls on eth1:1 with -ENODEV.) Looking at ways to avoid getting into this situation.
(In reply to comment #15) > Looking at ways to avoid getting into this situation. Bill, I saw your commits to core-CVS and build initscripts-8.31.4-1 for from initscripts/FC-5 for FC-5 locally -- works fine and fixes this bug for me.
8.31.4-1 should be in updates-testing now, FWIW.
Was fixed afaics