Bugzilla – Bug 120959
initrd load specific kernel modue for standart ide controller (not SATA, not SCSI)
Last modified: 2006-04-07 10:04:04 UTC
It is impossible to change the motherboard having another chipset, because initrd doesn't use generic ide driver, but specific driver to IDE controller in southbridge of MB. It is specified right after installation. Unable to boot up. Really annoying. It is possible to change it in yast but what in the case the primal motherboard is damaged?
This is not a real usability issue but a technical problem and a feature request. If I understand correct, the system will not run correct with a new motherboard after a damage because the "former" drivers are used and will crash? You really will need a new installation because no generic drivers are loaded after a failure? This is &7$§")(7=ß! I think windows can handle this problem. Is this a kernel problem? Screening team -- please help.
Lets call it a feature request. > because the "former" drivers are used and will crash? Yes, kernel can't communicate with hdd, it writes to console something like: Cann't acces /dev/hda ... > You really will need a new installation because no generic drivers > are loaded after a failure? Yes, at least boot from installation CD and "repair installation" is needed. > This is &7$§")(7=ß! I think windows can handle this problem. I don't understand, but I agree with the second part. This "feature request" has Continue, please take a look at bug #120961 .
Can't you launch the system in "save mode" or select the drivers manually via linuxrc during the start?
Save mode didn't help. At the time kernel needed to communicate with hdd, it complained that "can't see /dev/hda". Modules from initrd are loaded firstly, aren't they?
From comment #1: > Is this a kernel problem? > Screening team -- please help. I think we came to the conclusion that this is rather an enhancement (because a defective controller that identifies itself correctly [and was used during the installation] but fails later... is not a software problem at all). This could probably be done with adding special menu-entries to the bootloader which would disable/enable certain mass-storage subsystems? Thorsten: Any clue?
If you would ask me (which you don't, unless you finally spell my name right), I'd counter where the problem is with loading a generic IDE driver module after the specialized one expected to work with the assumed chipset. It's clearly an installation feature request, to add a generic IDE driver to modules wrapped into the initrd.
In general we do _not_ do any automatic detection of any required device driver within mkinitrd. Sure we can add ide_generic to the list of modules loaded from initrd, but we simply cannot cover all possible cases from users replacing parts of their machine at random. They can as well boot up the rescue system, fix INITRD_MODULES, re-do the initrd and reboot. We can consider adding ide-generic for SL10.1; it definitely requires quite a bit of testing before we're doing in in general.
it's later now.
I don't think it's a good idea. We might well include the module in the initrd to have it available if the 'normal' module fails, but we certainly won't be loading it by default. Loading ide-generic by default would mean we _cannot_ load any IDE module later during boot. Bad idea. And come to think of it: udev might be tempted to load ide-generic during initrd run anyway. So we'll better leave it off.