Bug 976768 - grub2 stops with "alloc magic is broken at 0xXXXXXX. Aborted. Press any key"
grub2 stops with "alloc magic is broken at 0xXXXXXX. Aborted. Press any key"
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-21 08:05 EDT by Stefan Becker
Modified: 2014-06-13 10:09 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-26 09:21:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stefan Becker 2013-06-21 08:05:20 EDT
Description of problem:

I've updated grub on my box with

 # grub2-install /dev/sda
 Installation finished. No error reported.

After rebooting grub load stops with

   alloc magic is broken at 0xXXXXXX.
   Aborted. Press any key

Version-Release number of selected component (if applicable):
grub2-2.00-20.fc19.x86_64

How reproducible: always


Steps to Reproduce:
1. grub2-install /dev/sda
2. reboot
3.

Actual results:
Machine no longer boots

Expected results:
Machine should go into grub menu in gfx mode

Additional info:
grub has already executed some parts of the grub.cfg file, because it switched to gfx mode (1600x900 on my laptop LCD). I.e. the message is not shown in VGA text mode.

I still have the F18 root on the same machine. Booting Fedora rescue from a USB stick, chroot into F18 system image and running "grub2-install /dev/sda" there restores grub into a working state with correct gfx mode, gfx menu & theme.
Comment 1 Stefan Becker 2013-06-28 12:09:49 EDT
Additional information:
- Dell Latitude E6420
- BIOS version A17
- BIOS mode (BIOS doesn't have UEFI)


- reproduced bug also with the following versions:
* grub2-2.00-22.fc19.x86_64
* grub2-2.00-18.fc19.x86_64


- latest version verified to work: grub2-2.00-16.fc19.x86_64 (Koji doesn't have release 17 anymore)


changes from changelog:

* Fri May 10 2013 Matthias Clasen <mclasen@redhat.com> - 2.00-18
- Move the starfield theme to a subpackage (#962004)
- Don't allow SSE or MMX on UEFI builds (#949761)

* Wed Apr 24 2013 Peter Jones <pjones@redhat.com> - 2.00-17.pj0
- Rebase to upstream snapshot.

* Thu Apr 04 2013 Peter Jones <pjones@redhat.com> - 2.00-17
- Fix booting from drives with 4k sectors on UEFI.
- Move bash completion to new location (#922997)
- Include lvm support for /boot (#906203)

So my guess is that the change to "upstream snapshot" is the root cause for this bug.
Comment 2 John Duchek 2013-08-16 08:32:04 EDT
I have the same problem.  The grub2-install /dev/sdb (in my case) did not fix the problem.  It has been doing this since I installed fedora 19 in all the kernels labeled with "Schrodinger's Cat".  It seem I am getting a version of the kernel with that label and one without that label on each kernel upgrade.  The SC version coughs up this error.  The other does not. Mine is a UEFI system.
Comment 3 Turgut Kalfaoglu 2013-08-20 01:39:25 EDT
Same issue on a Samsung laptop. After yum update today, the new fedora kernel does not boot, but last week's kernel boots.
Comment 4 Mads Kiilerich 2013-08-20 08:09:04 EDT
Can you test and verify if the problem follows the grub2 version or the kernel version?
Comment 5 John Duchek 2013-08-20 08:16:39 EDT
Doesn't it almost have to be the kernel?  My computer uses the same grub2 version, but the menu choices with "schrodinger cat" on them all give the error.  The menu choice with no SC does not. My version that is working is 3.10.5-201.fc19.x86_64.  The two later versions that I updated to do not work.  
John
grub2-install version is 2.00
Comment 6 Turgut Kalfaoglu 2013-08-20 09:12:25 EDT
It follows the kernel - that is, if If I hit the down arrow and pick an older kernel, it boots fine.
Comment 7 Stefan Becker 2013-08-20 10:30:03 EDT
(In reply to Turgut Kalfaoglu from comment #6)
> It follows the kernel - that is, if If I hit the down arrow and pick an
> older kernel, it boots fine.

This sounds like a different kind of error. In my case, after updating to the latest grub2 and installing on the disk, the machine loads grub but aborts *BEFORE* reaching the selection menu. What you are describing is that grub aborts during kernel load.

It could of course be that both have the same root cause.
Comment 8 John Duchek 2013-08-20 10:35:08 EDT
I did not go out of my way to update the grub2 program, it is running whatever the current one that yumex provided.  I did run grub2-config and grub2-install to try a fresh look, but it made no difference.  I might note that my Dell d630 laptop (dual core, 64 bit also) but running bios not UEFI has been completely updated and is having no problem running any of the kernels.
John
Comment 9 Turgut Kalfaoglu 2013-08-25 23:56:10 EDT
Just a note that this problem still continues..
Comment 10 John Duchek 2013-08-26 08:32:14 EDT
Same here. Given that this stops one from booting the computer, I think the severity should be higher than unspecified.  How does one change that to "show stopping" or severe.
John
Comment 11 giuseppe.angilella 2013-09-17 00:43:44 EDT
Same here on a Samsung Ultrabook. The problem first occurred after a kernel update (yum update), which presumably included a grub2-install, since the grub menu was modified. The problem persisted after a later kernel update.

Fortunately, I can still boot linux using a previous kernel (had to set installonly_limit=0 in /etc/yum.conf in order to prevent automatic cleaning of older kernels during updates, though).

Originally, I thought it might have to do with secure boot (which I keep disabled, otherwise I cannot even enter the grub menu, let alone choosing which kernel to boot).
Comment 12 giuseppe.angilella 2013-09-20 01:04:31 EDT
Still hanging after upgrading to kernel-3.11.1-200.fc19.x86_64 .

Last working kernel is 3.10.4-300.fc19.x86_64 .
Comment 13 Mads Kiilerich 2013-09-21 08:41:00 EDT
(In reply to giuseppe.angilella from comment #11)
> which presumably included a grub2-install, since the
> grub menu was modified.

No. grubby just patched the grub config.

So apparently, the new kernel just happens to trigger some memory corruption in grub.
Comment 14 John Duchek 2013-09-23 11:27:16 EDT
This may or may not be related to the above.  I have
 a quickly flashing message before grub2 starts that I have not been able to read.  I am running a UEFI system.  I photographed the message.
It says

error: failure reading sector 0x0 from 'hd1'  

I have not a clue which hard drive 'hd1' is since they are all /dev/sd(x).  Fedora 19 was a fresh install and it dealt with the hard drive, so I don't know why it would be having trouble.  Grub2 then won't read the kernel, but reads an older kernel as discussed above.
FWTIW,
John
Comment 15 Erik Johnson 2013-10-08 00:44:56 EDT
Chiming in that now I have this problem as well, (re)installing grub from a live cd didn't fix it...  No RAM errors either.
Comment 16 Nils Tonnätt 2013-10-23 13:34:34 EDT
I had the same problem after doing a grub2-install. The only one I could boot afterwards was the rescue kernel. I fixed the problem with

# grub2-mkconfig -o /boot/grub2/grub.cfg

Today I installed a new kernel and I have the same problem with that again. I think the kernel install scripts use something different to grub2-mkconfig because the menu entry of the new kernel looks different.
Comment 17 Maciek Borzecki 2013-11-16 07:27:05 EST
I've observed the problem on F20 after upgrade with fedup. The initial kernel upgrade from F19 to F20 was booting just find. Subsequent kernel updates on F20 broke each time with 'Alloc magic..'. Each time after regenerating grub config, the boot process went fine. So either, grub2-mkconfig in %post did not work as expected, or something else went wrong.

System is using EFI boot.
Comment 18 Radist Morse 2013-11-17 09:33:30 EST
Just got that after kernel update.

I found the error in grub.cfg: it was

initrd /boot/initramfs-3.11.8-300.fc20.x86_64.img

instead of

initrdefi /boot/initramfs-3.11.8-300.fc20.x86_64.img

After replacing the line everything went fine.
Comment 19 Elliott Sales de Andrade 2013-12-30 17:56:58 EST
I was experiencing the same problem some time after upgrading to Fedora 20. I was trying to refresh the bootloader with the F20 version as I was seeing some bugs with the existing one. I had run `yum reinstall grub2 grub2-efi` and `grub2-install --efi-directory=/boot/efi`.

The explanation in comment #18 was the hint I needed to figure it out. For whatever reason, there were two grub.cfg, one in /boot/grub2/grub.cfg and one in /boot/efi/EFI/fedora/grub.cfg. One had old stuff from F19, and one had new stuff from F20 (sorry, don't remember which was which). Somehow after all the reinstall steps, I had managed to convince grub to use the old grub.cfg resulting in it being confused.

My fix was to delete both grub.cfg files and re-create whichever one grub thought it should be using with grub2-mkconfig (which was /boot/grub2/grub.cfg in my case).
Comment 20 buzire.rhn 2014-01-21 02:15:39 EST
Same problem after upgrading a Fedora 20 kernel yesterday.
The system was upgraded from Fedora 19, then had grub reinstalled (grub2-install).
The new entry labeled "Heisenbug" doesn't boot with "alloc magic is broken". The old entries boot correctly. Latest entry has "initrd" instead of "initrdefi" as per #18.
Comment 21 John Duchek 2014-01-21 08:52:58 EST
I believe this error has been tracked down and killed.  I checked the entry as mentioned in 18, and I had it.  I put the commands in in 19 and the bug is dead.  Bravo!!!   Great work, you guys!

John
Comment 22 Mads Kiilerich 2014-01-21 09:03:18 EST
Note that the Fedora grub2 fork and its packaging do things differently than upstream. Running grub2-install on an EFI system will leave you with a non-standard setup. If it breaks in the future then you will have to fix it. If you want something that "just works" then you will have to get your system back to standard somehow.

Fedora grub2-mkconfig and grubby will use initrdefi in the grub.cfg in /boot/EFI (linked from /etc/grub2-efi.cfg) and initrd in /boot/grub2/grub.cfg (linked from /etc/grub2.cfg.) If you have the wrong kind in some of your config files then it mus tbe because your system somehow ended with with some BIOS/EFI confusion.
Comment 23 John Duchek 2014-01-21 09:13:14 EST
I installed Fed 19 on this efi system using the XFCE spin.  I have never played with the grub installation before.  The system worked ok til about the 3rd kernel update and I have had to live with this error for the last 6 months.  (first comment 8/16/13). 
If there is an error it is coming in in the standard installation.  This is the first thing that I have found that "just works".  It has to be pointing the way to an bug in the standard installation on efi systems.  (all my other computers have old style bios and show no error).

John
Comment 24 Stefan Becker 2014-01-21 10:53:51 EST
* The system I reported this error for does not have EFI (I guess from the comment that means that grub2-install is safe to use on this system then)

* as I already explained, the error I reported is *DIFFERENT* from all other comments. Updating to the bootloader from the F19 grub2 binaries after upgrading from F18 to F19 rendered the system *COMPLETELY* *UNABLE* *TO* *BOOT*. Instead of reaching the boot menu you only see the "alloc magic..." error message on the screen.

I'll try to find some time to run F20 grub2-install on this system over the weekend. The changelog shows that -19 is based on a new upstream snapshot. Maybe the error is fixed in that.
Comment 25 John Duchek 2014-01-21 13:05:58 EST
Stefan, you are correct that is different.  I was always able to go back a kernel or two and find one that would boot.  I never saw a problem like this on my non efi fedora setups (I have at least 3 of those,desktops and laptops).

Good luck!
john
Comment 26 Elliott Sales de Andrade 2014-01-21 17:03:11 EST
After an upgrade last week, I ran into the same issue again. It seems that grubby places 'linuxefi' with plain 'initrd'!

So digging into the grubby scripts a bit, I found that it determines whether to use EFI mode from the symlinks in /etc (the script being /sbin/new-kernel-pkg).

If you have a valid /etc/grub.cfg, then use GRUB1 (grubby --grub).
If you have a valid /etc/grub2.cfg, then use GRUB2 (grubby --grub2).
If you have a valid /etc/grub2-efi.cfg, use GRUB2 in EFI mode (grubby --grub2 --efi).

So, in my case, the fix (besides cleaning out stuff in comment #19) was to move /etc/grub2.cfg to /etc/grub2-efi.cfg. On the next kernel upgrade that I tested today, the new entry correctly used 'linuxefi' and 'initrdefi'.

There may still be a bug in grubby though, because in non-EFI mode (which is what happened earlier), it would use 'linuxefi'.
Comment 27 Mads Kiilerich 2014-01-21 17:26:08 EST
(In reply to Elliott Sales de Andrade from comment #26)
> There may still be a bug in grubby though, because in non-EFI mode (which is
> what happened earlier), it would use 'linuxefi'.

Are you sure that not was caused by having /etc/grub2-efi.cfg point to /boot/grub2/grub.cfg?
Comment 28 Elliott Sales de Andrade 2014-01-21 18:06:19 EST
(In reply to Mads Kiilerich from comment #27)
> (In reply to Elliott Sales de Andrade from comment #26)
> > There may still be a bug in grubby though, because in non-EFI mode (which is
> > what happened earlier), it would use 'linuxefi'.
> 
> Are you sure that not was caused by having /etc/grub2-efi.cfg point to
> /boot/grub2/grub.cfg?

No, I originally had /etc/grub2.cfg -> /boot/grub2/grub.cfg. This resulted in linuxefi+initrd.

I have now renamed /etc/grub2.cfg to /etc/grub2-efi.cfg and grubby correctly uses linuxefi+initrdefi.

The /sbin/new-kernel-pkg script does not care about the target, only whether the symlink exists. On the other hand, maybe grubby itself does care about the target location.
Comment 29 Mads Kiilerich 2014-01-21 19:34:24 EST
(In reply to Elliott Sales de Andrade from comment #28)
> No, I originally had /etc/grub2.cfg -> /boot/grub2/grub.cfg. This resulted
> in linuxefi+initrd.
> 
> I have now renamed /etc/grub2.cfg to /etc/grub2-efi.cfg and grubby correctly
> uses linuxefi+initrdefi.

But ... the EFI installed by the grub2-efi rpm will never read /boot/grub2/grub.cfg - it will read the EFI grub.cfg. If you have a grub2.efi in place that reads /boot/grub2/grub.cfg then it must have been created by manually running grub2-install while in EFI mode. No standard procedure should ever do that.
Comment 30 Elliott Sales de Andrade 2014-01-21 19:43:14 EST
(In reply to Mads Kiilerich from comment #29)
> (In reply to Elliott Sales de Andrade from comment #28)
> > No, I originally had /etc/grub2.cfg -> /boot/grub2/grub.cfg. This resulted
> > in linuxefi+initrd.
> > 
> > I have now renamed /etc/grub2.cfg to /etc/grub2-efi.cfg and grubby correctly
> > uses linuxefi+initrdefi.
> 
> But ... the EFI installed by the grub2-efi rpm will never read
> /boot/grub2/grub.cfg - it will read the EFI grub.cfg. If you have a
> grub2.efi in place that reads /boot/grub2/grub.cfg then it must have been
> created by manually running grub2-install while in EFI mode. No standard
> procedure should ever do that.

I think you're confusing me with someone else on this thread. In comment #19, I said I ran `yum reinstall grub2 grub2-efi` and when that broke things, I ran `grub2-mkinstall --efi-directory=/boot/efi`. From other comments on this thread, I realized that there were two config files, and removed the one that wasn't working. Finally, when the kernel upgrade messed things up again, I realized I needed to have a /etc/grub2-efi.cfg instead of /etc/grub2.cfg.

In any case, if grub2 works differently in EFI mode, can somebody please fix the GRUB 2 wiki page?
Comment 31 Mads Kiilerich 2014-01-21 19:49:49 EST
(In reply to Elliott Sales de Andrade from comment #30)
> I think you're confusing me with someone else on this thread.

Meh. There is apparently many different issues with similar symptoms discussed in thsis thread. I didn't try to dig into what you have said versus what others said.

> #19, I said I ran `yum reinstall grub2 grub2-efi` and when that broke
> things

I would rather say that it revealed that something already was broken.

> I ran `grub2-mkinstall --efi-directory=/boot/efi`.

That really broke things by Fedora's standard, leaving you with a "need" for /etc/grub2-efi.cfg pointing to /boot/grub2/grub.cfg.
Comment 32 Elliott Sales de Andrade 2014-01-21 19:57:22 EST
(In reply to Mads Kiilerich from comment #31)
> That really broke things by Fedora's standard, leaving you with a "need" for
> /etc/grub2-efi.cfg pointing to /boot/grub2/grub.cfg.

And what is Fedora's standard exactly?

There are three mentions of grub in the Fedora 20 Installation Guide, and all of them say /boot/grub2/grub.cfg.

http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/ch10s04.html
http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/s2-trouble-grub-command-line.html
http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/sn-medialess-editing-grub-conf.html

There is a hint of a difference on the wiki page, but it's got *two* warnings stating it could be wrong and/or out of date.
Comment 33 buzire.rhn 2014-01-22 05:11:08 EST
(In reply to Elliott Sales de Andrade from comment #32)
> And what is Fedora's standard exactly?

I'm also interested in the answer to that question.
Admittedly, my problem (#20) might be different. Initially, I have rendered my system unbootable by doing "grub2-install". I spent hours trying to find any documentation whatsoever about how to restore grub2 in EFI mode in Fedora, but couldn't.
Eventually, I "corrupted" my installation when I finally put grub.cfg in /boot/grub2.

I think a class of boot problems discussed here would be gone if (re)installing a Fedora boot loader was documented somewhere (or if Fedora was using the standard way of doing it). AFAIK breaking the boot loader is relatively common...
Comment 34 Mads Kiilerich 2014-01-22 06:09:40 EST
(In reply to Elliott Sales de Andrade from comment #32)
> And what is Fedora's standard exactly?

That is how the installer installs the system. That is the setup that we can expect package and OS upgrades to handle correctly.

> There are three mentions of grub in the Fedora 20 Installation Guide, and
> all of them say /boot/grub2/grub.cfg.
> 
> http://docs.fedoraproject.org/en-US/Fedora/20/html/Installation_Guide/
> ch10s04.html

That is true for BIOS system. The documentation has not been updated after x86 no longer is the same as BIOS. You could file a documentation bug.
Comment 35 Marcel Wysocki 2014-01-23 02:51:25 EST
same issue, after every kernel upgrade i have to re-run grub2-mkconfig and grub2-install
Comment 36 Stefan Becker 2014-01-26 09:21:37 EST
Retested on the same system with latest F20 packages:

 grub2-tools-2.00-25.fc20.x86_64
 grub2-2.00-25.fc20.x86_64
 grub2-starfield-theme-2.00-25.fc20.x86_64

I ran "grub2-install /dev/sda".

I ran "grub2-mkconfig -o grub.cfg" and updated in /boot/grub2.cfg (by hand) the few bits that have changed in the templates since the original version, using output from diff.

I can no longer reproduce the issue, i.e. with the latest grub2 binaries written into /dev/sda the machine comes up fine and the boot sequence goes into the graphical boot menu and beyond.

Closing as CURRENTRELEASE.
Comment 37 Mads Kiilerich 2014-01-26 10:28:36 EST
(In reply to Stefan Becker from comment #36)
> I ran "grub2-mkconfig -o grub.cfg" and updated in /boot/grub2.cfg (by hand)
> the few bits that have changed in the templates since the original version,
> using output from diff.

Did you mean /boot/grub2/grub.cfg ? If it doesn't work with grub2-install and
  grub2-mkconfig -o /boot/grub2/grub.cfg
(on a BIOS system) then you still have a system that probably will break at some later point.

> Closing as CURRENTRELEASE.

I doubt it was fixed changes in the grub2 package. It was probably fixed by your cleanup and reinstallation. The same result could have been achieved with an old grub2 package ... and others with the same symptions will not get a working system just by upgrading grub2.

FWIW, it sounds more like worksforme or insufficient_data.
Comment 38 Stefan Becker 2014-01-26 12:06:25 EST
(In reply to Mads Kiilerich from comment #37)
> Did you mean /boot/grub2/grub.cfg ? If it doesn't work with grub2-install and
>   grub2-mkconfig -o /boot/grub2/grub.cfg
> (on a BIOS system) then you still have a system that probably will break at
> some later point.

The original issue was with grub2-install, following the standard documentation on what steps to perform after a "fedup". See comment #1 for the version & system details.

I can't use "grub2-mkconfig -o /boot/grub2/grub.cfg", because it always destroys my menu settings, e.g. it drops --unrestricted and gfxpayload=keep. I have to write it to a temporary file and use diff & vi to update /boot/grub2/grub.cfg by hand.


> I doubt it was fixed changes in the grub2 package. It was probably fixed by
> your cleanup and reinstallation. The same result could have been achieved
> with an old grub2 package ... and others with the same symptions will not
> get a working system just by upgrading grub2.

As far as I can tell the other reporters jumped on this bug report bandwagon for unrelated issues, i.e. grub menu works, but single entries no longer boot, or corrupted grub.cfg updates on EFI system.

My issue is fixed, i.e. I can update the grub2 binaries on my boot disk using grub2-install, without making the system unbootable from that disk. That issue was 100% reproducable (see comment #1)
Comment 39 Erik Johnson 2014-02-10 03:37:53 EST
I just did a fedup to 20 from 19 and can no longer boot, grub error bad allocation magic - no menus or anything.  This after rebooting when prompted by fedup. Last time this happened I ended up erasing and rebuilding my boot partition.
Comment 40 Erik Johnson 2014-02-10 03:46:05 EST
Err, the exact message is:
Alloc magic is broken at 0xbf6a7080: fffffffc
aborted

Even when following Stefan's steps after chrooting into my installation from a live CD (yum even worked and updated grub to the exact version specified)
Comment 41 Erik Johnson 2014-02-14 22:49:04 EST
I fixed myself and think I found the issue.  Firstly I cannot cleanly do a grub2-mkconfig as I lose all of my LUKS configuration doing so.
So While pouring over the generated and fedup-modified cfg files I found this:

menuentry 'System Upgrade (fedup)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-xxxx-xxxx-xxxx-xxxx' {
        savedefault
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1  xxxx-xxxx-xxxx-xxxx
        else
          search --no-floppy --fs-uuid --set=root xxxx-xxxx-xxxx-xxxx
        fi
        linux   /vmlinuz-fedup root=/dev/mapper/luks-xxxx-xxxx-xxxx-xxxx ro quiet rhgb rd.md=0 rd.lvm=0 rd.dm=0 rd.luks.uuid=xxxx-xxxx-xxxx-xxxx LANG=en_GB.UTF-8
}
        initrd /initramfs-fedup.img
        initrd /initramfs-fedup.img
        initrd /initramfs-fedup.img
        initrd /initramfs-fedup.img
menuentry 'Fedora 19............



Notice how fedup (or whatever util it uses) added the initrd OUTSIDE the menuentry.  And added 4 (!) of them there.
Deleting these and putting just 1 under the linux def. of the fedup menu entry allowed me to update.
Comment 42 Mariusz Smykuła 2014-02-19 13:36:52 EST
I have this error after selecting newly  installed kernel 3.13 in Fedora 20. Should I open this bug or create new one?
Comment 43 Mariusz Smykuła 2014-02-19 14:19:29 EST
I have two grub.cfg files /boot/grub2/grub.cfg and and /boot/efi/EFI/fedora/grub.cfg.

Probably the first config file is used and has wrong entry:

menuentry 'Fedora (3.13.3-201.fc20.x86_64) 20 (Heisenbug)'
   ...
   linuxefi /vmlinuz-3.13.3-201.fc20.x86_64 root=UUID=08371bdb-0e64-4189-963b-f42cb83e954b ro vconsole.font=latarcyrheb-sun16  rhgb quiet LANG=pl_PL.UTF-8
   initrd /initramfs-3.13.3-201.fc20.x86_64.img
}

menuentry 'Fedora, with Linux 3.12.10-300.fc20.x86_64' 
   ...
   lnuxefi /vmlinuz-3.12.10-300.fc20.x86_64 root=UUID=08371bdb-0e64-4189-963b-f42cb83e954b ro vconsole.font=latarcyrheb-sun16  rhgb quiet
   initrdefi /initramfs-3.12.10-300.fc20.x86_64.img
}


The 'initrd' in newly created entry is wrong
Comment 44 Mads Kiilerich 2014-02-22 09:55:26 EST
(In reply to Mariusz Smykuła from comment #43)
> I have two grub.cfg files /boot/grub2/grub.cfg and and
> /boot/efi/EFI/fedora/grub.cfg.

So which one are you quoting? Which /etc/grub*.cfg symlinks do you have?
Comment 45 John Duchek 2014-02-22 10:55:33 EST
The bug returned when the new kernel was loaded using yumex yesterday.  I reedited the grub.cfg file as mentioned in my last several posts and it has gone away again.  Basically changing initrd to initrdefi
John
Comment 46 Mads Kiilerich 2014-02-22 11:33:07 EST
(In reply to John Duchek from comment #45)
> The bug returned when the new kernel was loaded using yumex yesterday.

So you are still using a custom setup that is incompatible with how Fedora does it.
Comment 47 Mariusz Smykuła 2014-03-10 12:07:00 EDT
@Mads, probably you are right. I was trying to fix my bootloader with grub2-mkconfig -o /boot/grub2/grub.cfg.

How to go back from this custom setup to normal setup? What should I do?
Comment 48 Michael J. Chudobiak 2014-03-11 08:40:00 EDT
Marius,

you should probably check your /var/log/grubby, and see if you switched from using /boot/efi/EFI/fedora/grub.cfg to /boot/grub2/grub.cfg at some point.

If so, you might need to run:

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
rm /boot/grub2/grub.cfg

and reboot.

Of course, if I'm wrong, you might end up with an unbootable system, so beware. I'm trying to untangle this mess myself...
Comment 49 Jeremy Visser 2014-06-09 01:43:06 EDT
(In reply to Michael J. Chudobiak from comment #48)
> grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
> rm /boot/grub2/grub.cfg

This doesn't seem to be correct based on my experience, despite your statement agreeing with what is stated on https://fedoraproject.org/wiki/GRUB_2#Create_a_GRUB_2_configuration — this means the documentation is likely incorrect.

If I remove my /boot/grub2/grub.cfg, but leave /boot/efi/EFI/fedora/grub.cfg in place, I get greeted by a "grub>" prompt with no menu.  I need to type "configfile (hd1,gpt3)/boot/efi/EFI/fedora/grub.cfg" in order to get the proper menu.

If I instead hit "configfile /<TAB>", the tab-complete starts listing the contents of my Fedora / partition.  I'm not sure whether this is expected behaviour (I had expected it to start listing the contents of my EFI System Partition, which contains the grub.cfg file I want it to use).

I can get GRUB to autoload the config file if I run "grub2-mkconfig -o /boot/grub2/grub.cfg" where it seems to be looking for it, but as mentioned earlier in the bug, this creates the problem where grubby modifies the file to use an "initrd" entry, not "initrdefi" entry.

This bug does not seem to be fixed.  I'm not sure whether it is a code bug or documentation bug, but after spending hours RTFM'ing I am not getting any further.

I'm not sure how well people tolerate comments like these in this bugtracker, but to be honest GRUB 2 works *much* more reliably overall in Ubuntu and Debian.  I think this is due to update-grub being much more robust than grubby.

$ rpm -q kernel grub2 grub2-efi shim grubby
kernel-3.14.5-200.fc20.x86_64
grub2-2.00-25.fc20.x86_64
grub2-efi-2.00-25.fc20.x86_64
shim-0.7-1.fc20.x86_64
grubby-8.28-1.fc20.x86_64

$ ls -l /etc/grub2.cfg /etc/grub2-efi.cfg
lrwxrwxrwx. 1 root root 22 Jun  9 15:12 /etc/grub2.cfg -> /boot/grub2/grub.cfg
lrwxrwxrwx. 1 root root 29 Jun  1 23:04 /etc/grub2-efi.cfg -> /boot/efi/EFI/fedora/grub.cfg

Note that it doesn't make sense for me to remove the symlinks /etc/grub2.cfg or /etc/grub2-efi.cfg (as suggested somewhere else I was reading today) as they are both owned by rpm, meaning an upgrade to grub2 will reinstate them:

$ rpm -qf /etc/grub2.cfg /etc/grub2-efi.cfg
grub2-2.00-25.fc20.x86_64
grub2-efi-2.00-25.fc20.x86_64
Comment 50 Brian Lane 2014-06-09 11:54:15 EDT
(In reply to Jeremy Visser from comment #49)
> (In reply to Michael J. Chudobiak from comment #48)
> > grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
> > rm /boot/grub2/grub.cfg
> 
> This doesn't seem to be correct based on my experience, despite your
> statement agreeing with what is stated on
> https://fedoraproject.org/wiki/GRUB_2#Create_a_GRUB_2_configuration — this
> means the documentation is likely incorrect.
> 
> If I remove my /boot/grub2/grub.cfg, but leave /boot/efi/EFI/fedora/grub.cfg
> in place, I get greeted by a "grub>" prompt with no menu.  I need to type
> "configfile (hd1,gpt3)/boot/efi/EFI/fedora/grub.cfg" in order to get the
> proper menu.

That doesn't seem right -- /EFI/fedora/ should be at the top of the ESP partition, it is only at /boot/efi/ after the system boots and mounts the ESP there.
Comment 51 Jeremy Visser 2014-06-13 10:09:45 EDT
My apologies — I had typed that from memory.  You are of course correct, and the actual command I type as a workaround is:

configfile (hd1,gpt3)/efi/fedora/grub.cfg

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