From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625 Description of problem: Mkinitrd fails to include sata_sil and sd_mod modules in the new kernel when an upgrade is attempted from fc1 to fc3t1 on sata hardware. /etc/modules.conf is as follows: alias eth0 3c59x alias usb-controller usb-ohci alias usb-controller1 ehci-hcd alias ieee1394-controller ohci1394 alias sound-slot-0 i810_audio post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1 || : pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S >/dev/null 2>&1 || : # Note: for use under 2.6, changes must also be made to modprobe.conf! Version-Release number of selected component (if applicable): mkinitrd-3.5.24-1 How reproducible: Always Steps to Reproduce: 1. Install fc1 2. Install fc3t1 3. Actual Results: System won't boot, kernel panics trying to mount / filesystem. Expected Results: System boots with modules loaded Additional info: Workaround: boot single user off an old disk, and run: mkinitrd --with=sata_sil --with=sd_mod image kernelid
In general, kudzu handles the modules that change on a kernel upgrade but it's not catching changes of this sort. And I'm not really sure of a good way for it to do so :/
I've had the same issue. But I've looked at the code and if the install is not an upgrade, Kudzu will update modprobe.conf. Why not let Kudzu update modprobe.conf in case of an upgrade?
Yup, if modprobe.conf is updated by Kudzu BEFORE mkinitrd is run, there is no problem. Kudzu will detect the controller. Kudzu will now update modprobe.conf after the first reboot, but that's too late for the initrd.
Realistically, going from 2.4 to 2.6 needs a full new hardware detect as opposed to inheriting the old one..
fc4 lacked the module_upgrade call. As this needs to be run during the installation, this can't be fixed until FC4. (And its already done in latest builds)