[Mageia-dev] Issues with dracut

Fri Dec 16 23:52:47 CET 2011

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...
+
+> 
+> I think the nokmsboot parameter is not working in dracut because the
+> udev rule that interprets it uses the grep command and that is not
+> currently included in the ramdisk. I could hack it in easy enough, but
+> we should maybe see if a more minimal method of detecting it in the
+> commandline is possible.
+> 
+
+At boot I get a message about (bin/grep non existent, right...
+
+> 
+> > - initrd from dracut fails to detect one of my drives, and booting stops:
+> 
+> OK, this is more interesting.
+> 
+> > systemd[1]: Job dev-sdd1.device/start timed out.
+> > systemd[1]: Job fedora-autorelabel.service/start failed with result 'dependency'.
+> > systemd[1]: Job fedora-autorelabel-mark.service/start failed with result 'dependency'.
+> > systemd[1]: Job mandriva-boot-links.service/start failed with result 'dependency'.
+> > systemd[1]: Job local-fs.target/start failed with result 'dependency'.
+> > systemd[1]: Triggering OnFailure= dependencies of local-fs.target.
+> > systemd[1]: Job export-video.mount/start failed with result 'dependency'.
+> > systemd[1]: Job home-shared-media-video.mount/start failed with result 'dependency'.
+> > systemd[1]: Job dev-sdd1.device/start failed with result 'timeout'.
+> 
+> 
+> When this happens you should get an emergency shell right? In this shell
+> you should be able to do: "mount /home/shared/media/video" and it should
+> work, then you should be able to do "systemctl start local-fs.target"
+> and it should succeed. And you can then do "systemctl start
+> graphical.target" to continue to a normal boot.
+> 
+
+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 ;)).
+
+> >   If I rengerate initrd with mkinitrd, system boots fine.
+> 
+> Sadly mkinitrd fails with anything relating to LVM when used with
+> systemd so we really do need to solve the problem with dracut to get
+> this nailed. I'm sure it's possible :)
+> 
+> 
+> > fstab is like:
+> > 
+> > /dev/sda1  /                        ext4 acl,relatime 1 1
+> > none       /proc                    proc defaults 0 0
+> > /dev/sda2  /opt                     ext4 acl,relatime 1 2
+> > /dev/sda3  swap                     swap defaults 0 0
+> > /dev/sdb1  /home                    ext4 acl,relatime 1 2
+> > /dev/sdc1  /home/shared/media/music ext4 acl,relatime 1 2
+> > /dev/sdd1  /home/shared/media/video ext4 acl,relatime 1 2
+> > 
+> > /home/shared/media/music /export/music bind bind 0 0
+> > /home/shared/media/video /export/video bind bind 0 0
+> > /home/shared/in          /export/in    bind bind 0 0
+> > /opt/soft                /export/soft  bind bind 0 0
+> 
+> 
+> That all looks OK to me.
+> 
+> > lsscsi:
+> > werewolf:~# lsscsi
+> > [3:0:0:0]    disk    ATA      ST3500418AS      CC38  /dev/sdd 
+> 
+> I guess sdd translates to ata4...
+> 
+> > ata4: SATA max UDMA/133 abar m2048 at 0xf9ffe800 port 0xf9ffea80 irq 43
+> 
+> > ata4.00: ATA-8: ST3500418AS, CC38, max UDMA/133
+> > ata4.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
+> > ata4.00: configured for UDMA/133
+> 
+> 
+> Hmm.
+> 
+> Well, systemd uses the information in udev to determin when the disks
+> are ready/available, so it seems that some kind of metadata goes missing
+> somewhere.
+> 
+
+Well, as I said above, the disk was still there, but I was looking for it
+under sda, that now pointed to my usb flash card reader :(.
+
+> 
+> Can you try and boot with the dracut again, verify you can ultimately
+> make it to a regular boot via the commands I listed above from the
+> emergency shell.
+> 
+> You can pass splash=verbose to disable any graphical stuff and and you
+> can also pass rd.debug=1 to get extra info.
+> 
+> If you boot like that and them post the dmesg, that might offer some clues.
+> 
+> There is also some udevadm stuff to run too after booting.
+> 
+> udevadm info --query env --name=/dev/sdd1
+> 
+> It's this info systemd uses to work out if the disk is ready or not, so
+> this is probably quite important.
+> 
+> All the best
+> 
+> Col
+> 
+> 
+
+