[Mageia-dev] Issues with dracut

[Colin Guthrie]

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)

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.


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

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


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


-- 

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/