Bug 738085

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

*** Bug 739134 has been marked as a duplicate of this bug. ***

Additionally, I notice that when a new kernel is installed, the grub2.cfg file is regnerated, but that instead of using sub-menus, all te Xen entries are moed tot he topp menu, if I subsequently regenrate it with grub2-mkconfig it recreates it with the submenu.

Is the %post processing of the kernel rpms using a separate menthod to recreate the grub2.cfg?

hmm, your patch somehow makes "module initramfs.cpio.gz" go away (not good)

I can't see how that patch would do that, but I did have another patch that dealt with missing initramfs

https://bugzilla.redhat.com/attachment.cgi?id=522992&action=diff

but then I realised someone else had a very similar patch, so I DUPE'd mine

I've never seen a distro use .cpio.gz but it cold easily be added to the list in that section of code.

(In reply to comment #4)
> hmm, your patch somehow makes "module initramfs.cpio.gz" go away (not good)

Ignore that. I did not have grub2-1.99-6.fc16.x86_64 installed, but the earlier version.

(In reply to comment #0)
> The 20_linux_xen helper for grub2-mkconfig generates sub menus for each file
> matching /boot/xen* this includes symlinks and symbol files which result in
> either duplicates or non-bootable grub menu entries

(FWIW, I don't use XEN and I think this bug report could be improved by attaching a xen grub.cfg with the wrong entries.)

(In reply to comment #3)
> Additionally, I notice that when a new kernel is installed, the grub2.cfg file
> is regnerated, but that instead of using sub-menus, all te Xen entries are moed
> tot he topp menu, if I subsequently regenrate it with grub2-mkconfig it
> recreates it with the submenu.
> 
> Is the %post processing of the kernel rpms using a separate menthod to recreate
> the grub2.cfg?

Yes, kernel rpms update grub2.cfg using grubby, and grubby do apparently not support grub2 submenus. That should probably be filed as a separate grubby bug (with a sample grub.cfg attached).

An alternative solution could be to patch 20_linux_xen so it no longer uses submenus.

(In reply to comment #7)

> I don't use XEN and I think this bug report could be improved by
> attaching a xen grub.cfg with the wrong entries.

will do.

> kernel rpms update grub2.cfg using grubby, and grubby do apparently not
> support grub2 submenus. That should probably be filed as a separate grubby bug
> (with a sample grub.cfg attached).
> 
> An alternative solution could be to patch 20_linux_xen so it no longer uses
> submenus.

submenus are *good* not least because they let you set e.g. 

GRUB_DEFAULT="Xen 4.1.1" 

in /etc/default/grub

which will then always boot xen with the most recent kernel from the top of the submenu, in the same way that without xen, grub2 picks the most recent kernel from the top fo the mainmenu.

(In reply to comment #8)
> submenus are *good* not least because they let you set e.g. 
> 
> GRUB_DEFAULT="Xen 4.1.1" 

Do that work for you? You don't see bug 742720 ?

> in /etc/default/grub
> 
> which will then always boot xen with the most recent kernel from the top of the
> submenu, in the same way that without xen, grub2 picks the most recent kernel
> from the top fo the mainmenu.

In what way is that better or different from putting the xen entries in the main menu?

(In reply to comment #9)
> (In reply to comment #8)
> > submenus are *good* not least because they let you set e.g. 
> > 
> > GRUB_DEFAULT="Xen 4.1.1" 
> 
> Do that work for you? You don't see bug 742720 ?

Yes, performing a kernel update in isolation that bug does bite me.

Up until now it's probably been obscured to grub2 updates wiping out my /etc/default/grub changes, and grubby mangling my grub2.cfg, so I'd got into the habit of running grub2-mkconfig manually after restoring /etc/default/grub from my own copy!
 
> > in /etc/default/grub
> > 
> > which will then always boot xen with the most recent kernel from the top of the
> > submenu, in the same way that without xen, grub2 picks the most recent kernel
> > from the top fo the mainmenu.
> 
> In what way is that better or different from putting the xen entries in the
> main menu?

If the Xen entries were at the top of the main menu then it would be OK, otherwise how do I know which name or number to set GRUB_DEFAULT to?

Hah! I now see that 3.1-rc10 reverse sorted is lexically after 3.1-rc9 in the menu and submenu so I don't get the newest kernel anyway in this case.

Created attachment 535354 [details]
Sample grub.cfg

Comment 7 asked for a sample grub.cfg showing the problem.

Note that grubby will end up mangling a xen grub.cfg anyway:
Bug 744717 - Removing old kernel cleans up too much of grub.cfg (GRUB2)

The odd ordering of kernel entries is Bug 678840 - grub2 wrong sorting

So is this BZ still an issue with F17?

(In reply to comment #14)
> So is this BZ still an issue with F17?

It seems so.

I guess someone familiar with xen should post the patch upstream - and provide some analysis of typical naming of xen kernels for different linux distributions so the most appropriate filtering can be used. Skipping symlinks seems to be a separate issue that should have its own convincing arguments.

The whole of /boot/grub2/grub.cfg still seems messy to me

the initial file is is generated by grub2-mkconfig, then subsequent kernel updates use grubby to modify the existing file, rather than regenerating it, but this seems to switch back from having a Xen submenu to having top level two entries per kernel one with Xen, one without, of course to get a running system I then edit the .cfg file by hand, and from that point onwards I'm not sure if problems with subsequent updates are mine or grubby's but I seem to constantly be editing my cfg file to unbreak it.

(In reply to comment #16)
> The whole of /boot/grub2/grub.cfg still seems messy to me

You are absolutely right that it is a mess. Cleaning that mess up is a major task. But it might be feasible to turn it into a mess that mostly works.

Let's try to limit the scope of this bug to grub2-mkconfig. If that works reliably for you then you can just run that every time the kernel is updated ... and you might even be able to hack new-kernel-pkg to do it automatically for you.

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 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.

Thank you for reporting this bug and we are sorry it could not be fixed.