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:
Created attachment 1019445 [details] anaconda.log
Created attachment 1019446 [details] program.log
Created attachment 1019447 [details] storage.log
Created attachment 1019448 [details] grub.cfg before finish config This is the initial grub.cfg created by grub2-mkconfig.
Created attachment 1019449 [details] grub.cfg modified This is the grubby modified grub.cfg, after Finish Configuration completes.
Happens when not encrypted too.
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.
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.
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
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)'
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.
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.
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 .
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.
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
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
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).
Confirmed good in Final TC1.
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.
This has still not taken effect in Rawhide. Anyone know why?
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
I'd probably rather file a separate bug on the build failure.
Cloned as https://bugzilla.redhat.com/show_bug.cgi?id=1220517 .