| Summary: | dracut produces an initramfs that loads pata_acpi before pata_via | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Dave Hodgins <davidwhodgins> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | mageia, marja11, piriu.cristian, thierry.vignaud, tmb |
| Version: | 2 | Keywords: | PATCH, Triaged |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | 3alpha3 | ||
| Source RPM: | dracut-013-2.mga2.src.rpm | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 4298 | ||
| Attachments: |
dmesg using initrd-3.1.1-server-0.rc1.1.mga2.img
patch for udev rule patch for lvm_scan script Patch for mount script to not force ro mount patch for lvm_scan script |
||
|
Description
Dave Hodgins
2011-11-20 04:16:21 CET
Created attachment 1089 [details]
dmesg using initrd-3.1.1-server-0.rc1.1.mga2.img
As shown in the dmesg output, pata_acpi is being loaded immediately
after libata. pata_via does not show up in the dmesg output.
$ lsmod|grep ata
pata_via 13404 0
pata_acpi 12875 0
ata_generic 12779 0
libata 182650 3 pata_via,pata_acpi,ata_generic
scsi_mod 185944 4 sg,sd_mod,usb_storage,libata
The pata_via module is being loaded, but since it's being loaded
after pata_acpi, it doesn't do anything.
Hi, thanks for reporting this bug. Assigned to the package maintainer. Keywords:
(none) =>
Triaged Just as a workaround here, you can edit /etc/dracut.conf and fine the line that starts: add_drivers+= Just put your pata_via before the pata_acpi... This line is added in an Mandriva patch and I'm not 100% sure how needed it really is. Ideally the upstream default of: #add_drivers+="" (i.e. nothing) would suffice. It could be worth testing an initrd generated like that? Col OK, so I just submitted a new dracut without this customisation so just update and ensure you do not have a /etc/dracut.conf.rpmnew and then regenerate your initrd and see if all is well. Thanks. Keywords:
(none) =>
NEEDINFO Doesn't work. # grep driver /etc/dracut.conf #add_drivers+="" To update the initrd, I used ... dracut -f /boot/initrd-3.1.4-server-1.mga2.img 3.1.4-server-1.mga2 After reboot, lsmod shows pata_acpi is still loading before pata_via, and /dev/sr0 does not exist. Can you just double check that adding pata_via to the add_drivers line works as expected (and includes the other pata_acpi as well which I presume is still needed) It doesn't. Despite having # grep driver /etc/dracut.conf add_drivers+="pata_via" The pata_acpi module is still being loaded before pata_via. head -n 1 /etc/modprobe.conf install scsi_hostadapter /sbin/modprobe pata_via; /sbin/modprobe sata_via; /bin/true I have no idea why the pata_acpi module is being loaded first. Can you do the following: 1. Create a file in /etc/modprobe.d/pata-via-first.conf 2. In it, put the line: install pata_acpi /sbin/modprobe pata_via; /sbin/modprobe --ignore-install pata_acpi 3. Regenerate initrd 4. Test. If it works, it would be nice to test whether or not the add_drivers bit is needed or not now (I'm quietly hoping that dracut would parse the install line and automatically include it, but I'm not sure it's that intelligent. After looking through the dracut hooks some more, I've found that adding the kernel parameter rdloaddriver=pata_via works. I'll also give the method described in comment 8 a try, without the kernel option and with/without the add_drivers option. Creating the file described in comment 8, and regenerating the inird works! It works with or without the pata_via in add_drivers+ in /etc/dracut.conf. I did remove the rdloaddriver kernel option. Nice. So that's a pretty simple approach then :) Just to double check: after removing the add_drivers+ line, did you regenerate the initrd again before testing? Now we need to work out how to generate such configuration on your hardware... I wonder if a harddrake rule or something is needed? I don't really know this side of things. Thierry, can you advise there on how to generate modprode.d rules for specific h/w? CC:
(none) =>
thierry.vignaud (In reply to comment #11) > Just to double check: after removing the add_drivers+ line, did you regenerate > the initrd again before testing? Yes. > Now we need to work out how to generate such configuration on your hardware... > I wonder if a harddrake rule or something is needed? I don't really know this > side of things. While this does work, as a workaround, wouldn't it be better to get udev to obey the order specified by /lib/modules/3.1.4-server-1.mga2/modules.order Obviously it can't if that file is not in the initramfs, but simply adding it to the initramfs doesn't get it obeyed. Something else needs to be done, as well. This bug still applies after doing a clean install using the alpha 2 dvd pre-release iso, and then installing all updates. Created attachment 1297 [details]
patch for udev rule
Colin, I managed to get my lvm /usr to mount properly. This this the first
of three patches that make it work.
Created attachment 1298 [details]
patch for lvm_scan script
Apparently, under udev, the path is not set.
Created attachment 1299 [details]
Patch for mount script to not force ro mount
Created attachment 1300 [details]
patch for lvm_scan script
Sorry, messed up the diff command.
Attachment 1298 is obsolete:
0 =>
1
Thierry Vignaud
2011-12-29 16:05:11 CET
Keywords:
(none) =>
PATCH
Thierry Vignaud
2011-12-29 16:08:21 CET
CC:
(none) =>
mageia (In reply to comment #11) > Thierry, can you advise there on how to generate modprode.d rules for specific > h/w? Thomas & blino have fixed a similar (eg pata_via vs pata_acpi) bugs in the past CC:
(none) =>
tmb (In reply to comment #18) > (In reply to comment #11) > > Thierry, can you advise there on how to generate modprode.d rules for specific > > h/w? > > Thomas & blino have fixed a similar (eg pata_via vs pata_acpi) bugs in the past @ Thomas @ Blino If you didn't do so yet, can you please help Colin with this? CC:
(none) =>
marja11
Manuel Hiebel
2012-02-06 14:47:03 CET
Blocks:
(none) =>
4298 The problem is back with the latest cauldron installs. Despite having ... # cat /etc/modprobe.d/pata-via-first.conf install pata_acpi /sbin/modprobe pata_via; /sbin/modprobe --ignore-install pata_acpi pata_acpi is being loaded before pata_via, so my hard drives are hda instead of sda, and the dvd drive is not sr0. This is a long lasting bug, since is blocking access to optical media drive this should be resolved as quick as posible. CC:
(none) =>
piriu.cristian On top on that it prevents MCC from running. I can confirm that adding rdloaddriver=pata_via solves both issues. removing NEEDINFO keyword, as Dave provided all information asked for. Keywords:
NEEDINFO =>
(none) Problem solved during one of the last updates, thank you everyone. (In reply to comment #24) > Problem solved during one of the last updates, thank you everyone. ok Status:
NEW =>
RESOLVED This bug is back again with Mageia 3 alpha 3 live iso images, both in live mode, and after installing. Hard drives are assigned hd? instead of sd?. Dvd drive is assigned hd? instead of sr?, causing lots of error messages in dmesg, and when loading diskdrake, as it tries to get the geometry etc. Status:
RESOLVED =>
REOPENED I know this is the same problem, but I really think we should open a new bug for this as this one is pulling in all sorts of dependant bugs etc (e.g. mga2 specifications). I think it would be cleaner. If you disagree, that's fine, but otherwise please close and open a new one (clone this one if you like!) (In reply to comment #27) > I know this is the same problem, but I really think we should open a new bug > for this as this one is pulling in all sorts of dependant bugs etc (e.g. mga2 > specifications). I think it would be cleaner. If you disagree, that's fine, but > otherwise please close and open a new one (clone this one if you like!) https://bugs.mageia.org/show_bug.cgi?id=7913 guess it's the same Resolution:
(none) =>
FIXED |