|
Bugzilla – Full Text Bug Listing |
| Summary: | driver priority messed up due to missing modules.order | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Jozef Uhliarik <juhliarik> |
| Component: | Kernel | Assignee: | Michal Marek <mmarek> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Blocker | ||
| Priority: | P1 - Urgent | CC: | aj, antoine.mechelynck, aschnell, dimstar, lmedinas, lnussel, locilka, mario_vazq, matt, max, novell.admin, snwint, spielmit |
| Version: | Beta 4 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | logs from /var/log/YaST2 | ||
|
Description
Jozef Uhliarik
2008-11-04 09:48:50 UTC
First of all a update problem. Bad luck, already reported as bug #441378 (for that case) fstab is using scsi-SATA_VBOX_HARDDISK_VBb815939d-003517b2-partX for mounting but now those names do not exist anymore (it's ata-VBOX_HARDDISK_VBb815939d-003517b2-partX now). udev has to ensure that persistent device names are there. (In reply to comment #3 from Arvin Schnell) > fstab is using scsi-SATA_VBOX_HARDDISK_VBb815939d-003517b2-partX > for mounting but now those names do not exist anymore (it's > ata-VBOX_HARDDISK_VBb815939d-003517b2-partX now). > > udev has to ensure that persistent device names are there. Udev cannot ensure any scsi-* links for IDE disks. Why are you using an IDE driver? As far as I know udev loads the drivers in openSUSE 11.1. *** Bug 441466 has been marked as a duplicate of this bug. *** But it loads no ide drivers, ata have priority. What's in /etc/sysconfig/kernel? You had better ask the reporter... I'm not the one you asked but in my case which was marked as dup of this one (logs in bug 441466) I have: INITRD_MODULES="processor thermal piix pata_acpi ata_piix ata_generic ide_pci_generic fan jbd ext3 edd" I suppose the update injected the piix there and therefore has switched the system from libata to ide drivers. We must not load any IDE drivers. INITRD_MODULES="processor thermal piix pata_acpi ata_piix ata_generic ide_pci_generic fan jbd ext3 edd" breaks all sort of setups. See also https://bugzilla.novell.com/show_bug.cgi?id=441466 Kay, only udev loads modules. Looks like a sideeffect of bug 440986 to me. Come on, udev does _not_ load modules mentioned in INITRD_MODULES. They get loaded before udev even starts up. Some broken logic puts IDE modules in that variable, and that is for 100% sure not udev. I've seen the same broken stuff on my laptop with a new installation of beta4. (In reply to comment #13 from Kay Sievers) > I've seen the same broken stuff on my laptop with a new installation of beta4. And I only noticed it because my dvd was hda with the rebboted system. > Come on, udev does _not_ load modules mentioned in INITRD_MODULES.
No, but INITRD_MODULES lists (among others) the modules that udev *did* load
for the storage controller. And if I start an install in e.g. qemu udev
*does* load all those ide modules. And in exactly that order.
If you turn off udev module loading with linuxrc.debug=-udev.mods things
get back to normal.
(In reply to comment #15 from Steffen Winterfeldt) > > Come on, udev does _not_ load modules mentioned in INITRD_MODULES. > > No, but INITRD_MODULES lists (among others) the modules that udev *did* load > for the storage controller. No, modprobe loads drivers, udev just calls modprobe for _every_ device with a hardware modalias not a module name. There is not a single hardware->driver definition in udev. Btw, why does the installer copy all loaded storage modules into that variable? Modprobe, by current definition, always loads all matching drivers. Why isn't the installer picking only the one that is bound to the device? Seems the installer and udev have no idea what driver is to load for which device, so find someone else who to blame. :) Modprobe loads the modules, and modprobe relies on the kernel supplied modules.order file to prefer libata drivers. That file is missing in the kernel rpm. Reassign to kernel, to make sure modules.order is shipped. > Btw, why does the installer copy all loaded storage modules into that variable?
> Modprobe, by current definition, always loads all matching drivers. Why isn't
> the installer picking only the one that is bound to the device?
A good point. I'll probably have to change that.
Anyway, we need to get modules.order back first.
Let's assign to Michal. Michal, we need modules.order to not have random hdX partitions instead of sdX. Increasing Priority (AJ speaking for openSUSE core team) (In reply to comment #17 from Kay Sievers) > Modprobe loads the modules, and modprobe relies on the kernel supplied > modules.order file to prefer libata drivers. I don't see any mention of modules.order neither in upstream module-init-tools-3.5 nor in ours. Tejun, you wrote the patch adding modules.order - where can I find the depmod part? It's in the kernel rpm. Or rather it WOULD be if it wouldn't be deleted. (In reply to comment #23 from Steffen Winterfeldt) > It's in the kernel rpm. Or rather it WOULD be if it wouldn't be deleted. That's the easy part - but where is the file really used? It's used by depmod to sort the module list. It's not upstream yet? http://thread.gmane.org/gmane.linux.kernel/611212/focus=619667 I'll check the CVS tree. Meh... doesn't seem to be there. You can apply the following patch. http://article.gmane.org/gmane.linux.kernel/611215/raw I'll ping Jon Masters. Thanks. *** Bug 440986 has been marked as a duplicate of this bug. *** *** Bug 444670 has been marked as a duplicate of this bug. *** The kernel now installs a modules.order and depmod uses it to sort modules.dep. ...and modules.alias. Jozef, please use more meaningful Summary lines. It seems modules.dep list is now sorted differently to speed up modprobe. The original patch wouldn't work properly with this change. Jon is working on solution. We either need to make sure the modprobe speed up change is not included or fix the take Jon is working on. Given the late stage, I think it's better to do the former. Reopening and assigning to Michal Marek just to be on the safe side. Michal, if this breaks, our RC1 will break badly. Can you please make sure this is in order? Thanks. (In reply to comment #32 from Tejun Heo) > It seems modules.dep list is now sorted differently to speed up modprobe. That's in version 3.5, we do not have that version, right? > The original patch wouldn't work properly with this change. Jon is working on > solution. We either need to make sure the modprobe speed up change is not > included or fix the take Jon is working on. Given the late stage, I think it's > better to do the former. "Jon is working" can mean anything, next week or next year. :) (In reply to comment #33 from Kay Sievers) > (In reply to comment #32 from Tejun Heo) > > It seems modules.dep list is now sorted differently to speed up modprobe. > > That's in version 3.5, we do not have that version, right? Yeap, we have 3.4. I just wanted to make sure we're not mixing up the two incompatible changes and it won't happen for future updates either. Michal, feel free to close this one again. > > The original patch wouldn't work properly with this change. Jon is working on > > solution. We either need to make sure the modprobe speed up change is not > > included or fix the take Jon is working on. Given the late stage, I think it's > > better to do the former. > > "Jon is working" can mean anything, next week or next year. :) Heh... :-) OK, we might have issues once we update to 3.5, but that's not a P1/blocker for 11.1 ;). *** Bug 446294 has been marked as a duplicate of this bug. *** *** Bug 446607 has been marked as a duplicate of this bug. *** *** Bug 447970 has been marked as a duplicate of this bug. *** *** Bug 448081 has been marked as a duplicate of this bug. *** *** Bug 435590 has been marked as a duplicate of this bug. *** *** Bug 444378 has been marked as a duplicate of this bug. *** I had a problem similar to the one in bug #448081 (duplicate of this one). But in my case the final SUSE 11.1 disk either live or install disk works. They stop early in the boot process because they cant find the CD (or DVD) to boot. Like in the report I make reference, my board has a SIS chipset (SIS 655). I tried with the regular boot option and the fail safe one. That same machine boots without problem with SUSE 11.0 Live CD. I would also like to mention that it may be an upstream issue since most common Linux distributions released close to the time frame of SUSE 11.1 have the same issue (Ubuntu 8.10, Fedora 10). Older ones like Mandriva 2008, and SUSE 11.0 boot fine. This is a link to the motherboard I have in case you need to check any other spec. http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=1618&ProductName=GA-SINXP1394(GA-8SQ800%20Ultra2) (In reply to comment #42) > I had a problem similar to the one in bug #448081 (duplicate of this one). But > in my case the final SUSE 11.1 disk either live or install disk works. They > stop early in the boot process because they cant find the CD (or DVD) to boot. This is most likely a different bug. |