Bug 224378

Summary: network not started: driver module changed
Product: [openSUSE] openSUSE 10.2 Reporter: Vinay Khaitan <vkhaitan>
Component: YaST2Assignee: Michal Zugec <mzugec>
Status: RESOLVED FIXED QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: kkaempf
Version: RC 1   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: boot.msg
messages log
save_y2logs as requested
/etc/sysconfig/network/*
/etc/sysconfig/hardware/*

Description Vinay Khaitan 2006-11-29 02:37:45 UTC
eth0 network is not started by default when booting up. I had upgraded from beta1 to RC1. when I start yast2 network module, it starts the network when finished. So there should not be any system problem. However, netowrk is not started in booting time.
Comment 1 Matej Horvath 2006-11-29 13:11:30 UTC
Please attach your yast log files (http://en.opensuse.org/Bugs/YaST), the /var/log/messages, boot.msg and boot.log . 

Thank you. 
Comment 2 Vinay Khaitan 2006-11-29 13:27:11 UTC
Created attachment 107378 [details]
boot.msg
Comment 3 Vinay Khaitan 2006-11-29 13:29:50 UTC
Created attachment 107379 [details]
messages log
Comment 4 Vinay Khaitan 2006-11-29 13:30:18 UTC
boot.log is empty.
Comment 5 Matej Horvath 2006-11-30 12:58:08 UTC
Thank you. Please post also your yast logs. You can do that easily by running this command 'save_y2logs /tmp/y2logs.tgz' as root. Then in the /tmp you will find the y2logs.tgz. 
Comment 6 Vinay Khaitan 2006-11-30 13:16:10 UTC
Created attachment 107613 [details]
save_y2logs as requested
Comment 7 Michal Zugec 2006-12-08 18:01:57 UTC
please attach also /etc/sysconfig/hardware/* and /etc/sysconfig/network/ifcfg-eth*
files
Comment 8 Vinay Khaitan 2006-12-11 18:43:25 UTC
Created attachment 109205 [details]
/etc/sysconfig/network/*
Comment 9 Vinay Khaitan 2006-12-11 18:44:06 UTC
Created attachment 109206 [details]
/etc/sysconfig/hardware/*
Comment 10 Michal Zugec 2006-12-12 09:25:04 UTC
that files seems ok
is network service enabled?
/sbin/chkconfig |grep network
Comment 11 Vinay Khaitan 2006-12-13 04:20:32 UTC
yes, network service enabled. that command says "network on".
One more thing, I have upgraded to 10.2 GM and problem is still the same.
Comment 12 Michal Zugec 2006-12-13 09:50:33 UTC
yast part seems to be ok
also network/ifcfg-eth-id-00\:10\:25\:48\:97\:87
has STARTMODE='auto'
and _nm_name='bus-pci-0000:03:00.0'
where in hardware/hwcfg-bus-pci-0000\:03\:00.0
is MODULE='r1000' with STARTMODE='auto'

Christian any idea?
Comment 13 Christian Zoz 2006-12-15 15:10:19 UTC
Vinay, please boot without any workarounds for your problem. After booting open a root shell and type
  ip a
Is there a network interface with that (00:10:25:48:97:87) MAC-address?

a) if no (that's what i expect): Is the module r1000 loaded?
   aa) if again no: load the module r1000 manually ('modprobe r1000').
       Then test if the interface is set up properly (should be done
       automatically).
   ab) ... (i don't expect this)

b) if yes: Is the interface set up properly? Are there files
   "/dev/shm/sysconfig/*<interface_name>"? What do these contain?
Comment 14 Vinay Khaitan 2006-12-15 17:13:13 UTC
First question: No
a) module r1000 not loaded.
I am pasting a session here. It is from root account.

vkhaitan@ishwar:~> ip a
1: lo: <LOOPBACK,UP,10000> 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 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: sit0: <NOARP> mtu 1480 qdisc noop
    link/sit 0.0.0.0 brd 0.0.0.0
vkhaitan@ishwar:~> lsmod | grep r1000
vkhaitan@ishwar:~> sux -
ishwar:~ # lsmod | grep r1
ishwar:~ # modprobe r1000
FATAL: Module r1000 not found.
ishwar:~ # find /lib | grep r1000
/lib/modules/2.6.18.1-7-default/kernel/drivers/net/r1000.ko
ishwar:~ # depmod -a
ishwar:~ # modprobe r1000
FATAL: Module r1000 not found.
ishwar:~ # insmod r1000
insmod: can't read 'r1000': No such file or directory
ishwar:~ #
Comment 15 Vinay Khaitan 2006-12-15 17:21:15 UTC
I got it. It is because the current kernel version used is 2.6.18.2-34-default. hence the older version r1000 would not work.

Second thing, the driver used for networking by yast is r8169. both module provides access to network. So correct module to load is perhaps r8169. But it is not loaded by default. Provide me the solution then, why yast doesn't write it as default module to load when it uses it to enable networking.
Comment 16 Vinay Khaitan 2006-12-16 12:38:06 UTC
I solved the problem for myself. In the "hardware details" in network devices, I changed r1000 to r8169. The question now is that Why does yast doesn't write r8169 as module to be used for networking when it uses that module itself, when it searches for correct module, which works.

So, for you, the bug in yast is that, write down the module configuration when it uses it.
Comment 17 Michal Zugec 2006-12-17 09:16:06 UTC
Thanks Christian,
I'll take is.
This is known issue, in fact it's a duplicate, but now I'am on vacation,
so it takes some time until I fix it
Comment 18 Michal Zugec 2007-02-27 10:26:27 UTC
Vinay, could you check it in last openSUSE version?
I fix it already but forgot to mark this bug as a duplicate
Comment 19 Vinay Khaitan 2007-02-27 12:35:08 UTC
Actually this bug persisted in opensuse 10.2 version. I dont know about 10.3 alpha versions though.
Comment 20 Michal Zugec 2007-02-28 12:19:42 UTC
>> I solved the problem for myself. In the "hardware details" in network devices,
>> I changed r1000 to r8169. The question now is that Why does yast doesn't write
>> r8169 as module to be used for networking when it uses that module itself, when
>> it searches for correct module, which works.

Sorry, forget my last comment.
Kernel maintainers: this bug is related to you (and probably WONTFIX). 
When kernel module is replaced by any other module (or just dropped) there is no mechanism to handle this (for example I can write module names into every sysconfig/* files, modprobe.* or /etc/pm/* or elsewhere).
Comment 21 Greg Kroah-Hartman 2007-03-01 00:36:00 UTC
This is not a kernel issue, but an installer issue...
Comment 22 Jiří Suchomel 2007-03-02 11:35:53 UTC
How could installer know that kernel replaced a module with a new version?
IMHO this must be handled in kernel rpm scripts...
Comment 23 Martin Vidner 2007-03-02 12:20:05 UTC
(In reply to comment #21)
> This is not a kernel issue, but an installer issue...

No, this is an issue of both. What will we do with dropped drivers between SLE10 and SLE11? IMO kernel maintainers should make it transparent or generate an obsoletion list for yast to use.
Comment 24 Greg Kroah-Hartman 2007-03-08 01:33:51 UTC
How has yast handled this in the past when hardware support has moved from one module to another?

Can't you just use the lookup tables that the kernel provides to determine this information?
Comment 25 Martin Vidner 2007-03-08 08:34:50 UTC
I think that we did not handle it at all. At least I am not aware.

> Can't you just use the lookup tables that the kernel provides to determine
> this information?

Probably yes, but we don't even know that something like that exists. Pointers to some docs, please.

Well, we should not make it too much intelligent, but perhaps we can create some improvement.
Comment 26 Karsten Keil 2007-03-16 20:42:21 UTC
I spoke with Klaus about this and he agree that you should use hwinfo to verify that the driver still is the same or if it got changed. This would not need any special effort. 
Comment 27 Karsten Keil 2007-03-16 20:58:02 UTC
OK, a little more exactely:
if a driver name is in the config file (which should not be the default, only special cases need this, e.g multiple driver for the same HW), you should verify in the update case that the driver still exist. If not use the driver from hwinfo.
Comment 28 Michal Zugec 2007-05-11 15:32:06 UTC
Nice idea, I will do that
Comment 29 Michal Zugec 2007-06-18 15:30:38 UTC
No, better idea is to leave that to kernel.
For 10.3 there is no hwcfg file if module is autoloaded by kernel using modules.alias file