From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-December/010542.html | 166 +++++++++++++++++++++++++++ 1 file changed, 166 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-December/010542.html (limited to 'zarb-ml/mageia-dev/2011-December/010542.html') diff --git a/zarb-ml/mageia-dev/2011-December/010542.html b/zarb-ml/mageia-dev/2011-December/010542.html new file mode 100644 index 000000000..886bd085f --- /dev/null +++ b/zarb-ml/mageia-dev/2011-December/010542.html @@ -0,0 +1,166 @@ + + + + [Mageia-dev] Issues with dracut + + + + + + + + + +

[Mageia-dev] Issues with dracut

+ Colin Guthrie + 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:
+> 
+>> 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/
+
+ + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1