Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Um. There's no information in this beyond the summary. Can you load the modules by hand? Did you upgrade to or from the kernels you mention in the summary? More info, please!
more info below upgrade the kernel via the up2date utility. The e1000 modude did not load while the system reboot. lsmod see the e1000_422???? module loaded on the system. rmmod e1000_422???? and reload the e1000. lsmod see the e1000 loaded on the system. Start the network. It work. Reboot the system the e1000 doesn't load. Please see the ticket 278922 on the support for more details. It is hard to lists every details here
I created bug 113234, which is exactly this problem, I also have the e1000 network interface as a loadable module. After the up2date process finished, including getting my new kernel, I had to do a depmod -ae and that solved my problem; I think "I think" means in this case that I saw one more blip of strange behavior from the interface after this but it has been working normally since then, even after a reboot. However, I am skeptical, wondering if some other modules are not loading right, some other problem will show up down the line that is ultimately caused by this "incomplete" kernel upgrade......
*** Bug 113234 has been marked as a duplicate of this bug. ***
This is a pretty major problem for folks that remotely manage their machines. When you upgrade a kernel and reboot the box, the expectation is that, if the drivers loaded before the upgrade, they will load after the upgrade. That is broken here, and could cause folks to loose communication with remote machines, because a driver that was working all of a sudden stops for no good reason.
yup all these bugs are related. we've got a whole slew now. As far afaict the problem is the the modules.dep file shows a dependency of e1000 on a previous e1000 driver. However, when depmod is re-run, as mentioned above the dependency disappears. The workaround is simply to re-run depmod, remove modules.dep (its created on boot), or simply remove the dependency from the file. There should be no furhter concerns. the question is why is depmod apparently producing different results?
I was wondering if there is going to be a new kernel package released to address this. We still hvae quite a few remote offices that have not been updated to the latest kernel release due to this problem. Thanks, Craig Dawson
yes, very shortly.
a preview can be grabbed at: http://people.redhat.com/~jbaron/.private/stable/2.4.9-e.37/
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2004-044.html
*** Bug 113640 has been marked as a duplicate of this bug. ***
The new kernel did not fix this problem for me. I was trying to go from 2.4.9-e.30 to 2.4.9-e.37. After upgrading the kernel, the e1000 module was not loaded.
hmmm, that is surprising. does 'modprobe e1000' work? Can i see the output of: 'grep e1000 /lib/modules/2.4.9-e.37/modules.dep'? also, what does /etc/modules.conf look like? thanks.
Well, I used autoupdate to update the packages the first time. I tried it again using up2date and it is working. I guess this is my problem now, since autoupdate does not seem to be doing the right thing. Thanks, Craig
glad to hear that the issue is resovled.