[Mageia-dev] Issues with dracut

[JA Magallon]

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
> 
>