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.
Created attachment 529553 [details] exact grub.conf for the record
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.
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
Created attachment 548841 [details] captured what requrested in comment #2
(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.)
(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.
(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.
(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
(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).
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.
(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.
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
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.
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.