As discusseded in bug 3385 pata_acpi is again being loaded before pata_via making my dvd drive inaccessible. According to $ grep -e pata_via -e pata_acpi /lib/modules/3.1.1-server-0.rc1.1.mga2/modules.order kernel/drivers/ata/pata_via.ko kernel/drivers/ata/pata_acpi.ko I've noticed that /lib/modules/3.1.1-server-0.rc1.1.mga2/modules.order does not exist in /boot/initrd-3.1.1-server-0.rc1.1.mga2.img I created a new initramfs that does contain it as /boot/initrd-3.1.1-server-0.rc1.1.mga2.test.img however that doesn't seem to be enough to correct the order. I also tried copying all of the files from /lib/modules/3.1.1-server-0.rc1.1.mga2/ into the test initrd, but that is still not enough to correct the loading order. I'm stuck at this point trying to figure out what else has to be done to correct the loading order.
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) => TriagedAssignee: bugsquad => mageia
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
Keywords: (none) => PATCH
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
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 => RESOLVEDResolution: (none) => FIXED
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 => REOPENEDResolution: FIXED => (none)Whiteboard: (none) => 3alpha3
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) => FIXEDStatus: REOPENED => RESOLVEDVersion: Cauldron => 2