Bug 114089

Summary:	in /etc/sysconfig/network the config ifcfg-eth0 is not converted in ifcfg-MAC
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Tim Ehlers <tim>
Component:	Network	Assignee:	Peter Poeml <poeml>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Beta 3
Target Milestone:	---
Hardware:	i386
OS:	SUSE Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Tim Ehlers 2005-08-30 10:57:07 UTC

After Update the previous configuration ifcfg-eth0, ifcfg-eth1 etc is not
converted into ifcfg-MAC.

Comment 1 Christian Zoz 2005-08-31 10:20:20 UTC

Update from what version?

There are cases where this is not possible to do that automatically.
For 10.0 you can keep ifcfg-ethN if you like. See my commnt in bug 114088.

Peter, we still should convert them, even if we have now persistent names,
because we don't know if names changed during update.

Comment 2 Peter Poeml 2005-08-31 16:14:54 UTC

At the moment I don't understand what the problem is; could you provide
logs please?
There are two log files in /etc/sysconfig/network/ after update.

Comment 3 Tim Ehlers 2005-08-31 16:58:06 UTC

Ok, ist was an update from 9.0 to 10.0 beta3. The problem has to do with bug
114088. The update Skript created hwcfg-static-0 to save the current order of
ethX-interfaces. But this file seems no longer to be used.

So in combination with the error, that the config ifcfg-eth0 etc is not
converted into ifcfg-eth-id-MAC it happend, that the previos order:
eth0 -> 3com (3c59x)
eth1, eth2(unused) -> dual-NIC Gigabit (e1000)

changed after install-reboot into:

eth0, eth1 -> e1000
eth2 -> 3c59x

and previos config for eth0 is now set up for Gigabit-NIC.

So Network was misconfigured after update and the computer wasn't reachable.








cat update-log

Updating etc/sysconfig/network
Backup copies of the original ifcfg files are saved in
/var/adm/backup/sysconfig-backup
processing modules.conf...
creating /etc/sysconfig/hardware/hwcfg-static-0

processing ifcfg-eth0...
found matching entry in hardware database, but card is currently unavailable

processing ifcfg-eth1...
found matching entry in hardware database, but card is currently unavailable

pass #1 done.

pass #2 done.

pass #3 done.

pass #4 done.

processing routes...

pass #5 done.




cat update-log.debug
Mon Aug 29 18:04:49 CEST 2005

-rw-r--r--  1 root root  141 Aug 22 19:24 ifcfg-lo
-rw-r--r--  1 root root  180 Dec 10  2003 ifcfg-eth0~
-rw-r--r--  1 root root  180 Jan 16  2004 ifcfg-eth0
-rw-r--r--  1 root root  183 Feb 11  2004 ifcfg-eth1
-rw-r--r--  1 root root 5779 Aug 22 19:24 ifcfg.template

valid files:
ifcfg-eth0
ifcfg-eth1

-rw-r--r--  1 root root  239 Aug 22 19:24 ifroute-lo

valid files:
routes

ls: /sys/class/net/eth0/driver: No such file or directory
lrwxrwxrwx  1 root root 0 Aug 29 18:04 /sys/class/net/eth0/device ->
../../../devices/pci0000:00/0000:00:1e.0/0000:02:08.0
ls: /sys/class/net/eth1/driver: No such file or directory
lrwxrwxrwx  1 root root 0 Aug 29 18:04 /sys/class/net/eth1/device ->
../../../devices/pci0000:00/0000:00:1e.0/0000:02:08.1
count of plain eth interfaces found: 2

found ../../modules.conf
configured network driver modules:

>>> begin modconf.Vx7861
    alias eth0 3c59x
    alias eth1 e1000
<<<

searching module options for 3c59x
searching module options for e1000

>>> begin modconf.Vx7861
    alias eth0 3c59x
    alias eth1 e1000
<<<

found 2 aliases
found 2 ethernet aliases
found 0 tr aliases
creating /etc/sysconfig/hardware/hwcfg-static-0

>>> begin ../hardware/hwcfg-static-0
    # This file has been created during sysconfig update for reasons of backward
    # compatibility. It is not necessary in the new sysconfig concept, and could
    # theoretically be deleted.
    #
    # It ensures that the drivers below are loaded in the same order as
    # before the system update, to make sure that the network interface names
    # are not changed on your system.

    STARTMODE='auto'

    MODULE_1='3c59x'
    MODULE_OPTIONS_1=''

    MODULE_2='e1000'
    MODULE_OPTIONS_2=''
<<<

processing ifcfg-eth0...

>>> begin ifcfg-eth0
    BOOTPROTO='static'
    BROADCAST='134.76.7.255'
    IPADDR='134.76.7.101'
    MTU=''
    NETMASK='255.255.254.0'
    NETWORK='134.76.6.0'
    REMOTE_IPADDR=''
    STARTMODE='onboot'
    UNIQUE='6Ogo.rbKoCKmo5xF'

    # Note: a fixed alias name association has been found during update in
    # your modules.conf file. To make sure that the interface names are
    # the same as before the update, a file
    #              /etc/sysconfig/hardware/hwcfg-static-0
    # has been created, which loads the network modules in a fixed order.
    # It is recommended to use the new ifcfg-eth-id-00:d0:b7:b2:9c:a3 style
    # configuration names and remove the file hwcfg-static-0 file.

