Description of problem: After update to kernel 3.14.0-0.rc5.git2.1.fc21.x86_64, boot fails with the above message. Version-Release number of selected component (if applicable): 3.14.0-0.rc5.git2.1.fc21.x86_64 How reproducible: Every time Steps to Reproduce: 1. Reboot system 2. 3. Actual results: Boot is aborted Expected results: Grub2 start Additional info: Possibly related to 976768, but I believe that this may be a kernel problem. My system is not EFI, so the comments in 976768 re. EFI are not relevant. However, I do have a dual-drive system with Fedora 20 installed in a single partition on sdb and Rawhide on a raid-1 array of partitions on sda and sdb. The sda drive MBR is created with the grub2-install /dev/sda on the Rawhide system, and the MBR on sdb by a grub2-install /dev/sdb on the Fedora 20 system. The BIOS boot order is sda with fall-over to sdb. After the last kernel update, the boot from sda fails with the "alloc magic" error, and, when I press "any key," the BIOS moves to the sdb MBR, which boots with no problem. The reason I think that this is a kernel issue rather than a grub one is that, when I replace the F20 grub.cfg file with the Rawhide one, grub has no problem booting using that configuration file. As far as I can see (via a grep grub /var/log/yum.log) grub has not been modified on either system. (grubby has, but I don't use the grubby mods to the grub.cfg file. I always run grub2-mkconfig when after any kernel update.) It is, of course, possible that the grub2 code in the MBR is expecting the "magic" to be available in some specific location that's been altered. (I don't think that's very likely, but, perhaps the grub2-install code needs a "tweak" if it's changing things in the secondary file it loads.)
If you're seeing that error message, the kernel isn't even started. If there's something particular about the kernel binary being loaded that hiccups grub that would be interesting to know but it would still be a grub issue.
Yes, I hadn't thought that through. If the MBR is bonked, clearly it isn't a kernel issue. I've been looking for differences between GRUB on my two systems, and noticed something strange: (Note: My F-20 root is mounted as /Fedora; / is Rawhide) # diff `locate -b grub2-mkimage` Binary files /Fedora/usr/bin/grub2-mkimage and /usr/bin/grub2-mkimage differ # ll `locate -b grub2-mkimage` -rwxr-xr-x. 1 root root 188792 Aug 10 2013 /Fedora/usr/bin/grub2-mkimage -rwxr-xr-x. 1 root root 188648 Aug 10 2013 /usr/bin/grub2-mkimage # file `locate -b grub2-mkimage` /Fedora/usr/bin/grub2-mkimage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=01d5b3f3758aa65de83b13885e723c0288b34147, stripped /usr/bin/grub2-mkimage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=01d5b3f3758aa65de83b13885e723c0288b34147, stripped How is it that the binaries a different when the build ID sha1 values are identical? Not that it makes any difference: replacing all the grub2* files in /usr/bin with copies from my /Fedora/usr/bin and rerunning the grub2-install script still produced an unbootable MBR with the same error message. Another attempt: I booted into the F-20 system and ran grub2-install from there, pointing it to the Rawhide /boot. No joy: The MBR was still unbootable. (Tried this two ways: Once with a -d pointing to the Rawhide /boot/grub2 directory, once without a -d option.) All of the above seams to suggest grub has hard-coded something about the kernel that has been changed. By the way, I made a mistake with the -d value the first time I tried it, and GRUB had no problem booting into rescue mode, so the problem is only, I think, in the "magic number" check.
I think I may have found the source to my problem. (But I hope I haven't!) During my last Rawhide update I noticed an message I hadn't seen before: grub2-editenv: error: environment block too small. So I checked this and, sure enough, grubenv was only 968 bytes. After I fixed that so it was 1024 bytes, the reboot using /dev/sda executed flawlessly. Now, if that was, in fact, the cause of an unbootable MBR, I'd be VERY surprised. But, for whatever reason (maybe the rc7 kernel fixed something?), my system now seems, once again, to be bootable from either MBR. (I.e., sda or sdb) (I also noticed, in /var/log/messages, that grub2 is now running at a higher debug level, but that, too, should not have had any impact on an unbootable MBR.) Note: I did NOT rerun "grub-install /dev/sda" so, theoretically, nothing has been changed in the MBR on that device. Thus, a device that was unbootable earlier this morning is now bootable. (So, is it true that Linux is magic? Or just Fedora? Or is this just a Heisenbug?)
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.