| Summary: | yum install of a new kernel fails in dracut | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Fabio Valentini <decathorpe> |
| Component: | dracut | Assignee: | dracut-maint |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | dracut-maint, harald, jonathan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-07 21:55:52 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Fabio Valentini
2013-10-03 14:10:22 UTC
(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 |