Description of problem: systems fails to boot with "Failed to execute /init". dracut creates this kind of dir structure: # ls -ld lib64/libtinfo.so* usr usr/lib64 lib64 lrwxrwxrwx 1 root root 9 Mar 1 00:14 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 15 Mar 1 00:14 lib64/libtinfo.so -> libtinfo.so.5.9 lrwxrwxrwx 1 root root 28 Mar 1 00:14 lib64/libtinfo.so.5 -> ../usr/lib64/libtinfo.so.5.9 -rwxr-xr-x 1 root root 167608 Mar 1 00:14 lib64/libtinfo.so.5.9 drwxr-xr-x 7 root root 61 Mar 1 00:14 usr drwxr-xr-x 4 root root 8192 Mar 1 00:14 usr/lib64 # file {/,}lib64/libtinfo.so.5 /lib64/libtinfo.so.5: symbolic link to `libtinfo.so.5.9' lib64/libtinfo.so.5: broken symbolic link to `../usr/lib64/libtinfo.so.5.9' # chroot /boot/grub2/x lib64/ld-2.15.so bin/bash bin/bash: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory I think this is why on boot kernel fails to execute /init . Most of the other symlinks are broken, too. When I fix them (like they are in the real /lib64 , that chroot command works. Version-Release number of selected component (if applicable): 016-9.git20120217.fc17 How reproducible: 100% Steps to Reproduce: 1. run dracut 2. 3. Actual results: Expected results: Additional info: initrd created with dracut-014 manages to boot the system (but system shutdown does not work)
can you try: https://admin.fedoraproject.org/updates/FEDORA-2012-2699/dracut-017-17.git20120229.2.fc17
at least it now creates dir structure which works with that chroot test. but I am not doing a reboot test right now..
had to reboot due to drm problems, now with this updated dracut and 3.3rc5 kernel, it works ok, and reboot also works without panic.