Bug 207661 - "loopback" DEVICETYPE is missing = problem with ifcfg-lo-XX (dash separator)
"loopback" DEVICETYPE is missing = problem with ifcfg-lo-XX (dash separator)
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: initscripts (Show other bugs)
4.4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-22 07:43 EDT by Martin (calim)
Modified: 2014-03-16 23:02 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-26 14:10:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin (calim) 2006-09-22 07:43:50 EDT
Description of problem:

copying ifcfg-lo to ifcfg-lo-1 (with ONBOOT=yes) is not mounted with "service
network restart". But it works if you pass it to ifup/down explicitly (like ifup
lo-1). if you name it "ifcfg-lo:1" it works.

In another hand, copying ifcfg-eth0 to ifcfg-eth0-1 (with ONBOOT=yes) is mounted
OK with "service network restart", but ifcfg-eth0:1 is NOT ok !


I think it comes from a bug in functions file,
"/etc/sysconfig/network-scripts/network-functions", in it there is a "case"
statement with no "lo" DEVICETYPE. There is no fallback case.

Version-Release number of selected component (if applicable):

Centos 4.4

How reproducible:

anytime copying ifcfg-lo to ifcfg-lo-1 with ONBOOT=yes IPADDR=someipaddress and
ask for "service network restart".

See description.

Steps to Reproduce:
1.
2.
3.
  
Actual results:
loopback aliases is not mounted

Expected results:
loopback to mount with the name convention "ifcfg-<interfacename>-<aliasnumber>
or just fix the name convention ! (because share/doc/initscript/sysconfig.txt is
not reflecting the current behaviour...)

Additional info:
Comment 1 Bill Nottingham 2006-09-22 12:39:46 EDT
Aliases are delimited with ':', not '-' - what are you tryng to do?
Comment 2 Martin (calim) 2006-09-22 13:04:38 EDT
Hi !

Read closer : "In another hand, copying ifcfg-eth0 to ifcfg-eth0-1 (with
ONBOOT=yes) is mounted OK with "service network restart", but ifcfg-eth0:1 is
NOT ok !"

What i am trying to explain is, for ethernet aliases, separator ":" (like in
ifcfg-eth0:1) just doesn't work, BUT it works with loopback aliases (like
ifcfg-lo:1) !
So finally, for loopback device, you have to name "ifcfg-lo:1" and for ethernet
"ifcfg-eth0-1". Otherwise, it doesn't work with /etc/init.d/network
start|stop|restart.

I hope it'll be more clear :O
Comment 3 Bill Nottingham 2006-09-22 14:38:31 EDT
ONBOOT=yes is not valid for aliases; for that, ONPARENT=yes/no is used.

That being said, I've not had any reports of aliases failing to come up; do you
get any errors at all?
Comment 4 Martin (calim) 2006-09-23 07:02:32 EDT
As ONPARENT is "yes" by default. That's a fact : the problem is fully
reproductible the way i've described.
Maybe poeple just deal with the problem by renaming their loopback ifcfg files
like i've explained - without reporting ? Or maybe a minority of poeple use ip
aliasing on loopback ?
Comment 5 Bill Nottingham 2006-09-25 12:40:44 EDT
I'm still not sure what you're trying; ifcfg-lo-1 is an *invald* loopback alias;
whether or not it should be brought up on 'service network restart' as a
separate device is another issue.

So, your first comment is that ifcfg-lo-1 doesn't work as an alias (which is
expected) and that ifcfg-eth0:1 doesn't work (which is unexpected). That's the
one I'm concerned about - what errors do you get?
Comment 6 Martin (calim) 2006-09-26 05:30:14 EDT
> So, your first comment is that ifcfg-lo-1 doesn't work as an alias (which is
> expected) and that ifcfg-eth0:1 doesn't work (which is unexpected). That's the
> one I'm concerned about - what errors do you get?

Exactly. That was the case, and for any reason after one reboot it works with
ifcfg-eth0:1 and ifcfg-lo:1.

Anyway, i can't explain why ifcfg-eth0-1 works and ifcfg-lo-1 don't, whereas  
nothing else than eth0:1 and lo:1 should work ? :

Here it is the fresh configuration:

