(In reply to Fabio Valentini from comment #0)
> Description of problem:
> Since the last dracut update, installing new kernels via yum creates the
> (empty) directories /boot/efi, /boot/loader and /boot/(SomeLongNumber) and
> fails to create a new initramfs, leaves the System without an initramfs for
> the new version, does not create new grub entries, and leaves a system
> unable to boot the new kernel.
> 
> 
> Version-Release number of selected component (if applicable):
> dracut-033-3.git20130913.fc20
> first encountered when wanting to upgrade to kernel 3.11.2-301.fc20
> 
> 
> How to reproduce with yum:
> 1. yum install kernel-VERSION (fails with some $POSTINST script failure)
> leaves behind empty /boot/loader, /boot/efi and /boot/SomeLongNumber
> directories.
> 
> 
> Steps to reproduce with upstream kernel:
> 1. make bzImage (works)
> 2. make modules (works)
> 3. sudo make modules_install (works)
> 4. sudo make install (fails to create an initramfs with dracut, prints "LILO
> not found" and leaves the system without initramfs; this used to work just
> fine)

Well, this "LILO not found" comes from /sbin/installkernel and grubby.

> 
> Creating an initramfs manually with
> sudo dracut /boot/initramfs-VERSION VERSION --verbose
> works just fine though and prints no error messages (about missing LILO
> etc.).

fine, so it's a grubby failure here, not dracut.

> 
> 
> Actual results:
> yum install of new kernels fails.
> 
> 
> Expected results:
> kernel installs, dracut creates a bootable initramfs, grub menu entries are
> created.
> 
> 
> Additional info:
> I am using BIOS boot on a 5 year old machine with GPT partition table and a
> BIOS Boot partition for GRUB.
> I have NOT modified any configuration files in /etc or anywhere else, and
> "rpm -Va" does not report any modified files that might be relevant.
> 
> 
> yum output of "yum upgrade":
> 
> (...)
> Running transaction check
> Running transaction test
> Transaction test succeeded
> Running transaction
>   Installing : kernel-3.11.2-301.fc20.x86_64                               
> 1/3 
>   Installing : kernel-modules-extra-3.11.2-301.fc20.x86_64                 
> 2/3 
>   Installing : kernel-devel-3.11.2-301.fc20.x86_64                         
> 3/3 
> dracut-install: ERROR: installing '/usr/lib/udev/bcache-register'
> /usr/lib/dracut/dracut-install -D /var/tmp/initramfs.7pvnD2 -a
> /usr/lib/udev/bcache-register
> /usr/lib/kernel/install.d/51-dracut-rescue.install: line 59:
> /boot/loader/entries/7725dfc225d14958a625ddaaaea5962b-0-rescue.conf: No such
> file or directory
> warning: %posttrans(kernel-3.11.2-301.fc20.x86_64) scriptlet failed, exit
> status 1
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kernel-3.11.2-301.fc20.x86_64

Hmm, so, we might have 2 bugs here.

1. Do you have a bcache partition?
2. Does /sbin/new-kernel-pkg exist?
3. Did the directory "/boot/loader/entries" exist on your system?

Concerning your questions:
1. No. I only have (BIOS boot), /boot, swap, / and encrypted /home on LUKS.
2. Yes, new-kernel-pkg exists when grubby is installed. 
3. /boot/loader/entries did not exist on my system prior to installing kernel-3.11.2-30x.fc20.




Today I tried to retrace my steps to reproduce the problem and narrow down the cause. But then, I encountered some very strange behaviour ...

So this is what I did:

I downloaded upstream 3.12-rc4, copied my config in and tried the following:
Grubby is installed. Compiling  worked, but installing the kernel didn't work.
I removed grubby. Compiling worked, but installing the kernel didn't work.
I installed grubby again. Compiling and installing worked, no complaints at all.

I tried the same with 3.12-rc2, everything works again, although I did not change my system at all, besides removing and installing grubby. Well ... I think this fits "Heisenbug" quite well ;)

At least that worked again. No idea why.


Then I went on to investigate the strange behaviour that the fedora kernel packages showed, but they installed just normally after removing and re-installing grubby. ... Heisenbug?


But I think all the problems I encountered just vanished into thin air. (... WHY??)

After testing all this and confirming that it works again today, I think we can think of it all as a rare system oddity and just close the bug. If anything weird happens again, I will try to investigate to more detail. *sigh*


Anyway, thank you very much for your help!

something has corrupted your grubby install