Bug 1015149 - yum install of a new kernel fails in dracut
yum install of a new kernel fails in dracut
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-03 10:10 EDT by Fabio Valentini
Modified: 2013-10-08 04:06 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-07 17:55:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabio Valentini 2013-10-03 10:10:22 EDT
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)

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


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
  Verifying  : kernel-3.11.2-301.fc20.x86_64                                1/3 
  Verifying  : kernel-devel-3.11.2-301.fc20.x86_64                          2/3 
  Verifying  : kernel-modules-extra-3.11.2-301.fc20.x86_64                  3/3 

Installed:
  kernel.x86_64 0:3.11.2-301.fc20                                               
  kernel-devel.x86_64 0:3.11.2-301.fc20                                         
  kernel-modules-extra.x86_64 0:3.11.2-301.fc20                                 

Complete!
Comment 1 Harald Hoyer 2013-10-07 04:57:14 EDT
(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?
Comment 2 Fabio Valentini 2013-10-07 17:55:52 EDT
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!
Comment 3 Harald Hoyer 2013-10-08 04:06:45 EDT
something has corrupted your grubby install

Note You need to log in before you can comment on or make changes to this bug.