Bug 748043 - initrd is not added, kernel fails to boot
initrd is not added, kernel fails to boot
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: grubby (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-21 15:27 EDT by Pete Zaitcev
Modified: 2015-02-17 08:56 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 08:56:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
exact grub.conf for the record (1.54 KB, text/plain)
2011-10-21 15:28 EDT, Pete Zaitcev
no flags Details
captured what requrested in comment #2 (5.31 KB, text/plain)
2011-12-20 08:51 EST, Kamil Dudka
no flags Details

  None (edit)
Description Pete Zaitcev 2011-10-21 15:27:05 EDT
Description of problem:

After "yum update", new grub.conf does not have initrd entry. So, it looks
like this:

title Fedora (3.1.0-0.rc10.git0.1.fc17.x86_64)
        root (hd0,1)
        kernel /vmlinuz-3.1.0-0.rc10.git0.1.fc17.x86_64 ro root=/dev/N1/Fedora s
elinux=0 SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us

If initrd line is added, the result is bootable (e.g. Dracut works).
The missing line:
        initrd /initramfs-3.1.0-0.rc10.git0.1.fc17.x86_64.img

Version-Release number of selected component (if applicable):

grubby-8.2-1.fc17.x86_64

How reproducible:

Seems synchronous... Depends on grub.conf probably.

Steps to Reproduce:
1. yum update kernel
  
Actual results:

System fails to boot

Expected results:

System boots

Additional info:

[root@niphredil zaitcev]# grep grubby /var/log/yum.log
Mar 29 13:42:00 Updated: grubby-7.0.16-3.fc15.x86_64
Jun 15 14:23:54 Updated: grubby-7.0.18-1.fc16.x86_64
Jul 22 20:00:36 Updated: grubby-8.0-1.fc16.x86_64
Jul 27 11:26:54 Updated: grubby-8.1-1.fc16.x86_64
Sep 16 10:23:32 Updated: grubby-8.2-1.fc17.x86_64

I'm quite certain that grubby-8.1 worked. There were definitely new
kernels since July in Rawhide.

When run, grubby may complain that "template is not found". Not sure
if this is relevant. But exactly the same grub.conf was update before.
There were no manual changes to it in a long time.
Comment 1 Pete Zaitcev 2011-10-21 15:28:25 EDT
Created attachment 529553 [details]
exact grub.conf for the record
Comment 2 Mads Kiilerich 2011-11-25 10:22:38 EST
The kernel line and the initrd line are written by different %pre/post scripts. Are you sure the package installation was completed without other error messages?

I think the best way to understand this would be to add 'set -x' to /sbin/new-kernel-pkg and try to reproduce the problem.
Comment 3 Kamil Dudka 2011-12-20 08:45:32 EST
This is easily reproducible on my rawhide machine.

# rpm -q grubby
grubby-8.4-1.fc17.x86_64

# rpm -q kernel
kernel-3.1.5-2.fc16.x86_64
kernel-3.2.0-0.rc5.git3.1.fc17.x86_64
kernel-3.2.0-0.rc6.git0.1.fc17.x86_64

The first kernel is from fc16 rawhide and is the only one that has an initramfs file installed in /boot and referred from grub.cfg.  The new kernels have no initramfs and fail to boot.

# rpm -ql kernel-3.2.0-0.rc6.git0.1.fc17.x86_64 | grep /boot/init
/boot/initramfs-3.2.0-0.rc6.git0.1.fc17.x86_64.img

# ls /boot/initramfs-3.2.0-0.rc6.git0.1.fc17.x86_64.img
ls: cannot access /boot/initramfs-3.2.0-0.rc6.git0.1.fc17.x86_64.img: No such file or directory

# yum reinstall kernel
[...]
Non-fatal POSTTRANS scriptlet failure in rpm package kernel-3.2.0-0.rc6.git0.1.fc17.x86_64
Comment 4 Kamil Dudka 2011-12-20 08:51:59 EST
Created attachment 548841 [details]
captured what requrested in comment #2
Comment 5 Mads Kiilerich 2011-12-20 10:28:00 EST
(In reply to comment #3)
> Non-fatal POSTTRANS scriptlet failure in rpm package

The posttrans scriptlet was apparently not run at all, and the final steps of the installation is thus missing - and that _was_ kind of fatal. If it had been run then we would have seen the /sbin/new-kernel-pkg output.

It looks like a problem in the kernel rpm or in rpm if it doesn't execute the commands in the posttrans scriptlet.

(Note also that it is very likely that grubby will have problems adding initramfs lines for new kernels if the previous kernel didn't have one. Try to remove the latest kernel, grub2-mkconfig -o /boot/grub2/grub.cfg, test that the latest kernel entry works, let yum update install a new kernel and see how that works out.)
Comment 6 Kamil Dudka 2011-12-20 12:12:56 EST
(In reply to comment #5)
> If it had been run then we would have seen the /sbin/new-kernel-pkg output.

Have you actually seen my attachment?  I am pretty sure there _is_ the /sbin/new-kernel-pkg output.

> It looks like a problem in the kernel rpm or in rpm if it doesn't execute the
> commands in the posttrans scriptlet.

Are you implying that the missing /boot/initramfs* files cannot be caused by a failure of grubby?  Who is responsible for installing those files on Fedora?  Why rpm claims they belong to the kernel package although they do not exist on the file system?

I do not understand much the kernel.spec, but there is something like /sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --dracut --depmod --update %{KVERREL}%{?-v:.%{-v*}} || exit $?\

Is the command above supposed to install the /boot/initramfs* files?

> (Note also that it is very likely that grubby will have problems adding
> initramfs lines for new kernels if the previous kernel didn't have one. Try to
> remove the latest kernel, grub2-mkconfig -o /boot/grub2/grub.cfg, test that the
> latest kernel entry works, let yum update install a new kernel and see how that
> works out.)

Unfortunately, this makes no difference.

Note I could add the entry in grub.cfg myself.  The key problem is that there is no /boot/initramfs* for the kernel on my file system.
Comment 7 Mads Kiilerich 2011-12-20 15:53:54 EST
(In reply to comment #6)
> (In reply to comment #5)
> > If it had been run then we would have seen the /sbin/new-kernel-pkg output.
> 
> Have you actually seen my attachment?  I am pretty sure there _is_ the
> /sbin/new-kernel-pkg output.

Look at "rpm -q --scripts kernel.yourversion". new-kernel-pkg should be invoked 3 times when a kernel is installed. Your output only shows the first.

> Are you implying that the missing /boot/initramfs* files cannot be caused by a
> failure of grubby?  Who is responsible for installing those files on Fedora?

The second invocation of new-kernel-pkg ... but as we have seen rpm never got as far as starting new-kernel-pkg.

> Why rpm claims they belong to the kernel package although they do not exist on
> the file system?

Becuase it is %ghost.

> The key problem is that there
> is no /boot/initramfs* for the kernel on my file system.

Right. I suggest uninstalling all these incorrectly installed kernels and continue from there.

Reinstall might take some shortcuts and might not be a realistic test of upgrade paths.
Comment 8 Kamil Dudka 2011-12-22 11:39:14 EST
(In reply to comment #7)
> Look at "rpm -q --scripts kernel.yourversion".

# rpm -q --scripts kernel-3.1.5-2.fc16.x86_64
postinstall scriptlet (using /bin/sh):

if [ `uname -i` == "x86_64" -o `uname -i` == "i386" ] &&
   [ -f /etc/sysconfig/kernel ]; then
  /bin/sed -r -i -e 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/' /etc/sysconfig/kernel || exit $?
fi

/sbin/new-kernel-pkg --package kernel --install 3.1.5-2.fc16.x86_64 || exit $?
preuninstall scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove 3.1.5-2.fc16.x86_64 || exit $?
posttrans scriptlet (using /bin/sh):
/sbin/new-kernel-pkg --package kernel --mkinitrd --dracut --depmod --update 3.1.5-2.fc16.x86_64 || exit $?
/sbin/new-kernel-pkg --package kernel --rpmposttrans 3.1.5-2.fc16.x86_64 || exit $?

> Right. I suggest uninstalling all these incorrectly installed kernels and
> continue from there.
> 
> Reinstall might take some shortcuts and might not be a realistic test of
> upgrade paths.

Thanks for the suggestion, but it makes no difference.

I put 'printf "%s %s\n\n" "$0" "$*"' on top of /sbin/new-kernel-pkg and it printed this:

# yum remove kernel-3.2.0-0.rc5.git3.1.fc17.x86_64 kernel-3.2.0-0.rc6.git0.1.fc17.x86_64
# yum update kernel
[...]
Running Transaction
  Installing : kernel-3.2.0-0.rc6.git2.1.fc17.x86_64              1/1
/sbin/new-kernel-pkg --package kernel --install 3.2.0-0.rc6.git2.1.fc17.x86_64

Non-fatal POSTTRANS scriptlet failure in rpm package kernel-3.2.0-0.rc6.git2.1.fc17.x86_64
Comment 9 Mads Kiilerich 2011-12-22 15:18:53 EST
(In reply to comment #8)

You show the scriptlets from the f16 kernel that worked correctly. It would be more interesting to look at the scriptlets in the f17 kernels that fails to install correctly. But let's assume they look fine too.

You confirm that grubby isn't invoked correctly when a kernel is installed (assuming that nothing hides outpot from posttrans scripts). That proves that it isn't a grubby bug and indicates that it must be a bug in rpm (or in the kernel scripts).
Comment 10 Kamil Dudka 2012-01-02 08:07:57 EST
I am not sure whether my problem was related to this bug report or not ... but whatever the problem was, it went away with the recent updates.  All kernels on my machine have now the appropriate /boot/initramfs-* files installed and I am able to boot them with no issues.
Comment 11 Mads Kiilerich 2012-01-02 08:18:20 EST
(In reply to comment #9)
> (assuming that nothing hides outpot from posttrans scripts)

It seems like the assumption was wrong and something _do_ hide the output from posttrans scripts, so debug info should be written to some log file instead.
Comment 12 Fedora End Of Life 2013-04-03 13:02:56 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 13 Fedora End Of Life 2015-01-09 11:49:59 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 14 Fedora End Of Life 2015-02-17 08:56:09 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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