From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.1-0.1.9smp i686; en-US; 0.8) Gecko/20010215 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. Reproducible: Always 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 3. 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 - SCSI - parallel port modules. None of these should hang the system. What does your /etc/sysconifg/hwconf look like?
Created attachment 10880 [details] /etc/sysconfig/hwconf
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.