Bug 1013087 - initramfs for rescue kernel not generated at system install time, trying to boot rescue kernel causes kernel panic
Summary: initramfs for rescue kernel not generated at system install time, trying to b...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Depends On:
Blocks: F20BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2013-09-27 19:52 UTC by Chris Murphy
Modified: 2013-10-15 16:26 UTC (History)
16 users (show)

Fixed In Version: anaconda-20.25-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-15 06:35:22 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
anaconda.log (12.25 KB, text/plain)
2013-09-27 19:58 UTC, Chris Murphy
no flags Details
program.log (57.37 KB, text/plain)
2013-09-27 19:58 UTC, Chris Murphy
no flags Details
storage.log (244.33 KB, text/plain)
2013-09-27 19:58 UTC, Chris Murphy
no flags Details
patch (1.95 KB, patch)
2013-10-11 18:52 UTC, Brian Lane
no flags Details | Diff

Description Chris Murphy 2013-09-27 19:52:33 UTC
Description of problem: After a successful installation, choosing the rescue kernel option in the GRUB menu results in a kernel panic.


Version-Release number of selected component (if applicable):
Fedora-Live-Desktop-x86_64-20-Alpha-4.iso
anaconda 20.18-1 and anaconda 20.20-1

How reproducible:
Always

Steps to Reproduce:
1. Fedora-Live-Desktop-x86_64-20-Alpha-4.iso
2. Install with default guided partition, LVM scheme.
3. Reboot and choose the rescue kernel

Actual results:
Kernel panic.

Expected results:
Not a kernel panic.

Additional info:
The initramfs for the rescue kernel is missing.

Comment 1 Chris Murphy 2013-09-27 19:58:13 UTC
Could this be a dupe of bug 983287 that slipped through the cracks from F19? Or is it transient?

Proposing as a Fedora 20 beta blocker: "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional." And also "A system installed without a graphical package set must boot to a working login prompt without any unintended user intervention, and all virtual consoles intended to provide a working login prompt must do so."

Comment 2 Chris Murphy 2013-09-27 19:58:34 UTC
Created attachment 804133 [details]
anaconda.log

Comment 3 Chris Murphy 2013-09-27 19:58:48 UTC
Created attachment 804134 [details]
program.log

Comment 4 Chris Murphy 2013-09-27 19:58:59 UTC
Created attachment 804135 [details]
storage.log

Comment 5 KitchM 2013-09-30 14:55:10 UTC
This happens with FC19 and has not yet been fixed.

Is there any news from developers on this?

Comment 6 Mike Ruckman 2013-10-02 19:57:03 UTC
Discussed this in the 2013-10-02 Blocker Review Meeting [1]. This has been voted a RejectedBlocker. While unfortunate, this does not violate any F20 beta release criteria and thus is rejected as a release blocking issue for f20 beta.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/

Comment 7 KitchM 2013-10-02 20:22:11 UTC
So basically, if I understand correctly, there will be no more rescue kernel and no way to recover a Fedora system.

That is a very serious problem for users of Fedora and fairly frightening as well.

