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 .