Bug 186355
Summary: | initscripts - some nasty change dooms alias addresses on network devices | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||||||||||
Component: | initscripts | Assignee: | Bill Nottingham <notting> | ||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> | ||||||||||||||
Severity: | medium | Docs Contact: | |||||||||||||||
Priority: | medium | ||||||||||||||||
Version: | rawhide | CC: | fedora, jarod, rvokal | ||||||||||||||
Target Milestone: | --- | ||||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | All | ||||||||||||||||
OS: | Linux | ||||||||||||||||
Whiteboard: | |||||||||||||||||
Fixed In Version: | 8.31.4-1 | Doc Type: | Bug Fix | ||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2006-08-06 12:43:00 UTC | Type: | --- | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Attachments: |
|
Description
Michal Jaegermann
2006-03-23 04:57:46 UTC
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 |