Comment 8 Chris Murphy 2013-10-02 20:34:39 UTC
(In reply to KitchM from comment #7)
No. It means this bug will not block the release of beta, should it still be unfixed at the beta go/no-go meeting.

Comment 9 KitchM 2013-10-02 23:47:06 UTC
Well then, what about the existing FC19 release's bug?

Comment 10 Chris Murphy 2013-10-03 00:12:08 UTC
(In reply to KitchM from comment #9)
Apparently on both F19 and F20, a yum update causes the initramfs to be created for the rescue kernel. I don't know if that's the intended behavior or not. At least on my F19 and F20 system, once I've done a yum update (at least one that includes a kernel update) the rescue kernel has an initramfs and can boot the system.

Comment 11 KitchM 2013-10-04 04:21:23 UTC
Not on mine.  The kernel panic still occurs.

Comment 12 Chris Murphy 2013-10-04 04:31:44 UTC
Is there an initramfs for that kernel? Is there an initrd entry for it in the grub.cfg?

Comment 13 KitchM 2013-10-04 13:37:31 UTC
Please read bug at https://bugzilla.redhat.com/show_bug.cgi?id=983287

Comment 14 Vratislav Podzimek 2013-10-09 13:46:20 UTC
Anaconda calls (from the program.log):

new-kernel-pkg --mkinitrd --dracut --depmod --update 3.11.0-300.fc20.x86_64

which should create the rescue initrd and set it in the grub.cfg. Reassigning.

Comment 15 Adam Williamson 2013-10-11 11:55:27 UTC
So far as I can see this probably isn't grubby either - grubby doesn't do, and isn't supposed to do, anything magical to get rescue kernel properly installed, it is dracut's job (via dracut-config-rescue subpackage). Re-assigning to dracut, as I think that's where the problem must be.

Comment 16 Adam Williamson 2013-10-11 12:37:59 UTC
So, a new build of dracut landed in Bodhi quite recently. I thought I'd build a live image including that dracut and see if it fixes the bug. So I did (also included the latest anaconda, 20.24). Install from that image appears to hang the system at 'Installing bootloader' - my VM is showing constant 100% CPU and RAM use and I can't get it to switch to a VT. Interesting, but not entirely helpful...

Comment 17 Harald Hoyer 2013-10-11 12:39:53 UTC
(In reply to Chris Murphy from comment #2)
> Created attachment 804133 [details]
> anaconda.log

none of those logs contain the journal or the output of the rpm installation.

Please add the journal of the installation.

Comment 18 Harald Hoyer 2013-10-11 12:43:28 UTC
is the package "dracut-config-rescue" installed?

Comment 19 Harald Hoyer 2013-10-11 12:44:20 UTC
(In reply to Harald Hoyer from comment #18)
> is the package "dracut-config-rescue" installed?

yes, it is, otherwise there would be no rescue entry in grub

Comment 20 Adam Williamson 2013-10-11 12:48:20 UTC
indeed it is, yeah. I'm currently poking at this in a VM - it's easy enough to reproduce, Harald, just grab any F20 Beta TC2 image ( https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/ ) and run an install.

Comment 21 Harald Hoyer 2013-10-11 12:55:39 UTC
(In reply to Adam Williamson from comment #20)
> indeed it is, yeah. I'm currently poking at this in a VM - it's easy enough
> to reproduce, Harald, just grab any F20 Beta TC2 image (
> https://dl.fedoraproject.org/pub/alt/stage/20-Beta-TC2/ ) and run an install.

downloading...

Comment 22 Harald Hoyer 2013-10-11 13:17:50 UTC
Downloaded Fedora-20-Beta-TC2-x86_64-netinst.iso, chose "minimal", autopartitioning.

Reboot, boot into rescue..

WORKSFORME

Comment 23 Adam Williamson 2013-10-11 13:42:13 UTC
So, haraldh and I have tracked this one down, we think. Basically this commit broke it:

https://git.fedorahosted.org/cgit/anaconda.git/commit/pyanaconda/packaging/__init__.py?id=57c19f440148a0f31288bdabd923c4f663ad11fc

Note that it removes a call to 'new-kernel-pkg --rpmposttrans' : that's the problem. That call was added to fix https://bugzilla.redhat.com/show_bug.cgi?id=922988 back in F19 cycle. We're not sure why removing it hasn't had worse consequences (like bringing that bug back), but we think removing it *has* caused this bug. The script that generates rescue initramfs is /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh . This is only run when new-kernel-pkg is called with --rpmposttrans , it's not run with the set of options that anaconda currently calls new-kernel-pkg with.

A kernel update 'fixes' the bug because new-kernel-pkg --rpmposttrans *is* called when a new kernel is installed.

Note that we think this bug is probably restricted to live installs only; in a non-live install, the kernel RPM scripts will be called, so new-kernel-pkg --rpmposttrans will be called that way and the rescue initramfs generated. But in a live image install, as no actual RPM package transactions take place, RPM scripts don't get run.

Bouncing back to anaconda, and to bcl, since he broke it :)

Comment 24 KitchM 2013-10-11 14:01:30 UTC
Does that include network installs?

Comment 25 Adam Williamson 2013-10-11 14:14:10 UTC
Kitch: no. If you are seeing this with a non-live F19 install it is certainly not due to the above problem. That would be something different, so please track it separately. I haven't yet tested if a normal F19 install has the same symptom for me. The fact that it still doesn't work for you after a 'normal' kernel package install is a further indication that you're seeing a different problem.

Comment 26 KitchM 2013-10-11 15:07:14 UTC
And yet all the indications are that it is exactly the same issue.  Please read #13 above.

Comment 27 Chris Murphy 2013-10-11 15:34:37 UTC
(In reply to Harald Hoyer from comment #22)
> WORKSFORME

It sounds like this bug is restricted to Live Desktop in that case. It definitely always fails, on baremetal or qemu/kvm from Live Desktop.

Comment 28 KitchM 2013-10-11 16:24:31 UTC
Sorry if I don't understand; but if you say so.;)

Comment 29 Adam Williamson 2013-10-11 16:53:02 UTC
chris: it clearly *is* restricted to live images, and I explained exactly why in c#23. harald and I are both happy with that explanation.

Comment 30 Adam Williamson 2013-10-11 16:55:47 UTC
Kitch: um, no, all the indications are that it's completely different.

Your failure affects kernels installed as RPMs after initial system install: the one in this bug does not. In your case, you appear to have an initramfs image for the affected kernel: in this bug, there is not such an image. There's really nothing at all in common between the two bugs except that the highest level symptom is similar: the rescue kernel fails to boot. All the other details are different. Please just follow up in your bug report, and not this one. Thanks.

Comment 31 Brian Lane 2013-10-11 18:52:46 UTC
Created attachment 811343 [details]
patch

Here's what was happening:

I dropped the rpmposttrans because it was making the rescue image show up first. I failed to actually try the rescue boot entry, sorry about that.

The /etc/machine-id from the live image was being copied over, so all the live installs had the same id. I'm now skipping that in the rsync.

livemedia-creator includes the vmlinuz rescue but not the initrd, which was picked up by the bootloader install. that's why the initrd line was missing. livecd-creator shouldn't be including the rescue vmlinuz or initrd. For now I'm also not copying them in the rsync.

rpmposttrans actually needs to be called before the bootloader config is written, it assumes it is the first thing created so it ends up at the start of the boot order. Moved it to be called in postInstall for live. It isn't needed for mirror installs.

I've tested with live Beta TC2 and a netboot.iso install.

Comment 32 Fedora Update System 2013-10-11 22:06:29 UTC
anaconda-20.25-1.fc20, python-blivet-0.23-1.fc20, pykickstart-1.99.42-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/FEDORA-2013-18731/python-blivet-0.23-1.fc20,pykickstart-1.99.42-1.fc20,anaconda-20.25-1.fc20

Comment 33 Fedora Update System 2013-10-12 02:27:35 UTC
Package anaconda-20.25-1.fc20, python-blivet-0.23-1.fc20, pykickstart-1.99.42-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-20.25-1.fc20 python-blivet-0.23-1.fc20 pykickstart-1.99.42-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18731/python-blivet-0.23-1.fc20,pykickstart-1.99.42-1.fc20,anaconda-20.25-1.fc20
then log in and leave karma (feedback).

Comment 34 Fedora Update System 2013-10-15 06:35:22 UTC
anaconda-20.25-1.fc20, python-blivet-0.23-1.fc20, pykickstart-1.99.42-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 35 Chris Murphy 2013-10-15 16:26:38 UTC
Confirm fix in Fedora-20-Beta-TC4-x86_64-DVD.iso which has anaconda-20.25-1.fc20, python-blivet-0.23-1.fc20, pykickstart-1.99.42-1.fc20. I can further vouch for usefulness of this working upon install, in bug 1013767 the regular initramfs causes boot failure with rootfs on thinp, whereas the rescue one succeeds.


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