Bug 186355 - initscripts - some nasty change dooms alias addresses on network devices
Summary: initscripts - some nasty change dooms alias addresses on network devices
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-03-23 04:57 UTC by Michal Jaegermann
Modified: 2014-03-17 02:59 UTC (History)
3 users (show)

Fixed In Version: 8.31.4-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-08-06 12:43:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
a network configuration file (81 bytes, text/plain)
2006-03-23 22:13 UTC, Michal Jaegermann
no flags Details
ifcfg-eth0:0 (83 bytes, text/plain)
2006-03-23 22:14 UTC, Michal Jaegermann
no flags Details
ifcfg-eth1 - this one actually is used on boot (112 bytes, text/plain)
2006-03-23 22:15 UTC, Michal Jaegermann
no flags Details
ifcfg-eth1:0 (256 bytes, text/plain)
2006-03-23 22:16 UTC, Michal Jaegermann
no flags Details
thl's config for eth1 (246 bytes, text/plain)
2006-03-24 21:55 UTC, Thorsten Leemhuis
no flags Details
thl's config for eth1:1 (264 bytes, text/plain)
2006-03-24 21:56 UTC, Thorsten Leemhuis
no flags Details

Description Michal Jaegermann 2006-03-23 04:57:46 UTC
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

Comment 1 Bill Nottingham 2006-03-23 17:13:20 UTC
can you attach all your ifcfg files for reference?

Comment 2 Michal Jaegermann 2006-03-23 22:13:25 UTC
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.

Comment 3 Michal Jaegermann 2006-03-23 22:14:53 UTC
Created attachment 126578 [details]
ifcfg-eth0:0

Comment 4 Michal Jaegermann 2006-03-23 22:16:00 UTC
Created attachment 126579 [details]
ifcfg-eth1 - this one actually is used on boot

Comment 5 Michal Jaegermann 2006-03-23 22:16:34 UTC
Created attachment 126580 [details]
ifcfg-eth1:0

Comment 6 Thorsten Leemhuis 2006-03-24 21:03:07 UTC
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)

Comment 7 Thorsten Leemhuis 2006-03-24 21:54:15 UTC
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.

Comment 8 Thorsten Leemhuis 2006-03-24 21:55:48 UTC
Created attachment 126670 [details]
thl's config for eth1

Comment 9 Thorsten Leemhuis 2006-03-24 21:56:39 UTC
Created attachment 126671 [details]
thl's config for eth1:1

Comment 10 Bill Nottingham 2006-06-30 19:49:44 UTC
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?

Comment 11 Michal Jaegermann 2006-06-30 21:38:34 UTC
> 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.

Comment 12 Bill Nottingham 2006-06-30 21:42:04 UTC
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.

Comment 13 Bill Nottingham 2006-06-30 21:43:56 UTC
Bug filed as 197401.

Comment 14 Michal Jaegermann 2006-07-01 00:29:43 UTC
> 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.

Comment 15 Bill Nottingham 2006-07-01 02:48:24 UTC
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.

Comment 16 Thorsten Leemhuis 2006-07-01 13:09:05 UTC
(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.

Comment 17 Bill Nottingham 2006-07-05 17:42:39 UTC
8.31.4-1 should be in updates-testing now, FWIW.

Comment 18 Thorsten Leemhuis 2006-08-06 12:43:00 UTC
Was fixed afaics


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