'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 <mag...@colin.guthr.ie> wrote: > >> Hiya, >> >> '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)รง > > Clue... > 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: > > lsscsi: > 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. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/