<<<

wireless=false, interface_type=eth
found unique string: 6Ogo.rbKoCKmo5xF
+ 169: local i
+ 170: for i in '$*'
+ 171: test -e ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF
+ 172: echo

+ 173: echo '>>> begin ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF'
>>> begin ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF
+ 174: sed 's/^/    /' ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF
    [General]
    UniqueID=6Ogo.rbKoCKmo5xF
    ParentID=6NW+.eDbWAYN5SdB
    HWClass=network
    Model=Dell 3c905C-TX/TX-M [Tornado]

    [Status]
    Configured=yes
    Available=no
    Needed=no
    Active=unknown

    [Hardware]
    Bus=0x4
    Slot=0x20c
    BaseClass=0x2
    VendorID=10b7
    DeviceID=9200
    SubVendorID=1028
    SubDeviceID=010d
    RevisionID=0x78
    DeviceName=3c905C-TX/TX-M [Tornado]
    VendorName=3Com Corporation
    SubVendorName=Dell Computer Corporation
    HWClassList=000002200000
    Res.IO=0xdc80,0x80,1,3
    Res.Memory=0xff6ffc00,0x0,1,3,1
    Res.Memory=0xff700000,0x0,0,1,0
    Res.Interrupts=18,1494,1

+ 175: echo '<<<'
<<<
+ 176: echo

processing ifcfg-eth1...

>>> begin ifcfg-eth1
    BOOTPROTO='static'
    BROADCAST='192.168.0.255'
    IPADDR='192.168.0.101'
    MTU=''
    NETMASK='255.255.254.0'
    NETWORK='192.168.0.0'
    REMOTE_IPADDR=''
    STARTMODE='onboot'
    UNIQUE='6Ogo.rbKoCKmo5xF'

    # Note: a fixed alias name association has been found during update in
    # your modules.conf file. To make sure that the interface names are
    # the same as before the update, a file
    #              /etc/sysconfig/hardware/hwcfg-static-0
    # has been created, which loads the network modules in a fixed order.
    # It is recommended to use the new ifcfg-eth-id-00:d0:b7:b2:9c:a3 style
    # configuration names and remove the file hwcfg-static-0 file.

<<<

wireless=false, interface_type=eth
found unique string: 6Ogo.rbKoCKmo5xF
+ 169: local i
+ 170: for i in '$*'
+ 171: test -e ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF
+ 172: echo

+ 173: echo '>>> begin ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF'
>>> begin ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF
+ 174: sed 's/^/    /' ../../../var/lib/hardware/unique-keys/6Ogo.rbKoCKmo5xF
    [General]
    UniqueID=6Ogo.rbKoCKmo5xF
    ParentID=6NW+.eDbWAYN5SdB
    HWClass=network
    Model=Dell 3c905C-TX/TX-M [Tornado]

    [Status]
    Configured=yes
    Available=no
    Needed=no
    Active=unknown

    [Hardware]
    Bus=0x4
    Slot=0x20c
    BaseClass=0x2
    VendorID=10b7
    DeviceID=9200
    SubVendorID=1028
    SubDeviceID=010d
    RevisionID=0x78
    DeviceName=3c905C-TX/TX-M [Tornado]
    VendorName=3Com Corporation
    SubVendorName=Dell Computer Corporation
    HWClassList=000002200000
    Res.IO=0xdc80,0x80,1,3
    Res.Memory=0xff6ffc00,0x0,1,3,1
    Res.Memory=0xff700000,0x0,0,1,0
    Res.Interrupts=18,1494,1

+ 175: echo '<<<'
<<<
+ 176: echo

pass #1 done.
pass #2 done.
pass #3 done.
pass #4 done.
processing routes...

>>> begin routes
    default 134.76.7.254 - -
<<<

+ 63: test -x /usr/bin/diff
+ 64: /usr/bin/diff -u /var/adm/backup/sysconfig-backup/routes ifcfg.tO8025

pass #5 done.

Comment 4 Peter Poeml 2006-05-09 07:39:35 UTC

Hrm, I overlooked this bug. Tim, thanks for the information. FYI: after
providing the needed information you can set the bug back to 'assigned',
so it doesn't stay in 'needinfo'. 

Hm, what happens?

A description file about each hardware device is stored in
/var/lib/hardware/unique-keys. There are respective files for the NICs
as well. However, both files show that the devices where "Unavailable"
during the last scan of hwinfo/hwbootscan. 

The update script does look for that in the function
get_data_from_uuid(), unavailable devices are not handled in the way
that "available" devices are. Unavailable devices were seen as no longer
existing iirc. Consequently, the devpath lookup for the MAC ID is not
done for them.

When the system is configured with yast, without manual intervention,
this doesn't happen to my knowledge. I'm sorry, but there is not much
that we can do about such special cases I think. (I am one of the people
myself who edit ifcfg files by hand, so that the unique keys tend to
become wrong, so I know those problems)


There is a suspicious error message in the log... that's because the
update script does:
	ls -l /sys/class/net/$dev/device /sys/class/net/$dev/driver 2>&1 | debuglog
This path is no longer valid, it seems to have changed to
	/sys/class/net/$dev/device/driver 
with current kernels. Fixed that in svnBut this info is not used anyway. (Could it be
used?)

So this is going to be a wontfix.