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