udev captures the modules "coldplugged" by the system (usually USB and Firewire) and this gets added to the list in INITRD_MODULES for the initrd. INITRD_MODULES is basically the list of modules that *has* to be loaded to get to mount the disk that udev is on (plus anything else you care to add). This is usually exactly your libata driver and your root filesystem module (on my system, "pata_mpc52xx xfs", on my Pegasos, "pata_via", on my VirtualBox systems, "ahci")
That was not the case. INITRD_MODULES was not containing the expected information
It doesn't get updated when you run mkinitrd - what I meant was, INITRD_MODULES is taken, then udev is poked to give up a list of loaded modules, which gets combined and passed to mkinitrd. INITRD_MODULES is fairly static as far as I have ever seen.. nothing has ever automatically updated it. The sole purpose of INITRD_MODULES is to load in drivers which CANNOT be coldplugged by udev because they have to be loaded to get to udev in the first place. Since udev can't know about them it can't be relied on to suggest them. There is no way to stop udev from doing this except to blacklist the driver from loading, and then udev won't bother (since it's not loaded at the time of mkinitrd, it will not add it to the list of coldplugged devices). If a broken driver is still being loaded, brokenmodules= on the kernel command line is your first step.
If INITRD_MODULES was working like that, as it used to pre-11.1 I don't think I'd have had an issue. It would have been a simple edit, and re-run mkinitrd.
Which works fine here. I don't see it on MY systems :D
The "problem" with adding stuff to the initrd is, is not a problem at all. Apart from the fact that INITRD_MODULES is generated during the install? If it installed the wrong driver (via82cxxx for example) for the disk then it glues that in there and it's not that easy to get it to automatically fix it.
It's actually removing things, as well as adding what you actually want, that appears necessary. As it stood, running mkinitrd by default updates for all kernels and initrd, which can caused the system to become unbootable, when attempting to force usage of the pdc202xx_old driver.
brokenmodules=pdc202xx_old, remove it from INITRD_MODULES if it's there, and blacklist it in /etc/modprobe.d/blacklist, then rebewt.. that's the real failsafe way (that way it can never be loaded from the initrd, it will never be put in the initrd next time it's built because neither the initrd init nor udev will load it, and if you ever try, modprobe is going to whine at you). Now make a new initrd and check it and rebewt again. Once you have a working initrd without it, and once you have it blacklisted from modprobe, you can remove the brokenmodules= line. It would be nicer to consolidate the stuff, that's for sure. There are no such problems with this stuff on FreeBSD etc. where the development is far more strict around kernel development. -- Matt Sealey <matt@genesi-usa.com> Genesi, Manager, Developer Relations -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org