Bug 131358 – mkinitrd fails to include sata modules in upgrade from fc1 to fc3t1

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 131358 - mkinitrd fails to include sata modules in upgrade from fc1 to fc3t1

Summary:	mkinitrd fails to include sata modules in upgrade from fc1 to fc3t1

Status:	CLOSED NEXTRELEASE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	kernel (Show other bugs)
Sub Component:
Version:	3
Hardware:	i686 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Dave Jones
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2004-08-31 10:54 EDT by Patrick Caldon
Modified:	2015-01-04 17:09 EST (History)
CC List:	5 users (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-05-22 00:57:08 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Patrick Caldon 2004-08-31 10:54:51 EDT

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

Comment 1 Jeremy Katz 2004-08-31 11:39:15 EDT

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 :/

Comment 2 Mark Wormgoor 2004-10-14 10:29:30 EDT

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?

Comment 6 Mark Wormgoor 2005-05-17 01:58:45 EDT

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.

Comment 7 Arjan van de Ven 2005-05-17 02:55:45 EDT

Realistically, going from 2.4 to 2.6 needs a full new hardware detect as opposed
to inheriting the old one..

Comment 11 Dave Jones 2005-05-22 00:57:08 EDT

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)

Note You need to log in before you can comment on or make changes to this bug.