Grub2 boot menu not showing new kernels even after succesful mkconfig

[aldend123]

My F16 install has been downloading kernel updates, but I recently discovered they weren't being run. The img's are in /boot, but uname is showing an old version. I found that the grub2 boot menu only had one kernel, the old one that I was running.

So I did a grub2-mkconfig -o /boot/grub2/grub.cfg and it successfully detected all the updated kernels, added them to the grub.cfg. However, when I reboot, none of them are being displayed as options in the boot menu. It remains unchanged! What gives?

[aldend123]

Is it inappropriete for me to bump this? I'm really at a loss for what to try next here. Should this thread be put in a different section of the forum? Mods, feel free to move it.

[glennzo]

Originally Posted by aldend123

Is it inappropriete for me to bump this?

No big deal if it has been a day or more since your previous post.

Is there an alternative menu that contains other kernels? Can't remember what it's called, Advanced? It would be immediately below the defult selection.

[aldend123]

Originally Posted by glennzo

Is there an alternative menu that contains other kernels? Can't remember what it's called, Advanced? It would be immediately below the defult selection.

Not sure what you mean, the grub.cfg opens with
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="${saved_entry}"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}

function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}

set timeout=5
### END /etc/grub.d/00_header ###




And then follows with
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora Linux, with Linux 3.4.7-1.fc16.x86_64.debug' --class fedora --class gnu-linux --class gnu --class os {
[etc etc, entries for each kernel I have and their debug equivilent]

[glennzo]

Does the grub menu show something similar to:
Fedora
Advanced Options for Fedora
Windows

[Dutchy]

That's pretty strange.
In my case the first menuentry is the newest kernel.
Do you happen to have some kind of "weird" partition layout?

[aldend123]

Originally Posted by glennzo

Does the grub menu show something similar to:
Fedora
Advanced Options for Fedora
Windows

Nope, just lists bootable options, does not provide sub-menus/sub-sections.

Interestingly, last night I realized I hadn't "Wondered" about the fact Xen is listed as an option, and the cmdline for it is to the same hd0 as my kernel. I don't remember installing Xen when I built this install, I just assumed it was some part of the configuration with Fedora. A little googling shows that might not be the case. Can anyone explain this, or have I completely lost my memory, previously installed Xen, and completely forgot about it? I'll have to take a better look at this tonight. And even if I had installed Xen (which would be weird considering I'm almost entirely unfamiliar with it), should it be a contributing factor?

Otherwise, I thought I had a typical default lay out, single OS on a single drive.

[Dutchy]

