[Mageia-dev] Issues with dracut
mageia at colin.guthr.ie
Sat Dec 17 00:18:50 CET 2011
'Twas brillig, and JA Magallon at 16/12/11 22:52 did gyre and gimble:
> On Fri, 16 Dec 2011 12:35:22 +0000
> Colin Guthrie <mageia at colin.guthr.ie> wrote:
>> 'Twas brillig, and JA Magallon at 16/12/11 12:06 did gyre and gimble:
>>> After those couple previous thread it looks like move to dracut is
>>> ongoing, so I decided to try it.
>> Good! This is exactly the kind of feedback we need!
>>> I found a couple problems:
>>> - dracut inists on loading nouveau driver. With mknitrd, just booting with nokmsboot
>>> works. Booting with a dracut generated initrd ignores that. I think it is plymouth
>>> that forces it, even if I added 'blacklist nouveau' in a .conf file in modprobe.d:
>>> dracut -f:
>> I'll include it but if it's blacklisted, it shouldn't ultimately be used
>> in the ramfs even if it's included. That said, it's clearly inefficient
>> to include it if it is blacklisted so we should try and fix that. Anssi,
>> could this be your code to detect the h/w that causes it to bypass any
>> blacklist checks (not sure if there are actually any blacklist checks
>> when building the initrd... not relaly looked at it much)ç
> Let's state all my findings. As 'nokmsboot' was ignored, i remembered CentOS
> where the nvidia installer achived the same blacklisting nouveau.
> I added the blacklist in /etc/modprobe.d/display-driver.conf, which is a
> symlink to /etc/nvidia-current/modprobe.conf. It didn't work.
> After the fiasco with symlinks in systemd, i tried creting a new file.
> And it worked. So there is something strange with symlinked files...
That's interesting... The code in question:
./modules.d/90kernel-modules/module-setup.sh: for i in $(find
/etc/modprobe.d/ -type f -name '*.conf'); do
So it only finds files.
If I change "find" to "find -L" this should fix up this problem (when
the files are installed, links are dereferenced so that won't be a problem).
This should avoid any such similar problems.
Also I believe it's pointless to go into any subfolders here, so adding
also a -maxdepth 1 should cut down on unnecessary includes.
>>> - initrd from dracut fails to detect one of my drives, and booting stops:
>> OK, this is more interesting.
> I found the problem:
> werewolf:~/dr# cat lsscsi*
> [0:0:0:0] disk ATA ST3250310AS 3.AA /dev/sda
> [1:0:0:0] disk ATA WDC WD3200AVJS-6 12.0 /dev/sdb
> [2:0:0:0] disk ATA ST3320620AS 3.AA /dev/sdc
> [3:0:0:0] disk ATA ST3500418AS CC38 /dev/sdh
> [5:0:0:0] cd/dvd HL-DT-ST DVDRAM GH22NS50 TN01 /dev/sr0
> [6:0:0:0] disk Generic USB CF Reader 0.00 /dev/sdd
> [6:0:0:1] disk Generic USB SD Reader 0.00 /dev/sde
> [6:0:0:2] disk Generic USB MS Reader 0.00 /dev/sdf
> [6:0:0:3] disk Generic USB SM Reader 0.00 /dev/sdg
> The disk has been renamed as sdh
> I changed the mounting points from devices to labels and all worked fine.
> This will probably not be an issue with standard install, using UUIDs,
> but the real problem is that drive name asssignment is even more random
> (well, interlaced ;)).
Hmm, interesting. Not quite sure why it's doing that but as it's using
udev rather than any manual driver loading, it's likely a more
predicable system overall in the long term.
Tribalogic Limited http://www.tribalogic.net/
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
More information about the Mageia-dev