Bug 1215839 - grub2-mkconfig needs to use stanza titles that are like the titles we use elsewhere
Summary: grub2-mkconfig needs to use stanza titles that are like the titles we use els...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F22FinalBlocker 1220517
TreeView+ depends on / blocked
 
Reported: 2015-04-27 22:05 UTC by Chris Murphy
Modified: 2015-05-11 18:06 UTC (History)
13 users (show)

Fixed In Version: grub2-2.02-0.16.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1220517 (view as bug list)
Environment:
Last Closed: 2015-05-02 18:06:11 UTC
Type: Bug


Attachments (Terms of Use)
anaconda.log (23.67 KB, text/plain)
2015-04-27 22:05 UTC, Chris Murphy
no flags Details
program.log (43.82 KB, text/plain)
2015-04-27 22:06 UTC, Chris Murphy
no flags Details
storage.log (165.29 KB, text/plain)
2015-04-27 22:06 UTC, Chris Murphy
no flags Details
grub.cfg before finish config (3.67 KB, text/plain)
2015-04-27 22:06 UTC, Chris Murphy
no flags Details
grub.cfg modified (3.69 KB, text/plain)
2015-04-27 22:07 UTC, Chris Murphy
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1153410 None None None Never

Internal Links: 1153410

Description Chris Murphy 2015-04-27 22:05:28 UTC
Description of problem: Live anaconda installs lack an initramfs file at the time grub2-mkconfig is called, so the grub.cfg lacks an initrd line which grubby is supposed to add. But it's not doing this, results in a kernel panic after new installations.


Version-Release number of selected component (if applicable):
Fedora-Live-Workstation-x86_64-22-20150427.iso
grubby-8.40-1.fc22.x86_64
anaconda-22.20.9-1

How reproducible:
Always


Steps to Reproduce:
1. Destination installation: select 1x drive, automatic partition, encrypt
2. Begin installation

Actual results:

Reboot after installation fails, kernel panic.
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)


Expected results:

Should boot.


Additional info:

Comment 1 Chris Murphy 2015-04-27 22:05:53 UTC
Created attachment 1019445 [details]
anaconda.log

Comment 2 Chris Murphy 2015-04-27 22:06:06 UTC
Created attachment 1019446 [details]
program.log

Comment 3 Chris Murphy 2015-04-27 22:06:21 UTC
Created attachment 1019447 [details]
storage.log

Comment 4 Chris Murphy 2015-04-27 22:06:54 UTC
Created attachment 1019448 [details]
grub.cfg before finish config

This is the initial grub.cfg created by grub2-mkconfig.

Comment 5 Chris Murphy 2015-04-27 22:07:35 UTC
Created attachment 1019449 [details]
grub.cfg modified

This is the grubby modified grub.cfg, after Finish Configuration completes.

Comment 6 Chris Murphy 2015-04-27 22:32:44 UTC
Happens when not encrypted too.

Comment 7 Fedora Blocker Bugs Application 2015-04-27 22:35:57 UTC
Proposed as a Blocker for 22-final by Fedora user chrismurphy using the blocker tracking app because:

 This is a case of a DOA installation (happens with automatic and manual partitioning).
Alpha requirements violated:
 A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility.
A system installed without a graphical package set must boot to a state where it is possible to log in through at least one of the default virtual consoles.

Comment 8 Adam Williamson (Fedora) 2015-04-27 23:25:33 UTC
Yeah, I can reproduce this with an all-defaults install from the same nightly live - https://kojipkgs.fedoraproject.org/work/tasks/8204/9578204/Fedora-Live-Workstation-x86_64-22-20150427.iso .

The anaconda build in the image is the same as in Beta - 22.20-9 - so it is indeed most likely a change in grubby. Beta had grubby 8.35-9, this image has 8.40-1.

+1 blocker.

Comment 9 Adam Williamson (Fedora) 2015-04-27 23:28:24 UTC
Verbose output from new-kernel-pkg:

