|
Bugzilla – Full Text Bug Listing |
| Summary: | network not started: driver module changed | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.2 | Reporter: | Vinay Khaitan <vkhaitan> |
| Component: | YaST2 | Assignee: | 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
Please attach your yast log files (http://en.opensuse.org/Bugs/YaST), the /var/log/messages, boot.msg and boot.log . Thank you. Created attachment 107378 [details]
boot.msg
Created attachment 107379 [details]
messages log
boot.log is empty. 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. Created attachment 107613 [details]
save_y2logs as requested
please attach also /etc/sysconfig/hardware/* and /etc/sysconfig/network/ifcfg-eth* files Created attachment 109205 [details]
/etc/sysconfig/network/*
Created attachment 109206 [details]
/etc/sysconfig/hardware/*
that files seems ok is network service enabled? /sbin/chkconfig |grep network 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. 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? 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?
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:~ #
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. 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. 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 Vinay, could you check it in last openSUSE version? I fix it already but forgot to mark this bug as a duplicate Actually this bug persisted in opensuse 10.2 version. I dont know about 10.3 alpha versions though. >> 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).
This is not a kernel issue, but an installer issue... How could installer know that kernel replaced a module with a new version? IMHO this must be handled in kernel rpm scripts... (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. 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? 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.
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. 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. Nice idea, I will do that 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 |