[root@localhost network-scripts]# cat /etc/redhat-release
CentOS release 4.4 (Final)
[root@localhost network-scripts]# ls ifcfg-*
ifcfg-eth0  ifcfg-eth1  ifcfg-lo
[root@localhost network-scripts]# cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:48:54:6F:6A:E2
ONBOOT=yes
TYPE=Ethernet
[root@localhost network-scripts]# cat ifcfg-lo
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
[root@localhost network-scripts]# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Setting network parameters:                                [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]
[root@localhost network-scripts]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:48:54:6f:6a:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.82/24 brd 192.168.2.255 scope global eth0
    inet6 fe80::248:54ff:fe6f:6ae2/64 scope link
       valid_lft forever preferred_lft forever
(...)

Now i add files eth0-1 and lo-1 (which is intended to be not valid):

[root@localhost network-scripts]# cat ifcfg-eth0-1
DEVICE=eth0:1
BOOTPROTO=static
IPADDR=192.168.5.5
ONBOOT=yes
TYPE=Ethernet

[root@localhost network-scripts]# cat ifcfg-lo-1
DEVICE=lo:1
IPADDR=12.12.12.12
ONBOOT=yes
NAME=loopback

[root@localhost network-scripts]# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Setting network parameters:                                [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]
Bringing up interface eth0-1:                              [  OK  ]

Notice , it show "Bringing up interface eth0-1:"

[root@localhost network-scripts]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:48:54:6f:6a:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.82/24 brd 192.168.2.255 scope global eth0
    inet 192.168.5.5/24 brd 192.168.5.255 scope global eth0:1
    inet6 fe80::248:54ff:fe6f:6ae2/64 scope link
       valid_lft forever preferred_lft forever

=> eth0 alias is OK, lo alias NO OK.

now, i move filenames eth0-1 and lo-1 to eth0:1 and lo:1 :

[root@localhost network-scripts]# ll ifcfg-*
-rw-r--r--  1 root root  77 Sep 26 11:09 ifcfg-eth0
-rw-r--r--  1 root root  75 Sep 26 11:22 ifcfg-eth0:1
-rw-r--r--  1 root root  61 Sep 22 10:06 ifcfg-eth1
-rw-r--r--  1 root root 254 Jun 21  2001 ifcfg-lo
-rw-r--r--  1 root root  56 Sep 26 11:22 ifcfg-lo:1

[root@localhost network-scripts]# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Setting network parameters:                                [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:                                [  OK  ]

[root@localhost network-scripts]#  ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet 12.12.12.12/8 brd 12.255.255.255 scope global lo:1
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:48:54:6f:6a:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.82/24 brd 192.168.2.255 scope global eth0
    inet 192.168.5.5/24 brd 192.168.5.255 scope global eth0:1
    inet6 fe80::248:54ff:fe6f:6ae2/64 scope link
       valid_lft forever preferred_lft forever

Results are OK. Notice that we don't see that some aliases are mounted while
"network restart".

What do you think ?
Why if "-" is not a valid separator, it works for eth0-1 ?
Why aliases are not showed up by network restart ?
Comment 7 Bill Nottingham 2006-09-26 14:10:43 EDT
OK, so you're only changing the filenames, and not the contents; that's probably
some of the confusion.

So, for any alias, you will not get a 'Bringing up interface' line - aliases are
added separately.

The reason you got it in the ifcfg-eth0-1 case is that it parsed the *filename*
as pertaining to a separate interface named eth0-1, so /etc/init.d/network ran
'ifup eth0-1' (which then managed to work to bring up the alias.)

I think the answer is that at least for aliases, if the device is ethX:Y, the
file needs to be named ifcfg-ethX:Y.

As this is essentially a configuration issue, closing as not-a-bug.
Comment 8 Martin (calim) 2006-09-26 18:27:47 EDT
admit it's confusing.
you name ifcfg-eth0-1 and it brings up your alias (you think "cool!"), and one
day you name an loopback alias ifcfg-lo-1, one day the server reboot and you
don't see it mounted ?

Seriously, i think it can be more clear. Like for example make "ifcfg-eth0-1"
NOT mountable, like for "ifcfg-lo-1".

And if one day i've called it "ifcfg-eth0-1", it's because i ever had a problem
with "ifcfg-eth0:1" : shame on me, i can reproduce it today.

I agree it's not a bug, but it's a good way to confuse the user.
You can answer that "you should know it", but i don't think it's the way you
want it ! :)

Thank you anyway. My advice is to make it clearer.

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