[root@localhost /]# new-kernel-pkg -v --mkinitrd --dracut --depmod --update 4.0.0-1.fc22.x86_64
initrdfile is /boot/initramfs-4.0.0-1.fc22.x86_64.img
devtreedir is 
running depmod for 4.0.0-1.fc22.x86_64
creating initrd: dracut  -f /boot/initramfs-4.0.0-1.fc22.x86_64.img 4.0.0-1.fc22.x86_64
found /boot/initramfs-4.0.0-1.fc22.x86_64.img and using it with grubby
/etc/grub.conf does not exist, not running grubby
updating 4.0.0-1.fc22.x86_64 from /boot/grub2/grub.cfg
- Making a normal entry.
/boot/efi/EFI/fedora/grub.cfg does not exist, not running grubby
/etc/lilo.conf does not exist, not running grubby
/boot/boot.scr does not exist, not setting up 
/boot/extlinux/extlinux.conf does not exist, not running grubby

Comment 10 Adam Williamson (Fedora) 2015-04-27 23:31:02 UTC
sh -x shows the grubby call as:

/sbin/grubby --grub2 -c /boot/grub2/grub.cfg --update-kernel=/boot/vmlinuz-4.0.0-1.fc22.x86_64 --initrd /boot/initramfs-4.0.0-1.fc22.x86_64.img '--args= LANG=en_US.UTF-8' '--title=Fedora (4.0.0-1.fc22.x86_64) 22 (Twenty Two)'

Comment 11 Adam Williamson (Fedora) 2015-04-27 23:36:49 UTC
And I can confirm that after downgrading grubby to 8.35-9, the same grubby command results in an initrd16 line appearing in grub.cfg.

Comment 12 Adam Williamson (Fedora) 2015-04-27 23:59:45 UTC
Aha. This is basically a resurrection of https://bugzilla.redhat.com/show_bug.cgi?id=1153410 .

There is a change in upstream grubby:

https://github.com/rhinstaller/grubby/commit/c3b1511221a5f542ae8b5691bcc5049249b9d29f

which was initially backported to Fedora's 8.35 build (along with most of the other changes since 8.35 was released), but it appears to have caused this problem; the backport was dropped to fix #1153410. But as soon as we bumped the package to 8.37, we got this change back as it's in upstream releases 8.36 and later.

Either we need to patch Fedora's 8.40 package to revert that change, or it needs to be dropped upstream (until it works right) and an 8.41 release made.

Comment 13 Adam Williamson (Fedora) 2015-04-28 00:01:40 UTC
Ah, this commit is also involved:

https://github.com/rhinstaller/grubby/commit/5c3bc267ba244478284c7879c7197aad168766e6

*both* those changes were backed out between grubby 8.35-6 and 8.35-7 .

Comment 14 Peter Jones 2015-04-28 16:52:47 UTC
Can you give an install with grubby-8.40 and the grub2 build at http://koji.fedoraproject.org/koji/taskinfo?taskID=9587635 a shot?  They work for me locally.

Comment 15 Fedora Update System 2015-04-28 20:35:37 UTC
grub2-2.02-0.16.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/grub2-2.02-0.16.fc22

Comment 16 David Gay 2015-04-28 21:44:49 UTC
Discussed at the 2015-04-28 blocker review meeting.[1] Voted as AcceptedBlocker.

Violates "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."[2]

[1]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-28/
[2]: https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Expected_installed_system_boot_behavior

Comment 17 Fedora Update System 2015-04-30 11:42:01 UTC
Package grub2-2.02-0.16.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing grub2-2.02-0.16.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-7236/grub2-2.02-0.16.fc22
then log in and leave karma (feedback).

Comment 18 Adam Williamson 2015-05-01 02:36:12 UTC
Confirmed good in Final TC1.

Comment 19 Fedora Update System 2015-05-02 18:06:11 UTC
grub2-2.02-0.16.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Andre Robatino 2015-05-11 10:22:59 UTC
This has still not taken effect in Rawhide. Anyone know why?

Comment 21 Andre Robatino 2015-05-11 10:36:45 UTC
Ah, there were new builds of grub2 to fix this on 4/28, the F22 build succeeded and the Rawhide build failed. No Rawhide builds after that. Should this be reopened for Rawhide? (But removing the blocker status since it's fixed in F22.)

http://koji.fedoraproject.org/koji/buildinfo?buildID=631502

Comment 22 Adam Williamson 2015-05-11 18:00:22 UTC
I'd probably rather file a separate bug on the build failure.

Comment 23 Andre Robatino 2015-05-11 18:06:18 UTC
Cloned as https://bugzilla.redhat.com/show_bug.cgi?id=1220517 .


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