+++ This bug was initially created as a clone of Bug #1215839 +++ 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: --- Additional comment from Chris Murphy on 2015-04-27 18:05:53 EDT --- --- Additional comment from Chris Murphy on 2015-04-27 18:06:06 EDT --- --- Additional comment from Chris Murphy on 2015-04-27 18:06:21 EDT --- --- Additional comment from Chris Murphy on 2015-04-27 18:06:54 EDT --- This is the initial grub.cfg created by grub2-mkconfig. --- Additional comment from Chris Murphy on 2015-04-27 18:07:35 EDT --- This is the grubby modified grub.cfg, after Finish Configuration completes. --- Additional comment from Chris Murphy on 2015-04-27 18:32:44 EDT --- Happens when not encrypted too. --- Additional comment from Fedora Blocker Bugs Application on 2015-04-27 18:35:57 EDT --- 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. --- Additional comment from Adam Williamson (Fedora) on 2015-04-27 19:25:33 EDT --- 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. --- Additional comment from Adam Williamson (Fedora) on 2015-04-27 19:28:24 EDT --- 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 --- Additional comment from Adam Williamson (Fedora) on 2015-04-27 19:31:02 EDT --- 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)' --- Additional comment from Adam Williamson (Fedora) on 2015-04-27 19:36:49 EDT --- 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. --- Additional comment from Adam Williamson (Fedora) on 2015-04-27 19:59:45 EDT --- 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. --- Additional comment from Adam Williamson (Fedora) on 2015-04-27 20:01:40 EDT --- 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 . --- Additional comment from Peter Jones on 2015-04-28 12:52:47 EDT --- 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. --- Additional comment from Fedora Update System on 2015-04-28 16:35:37 EDT --- 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 --- Additional comment from David Gay on 2015-04-28 17:44:49 EDT --- 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 --- Additional comment from Fedora Update System on 2015-04-30 07:42:01 EDT --- 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). --- Additional comment from Adam Williamson on 2015-04-30 22:36:12 EDT --- Confirmed good in Final TC1. --- Additional comment from Fedora Update System on 2015-05-02 14:06:11 EDT --- 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. --- Additional comment from Andre Robatino on 2015-05-11 06:22:59 EDT --- This has still not taken effect in Rawhide. Anyone know why? --- Additional comment from Andre Robatino on 2015-05-11 06:36:45 EDT --- 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 --- Additional comment from Adam Williamson on 2015-05-11 14:00:22 EDT --- I'd probably rather file a separate bug on the build failure.
Adam said in IRC that I probably shouldn't have created a clone. The problem here is merely that the build http://koji.fedoraproject.org/koji/buildinfo?buildID=631502 for grub2 in Rawhide failed, even though the corresponding build succeeded in F22 and fixed the original bug.
Proposing as a F23 Alpha Blocker by the same criteria as cited in https://bugzilla.redhat.com/show_bug.cgi?id=1215839#c7 (although the F23 Alpha Release Criteria page doesn't exist yet, so I'm using https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Expected_installed_system_boot_behavior ): 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.
+1 blocker, for the record.
Discussed at today's blocker review meeting [1]. This bug was accepted as blocker: This bug is a clear violation of the Alpha criterion: "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." [1] http://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-06-22/
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
I pushed a fix to the build (disable hardened flags) but as the package needs signing I can't push an official build. Scratch here if someone wants to test http://koji.fedoraproject.org/koji/taskinfo?taskID=10406124
We got an f23 build tagged before freeze: grub2-2.02-0.17.fc23 so this is closed. #1215839 has not been observed in any F23 testing lately.