GRUB problem after yum update

[chrismurphy]

Just in case anyone else experiences this. Started with an install of Fedora-17-Beta-TC2-x86_64-Live-XFCE.iso which has been booting fine since TC2 came out. And just a bit ago I did a yum update. And then this happened on reboot.

(2nd is a continuation of the 1st):

http://dl.dropbox.com/u/3253801/first.png
http://dl.dropbox.com/u/3253801/second.png


Which apparently fails, because I then get this:

http://dl.dropbox.com/u/3253801/third.png

Which, is not right, it's missing the primary/default "Fedora Linux" option which should boot the newly updated and current kernel. If I choose this Advanced option, or let it time out, I get this:

http://dl.dropbox.com/u/3253801/fourth.png

Eventually it boots, but uname -r indicates 3.3.0-0.rc7.git0.3 not 3.3.0-1.

Gave grub2-mkconfig a shot:

[root@f17v chris]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.3.0-1.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-1.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc7.git0.3.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc7.git0.3.fc17.x86_64.img
Warning: Please don't use old title `Fedora Linux, with Linux 3.3.0-0.rc7.git0.3.fc17.x86_64' for GRUB_DEFAULT, use `Advanced options for Fedora Linux>Fedora Linux, with Linux 3.3.0-0.rc7.git0.3.fc17.x86_64' (for versions before 2.00) or `gnulinux-advanced-a82f4975-9e17-4a85-b167-575e1f2300bd>gnulinux-3.3.0-0.rc7.git0.3.fc17.x86_64-advanced-a82f4975-9e17-4a85-b167-575e1f2300bd' (for 2.00 or later)
done

I'm not sure what the warning is about. And I don't know what caused the failure after update in the first place. But manually running grub2-mkconfig does fix the problem, apparently. Much nicer menu system too.

Main menu:
http://dl.dropbox.com/u/3253801/main.png

Advanced menu:
http://dl.dropbox.com/u/3253801/advanced.png

[glennzo]

I ran into the same thing last night after I updated Fedora 17 on my trusty old laptop. Like you, I just ran grub2-mkconfig and am now able to boot into the newely installed kernel.

[vallimar]

I mentioned this problem in the previous grub thread.
Grubby can't handle the new format, so until they fix it,
every kernel update will cause issues. The packager really
should have seen this coming and either removed the
new layout, or at least attempted to coordinate things to
prevent such easily preventable breakage.

[DBelton]

Now that's odd.

On a fully updated system here, the only issues I had with grub2 and the new 3.3.0-1 kernel is that a grub2 update looks like it changed the location of grub-mkconfig_lib and broke the memtest86+ script in /etc/grub.d

I just changed the location from /usr/lib/grub/grub-mkconfig_lib to /usr/share/grub/grub-mkconfig_lib and don't get any issues at all with grub2.

Here is what I ran into before the change:
[root@tower20 default]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.3.0-1.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-1.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc7.git0.3.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc7.git0.3.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc6.git0.2.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc5.git3.1.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc5.git3.1.fc17.x86_64.img
/etc/grub.d/20_memtest86+: line 24: /usr/lib/grub/grub-mkconfig_lib: No such file or directory
[/code]

And after the change

[root@tower20 grub.d]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.3.0-1.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-1.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc7.git0.3.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc7.git0.3.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc6.git0.2.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc6.git0.2.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-0.rc5.git3.1.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-0.rc5.git3.1.fc17.x86_64.img
Found memtest image: /boot/elf-memtest86+-4.20
  No volume groups found
Found Windows 7 (loader) on /dev/sda1
done

[flokip]

This bug might explain some chases.
Bug 805310 - Corrupted grub2.cfg content: trailing { missing in menuentry lines

[vallimar]

Originally Posted by DBelton

On a fully updated system here, the only issues I had with grub2 and the new 3.3.0-1 kernel is that a grub2 update looks like it changed the location of grub-mkconfig_lib and broke the memtest86+ script in /etc/grub.d

The problem isn't with generating a new grub config with the new grub, but with grubby mishandling a new format grub config upon kernel update.

---------- Post added at 03:37 PM ---------- Previous post was at 03:27 PM ----------

Looks like there is a new grubby in koji -- haven't tested to see if it really fixes things.
Hopefully it does though!

[DBelton]

I updated my kernel after the last grub2 update, though. The update to kernel 3.3.0-1 was just installed. Wonder why I didn't see the bug, but some people are?

[AdamW]

Bug is https://bugzilla.redhat.com/show_bug.cgi?id=805310 .

You will only see it in the following circumstance:

Install a kernel update, with grubby below 8.11 installed, if your grub2.cfg is in the fancy new 'nested format' that's generated by grub2-mkconfig since grub2-1.99-19.fc17.

You'll only have the 'nested format' if you installed from an image that had the new grub2, or if you manually ran grub2-mkconfig after that grub2 update. If you installed with an earlier grub2, you'll have the simpler, old-style flat format grub2.cfg, and you won't see the bug. That's probably why dbelton and I didn't see it at first. I managed to reproduce in a VM with the newer-style grub2.cfg format.

grubby 8.11 does broadly fix the issue, according to my testing (details in the bug report).

[DBelton]

I noticed that it tries to load more modules, too, and causing errors on boot due to the modules not being available in /boot/grub2

these three modules kick out an error on every boot because the modules don't exist. (at least not on my system here, anyway.) Plus, why is it trying to load efi modules. This isn't a efi box. It's definitely BIOS only.

insmod efi_gop
insmod efi_uga
insmod ieee1275_fb

These modules are hardcoded into /boot/grub.d/00_header to be added to the /boot/grub2/grub.cfg file and it never even does any checking to see if they are even valid modules.

[vallimar]

They simplified their logic, instead of detecting valid modules and inserting the contents of video.lst,
they just try to load all known video modules. The errors are safe to ignore generally, it's just telling
you that it couldn't load the module. If you know which one you need, you can tell grub to only load
that one. I set this in /etc/default/grub: GRUB_VIDEO_BACKEND=efi_gop. And so only that module
gets inserted.

Also, I'm not entirely sure how they handled fonts before, but you can (now?) create a
/boot/grub2/fonts/ folder, place your (hopefully valid) pff2 fonts in there, and do a more simple
"loadfont <name>" without the extension or specifying anything else or setting root and whatnot.

Seems like good stuff, just a lot of change-up without any notice.

---------- Post added at 08:16 AM ---------- Previous post was at 08:13 AM ----------

Originally Posted by AdamW

Bug is https://bugzilla.redhat.com/show_bug.cgi?id=805310

Thanks for the better explanation and all the testing to help get this sorted!

[DBelton]

Well, I don't like any errors being generated by my bootloader. (For one, it messes up the look of the menu screen )

I can see them loading some modules that really aren't needed. But for them to try and load modules that don't even exist is different.

In this case, the errors are caused by a lazy or inept (or both) developer that didn't want to put a couple of if statements into the /etc/grub.d/00_header script to check and see if the module actually exists before sticking it into the grub.cfg file. So these errors are unacceptable.

[zuchov]

Just installed F17, alpha xfce, from a live CD (USB), and got the error message about bootloader installment. Still it worked fine after reboot, just two extra lines in the bootmenu. Hopefully it's working after that monster-first-update.. 396 updates! :-)