Bug 3395 - dracut produces an initramfs that loads pata_acpi before pata_via
Summary: dracut produces an initramfs that loads pata_acpi before pata_via
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 2
Hardware: i586 Linux
Priority: Normal major
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard: 3alpha3
Keywords: PATCH, Triaged
Depends on:
Blocks: 4298
  Show dependency treegraph
 
Reported: 2011-11-20 04:16 CET by Dave Hodgins
Modified: 2012-11-17 14:51 CET (History)
5 users (show)

See Also:
Source RPM: dracut-013-2.mga2.src.rpm
CVE:
Status comment:


Attachments
dmesg using initrd-3.1.1-server-0.rc1.1.mga2.img (113.34 KB, text/plain)
2011-11-20 04:20 CET, Dave Hodgins
Details
patch for udev rule (513 bytes, patch)
2011-12-29 04:40 CET, Dave Hodgins
Details | Diff
patch for lvm_scan script (77 bytes, patch)
2011-12-29 04:41 CET, Dave Hodgins
Details | Diff
Patch for mount script to not force ro mount (454 bytes, patch)
2011-12-29 04:42 CET, Dave Hodgins
Details | Diff
patch for lvm_scan script (307 bytes, patch)
2011-12-29 04:46 CET, Dave Hodgins
Details | Diff

Description Dave Hodgins 2011-11-20 04:16:21 CET
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.
Comment 1 Dave Hodgins 2011-11-20 04:20:10 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.
Comment 2 Manuel Hiebel 2011-11-20 12:15:12 CET
Hi, thanks for reporting this bug.
Assigned to the package maintainer.

Keywords: (none) => Triaged
Assignee: bugsquad => mageia

Comment 3 Colin Guthrie 2011-11-30 23:04:46 CET
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
Comment 4 Colin Guthrie 2011-11-30 23:47:01 CET
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

Comment 5 Dave Hodgins 2011-12-01 00:56:25 CET
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.
Comment 6 Colin Guthrie 2011-12-01 10:23:37 CET
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)
Comment 7 Dave Hodgins 2011-12-01 20:00:57 CET
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.
Comment 8 Colin Guthrie 2011-12-01 20:54:56 CET
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.
Comment 9 Dave Hodgins 2011-12-01 22:39:54 CET
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.
Comment 10 Dave Hodgins 2011-12-01 23:42:34 CET
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.
Comment 11 Colin Guthrie 2011-12-01 23:55:28 CET
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

Comment 12 Dave Hodgins 2011-12-02 02:30:11 CET
(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.
Comment 13 Dave Hodgins 2011-12-13 19:00:32 CET
This bug still applies after doing a clean install using the alpha 2 dvd
pre-release iso, and then installing all updates.
Comment 14 Dave Hodgins 2011-12-29 04:40:09 CET
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.
Comment 15 Dave Hodgins 2011-12-29 04:41:25 CET
Created attachment 1298 [details]
patch for lvm_scan script

Apparently, under udev, the path is not set.
Comment 16 Dave Hodgins 2011-12-29 04:42:55 CET
Created attachment 1299 [details]
Patch for mount script to not force ro mount
Comment 17 Dave Hodgins 2011-12-29 04:46:08 CET
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

Comment 18 Thierry Vignaud 2011-12-29 16:16:04 CET
(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

Comment 19 Marja van Waes 2012-01-21 13:47:25 CET
(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

Comment 20 Dave Hodgins 2012-02-18 20:44:50 CET
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.
Comment 21 pîrîu cristian 2012-02-20 17:50:22 CET
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

Comment 22 pîrîu cristian 2012-03-10 14:56:46 CET
On top on that it prevents MCC from running. I can confirm that adding rdloaddriver=pata_via solves both issues.
Comment 23 Marja van Waes 2012-03-10 15:12:42 CET
removing NEEDINFO keyword, as Dave provided all information asked for.

Keywords: NEEDINFO => (none)

Comment 24 pîrîu cristian 2012-03-17 06:45:45 CET
Problem solved during one of the last updates, thank you everyone.
Comment 25 Manuel Hiebel 2012-03-17 15:53:35 CET
(In reply to comment #24)
> Problem solved during one of the last updates, thank you everyone.

ok

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 26 Dave Hodgins 2012-11-03 23:34:20 CET
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
Resolution: FIXED => (none)
Whiteboard: (none) => 3alpha3

Comment 27 Colin Guthrie 2012-11-03 23:38:23 CET
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!)
Comment 28 Manuel Hiebel 2012-11-17 14:51:17 CET
(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
Status: REOPENED => RESOLVED
Version: Cauldron => 2


Note You need to log in before you can comment on or make changes to this bug.