As discusseded in bug 3385 pata_acpi is again being loaded before pata_via
making my dvd drive inaccessible.
$ grep -e pata_via -e pata_acpi /lib/modules/3.1.1-server-0.rc1.1.mga2/modules.order
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
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.
Just as a workaround here, you can edit /etc/dracut.conf and fine the line that starts:
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:
(i.e. nothing) would suffice. It could be worth testing an initrd generated like that?
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.
# grep driver /etc/dracut.conf
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
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
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?
(In reply to comment #11)
> 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.
While this does work, as a workaround, wouldn't it be better to get
udev to obey the order specified by
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:
(In reply to comment #11)
> Thierry, can you advise there on how to generate modprode.d rules for specific
Thomas & blino have fixed a similar (eg pata_via vs pata_acpi) bugs in the past
(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
If you didn't do so yet, can you please help Colin with this?
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 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.
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.
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.
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.
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