From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1-0.1.9smp i686; en-US; 0.8)
When doing an rpm -i to install the new kernel-smp-2.4.1-0.1.9 (was at
kernel-smp-2.4.0-0.99.23), the post-install script call of
/usr/sbin/module_upgrade causes the system to hang. Real hard - complete
lock up, not even any kernel error messages logged.
Steps to Reproduce:
1.upgrade ancillary packages such as devfsd, kudzu, kernel headers and
source to the wolverine packages
2.Upgrade your kernel to kernel-smp-2.4.1-0.1.9 with rpm -ivv
Actual Results: Complete lock up, no error messages.
Expected Results: The kernel install should have finished.
After a couple trys at repeatign this bug and lots of fscking, I did a
--noscripts on the rpm install, manually made links, manually depmod'ed,
updated lilo.conf, and now things are happy. I didn't want my
/etc/modules.conf changed anyway.
Neat. If you run kudzu from the command line, does it also lock the system?
We (Red Hat) should really try to resolve this before next release.
All kudzu does that could cause this is load any (already configured):
- usb controller
- parallel port
None of these should hang the system. What does your /etc/sysconifg/hwconf
Created attachment 10880 [details]
Also, what does your /etc/modules.conf look like?
What happens if you load:
a) the aic7xxx module
b) the uhci module
c) the usb-uhci module
In answer to the questions - (thanks for being so fast guys!)
a) Running module_upgrade now does not crash the system. This is with the new
kernel all happily chugging away.
b) This system is scsi based, and does have usb and parallel ports (but nothing
running on the latter two). I have attached the /etc/sysconfig/hwconf
That said, I bet I know the answer - if module_upgrade was loading modules at
install time, and if it were trying to load the scsi driver from the old kernel
(aic7xxx from kernel-smp-2.4.0-0.99.23), then that module was known to lock up
the system at boot time at least - see bug #27993.
I had worked around this crash-on-boot bug by putting a working aic7xxx_old.o
driver into the initial ramdisk. But, module_upgrade would have know way of
knowing about that workaround.
If it _doesn't_ try to force a reload ofthe old modules when installing the new
kernel, then this answer is for not. In that case, let me know and I'll try to
back the system into the bug and play with things.
No, it was loading the previous aic7xxx module, so that would explain the
lockup. I'm going to mark this as closed, since that kernel issue is fixed
with the current kernel.
Also, there's really no reason for module_upgrade to be probing anything
other than the PCI bus at the moment, so we'll fix that in kudzu as well.