I think you need to reinstall grub to the mbr.
Look into grub2-install (it's quite easy actually).

[aldend123]

So after checking over things a few times again, I still think I'm losing my mind. I have no idea why Xen is being mentioned at all, no evidence of it.

So I went to reinstall grub2:
grub2-install /dev/sda --no-floppy
/sbin/grub2-setup: warn: Your core.img is unusually large. It won't fit in the embedding area..
/sbin/grub2-setup: error: embedding is not possible, but this is required when the root device is on a RAID array or LVM volume.

core.img is 32455
my /boot partition is sda1, Starts @ sector 63, 204800 blocks (512/bytes a block per fdisk) -> that's ~104meg, though the disk utility reports it as twice that, I'm guessing it is using 1024 bytes per block. Don't know which to trust.
my lvm is sda2, the remainer of the drive

I repeated the cmd above but to sda1, that gives me :
/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea..
/sbin/grub2-setup: error: embedding is not possible, but this is required when the root device is on a RAID array or LVM volume.


Now I've read people recommending just applying the -force option. I love that idea Is this truly advisable? And if so, should I apply it to sda or sda1?
Also, I'm guessing it's possible that I have both a boot partition (sda1) and a /boot directory inside my LVM and my environment is simply ignoring sda1? How would I verify where /boot mapped to? I checked fstab, and I don't see any entries specifically tied to /boot. I'm assuming that means that my current /boot directory is part of the LVM. If that's true, I'll have to take back my previous claim of nothing unusual.

[stoat]

Originally Posted by aldend123

Can anyone explain this, or have I completely lost my memory, previously installed Xen, and completely forgot about it?

I don't use and have never followed the Xen business, but choosing "Virtualization" in Package Selection during installation could be an explanation that you forgot.

Originally Posted by aldend123

Now I've read people recommending just applying the -force option. I love that idea Is this truly advisable?

That --force option (two dashes, not one) just causes GRUB 2 to drop its objection to installing the boot loader without embedding core.img somewhere (in your case, the 62 unused sectors between the MBR and the first partition). If you try it and it works, all it means is that boot.img that gets installed in the MBR will have to use the core.img file in the filesystem of the boot partition instead. GRUB objects to that because boot.img finds core.img by sector address. When core.img is embedded somewhere outside a filesystem, its sector address never changes. When it uses the core.img file instead, the boot loader is subject to breakage by the core.img file being relocated to different sectors by the filesystem. This is a rare thing IMO, and something we always have lived with even with legacy GRUB and its stages. The only difference is legacy GRUB never bothered to discuss this matter with us. If the force option works, but the boot loader mysteriously gets broken someday, then manually boot the system by any available means and re-install the boot loader the same way again. IMO, anybody who uses GRUB, whether or not core.img is embedded, should learn how to emergency boot and fix the boot loader.

The --force option idea will not work if the Fedora boot partition is on a different hard drive than the one with boot.img in the MBR. This method of boot.img finding core.img in a filesystem does not work across hard drives.

Originally Posted by aldend123

And if so, should I apply it to sda or sda1?

Use sda if you want it to boot directly from BIOS. Use sda1 if you are going to use some other boot loader to boot this system (like I do).

Originally Posted by aldend123

I'm guessing it's possible that I have both a boot partition (sda1) and a /boot directory inside my LVM and my environment is simply ignoring sda1?

I doubt that is so. And I don't understand why you think that.

[aldend123]

So I tried force, on Sda, no deal. Same error as above,
/sbin/grub2-setup: warn: Your core.img is unusually large. It won't fit in the embedding area..
/sbin/grub2-setup: error: embedding is not possible, but this is required when the root device is on a RAID array or LVM volume.

I tried reinstalling grub2, rebuilt grub.cfg just in case (no different), and unplugged my other drives just to be sure that there was no problems with them. Grub2 still works just like it did before, but continues to refuse to update.

[stoat]

Well, I'm not so sure re-installing GRUB was indicated for this problem anyway. I came in during the middle of this when that idea was already underway. BTW, I guess that message means what it says (embedding of core.img is required when the root filesystem is in LVM... I didn't know that).

Backing up to the beginning, you said this...

Originally Posted by aldend123in post #1

So I did a grub2-mkconfig -o /boot/grub2/grub.cfg and it successfully detected all the updated kernels, added them to the grub.cfg. However, when I reboot, none of them are being displayed as options in the boot menu. It remains unchanged!

Is that accurate? I mean, does /boot/grub2/grub.cfg actually have the entries for all of the installed kernels? Is it possible that there is another grub.cfg file somewhere? Could you inadvertently be recreating the new grub.cfg in /boot/grub instead of /boot/grub2? Something like that maybe? There has to be some explanation for this in the absence of a tidal wave of other victims.

[aldend123]

It does have all the kernels listed, the newest is at the top. I hadn't downloaded the latest kernel at the time of posting above when I provided the snippet of the cfg file. I've done a full search for grub.cfg (and menu.lst just in case) and the only one is the correct one. There is a symbolic link called grub2.cfg in /etc, I'm guessing that's standard.

I tried grub2-script-check, it says nothing. No news is good news? Verbose just dumps grub.cfg to stdout.

[aldend123]

I'm back to my theory of having two /boot file sections.

I mounted /dev/sda1, and it has grub2 directoy with a grub.cfg that contains exactly what I am seeing at boot-up. It also contains xen kernels and the single kernel I'm booting to. It is completely different than what I'm seeing under my natural /boot.

Is there any good way to confirm what I'm thinking? Or would you agree what I'm thinking seems accurate? How do I remedy this? Adjust my fstab?

[stoat]

Originally Posted by aldend123

I mounted /dev/sda1, and it has grub2 directoy with a grub.cfg that contains exactly what I am seeing at boot-up.

I'm probably just not following along well, but if /dev/sda1 is your Fedora boot partition shouldn't it already be mounted? Try unmounting it and then use your file manager to look in the /boot folder (the boot partition's mount point). I you may find files there which disappear when /dev/sda1 is mounted to it. Anyway, that exact thing has happened before. I'm just having some trouble explaining how it could have happened in this case unless parts of the story are missing.