This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 738085 - Patch to reduce spurious Xen entries in grub menu
Patch to reduce spurious Xen entries in grub menu
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
16
Unspecified Linux
unspecified Severity low
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Patch
: 739134 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-13 16:43 EDT by Andy Burns
Modified: 2013-02-13 16:09 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 912791 (view as bug list)
Environment:
Last Closed: 2013-02-13 16:09:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch to suppress spurious xen grub menu entries (700 bytes, patch)
2011-09-13 16:43 EDT, Andy Burns
no flags Details | Diff
Sample grub.cfg (8.22 KB, text/plain)
2011-11-23 01:13 EST, Kyle
no flags Details

  None (edit)
Description Andy Burns 2011-09-13 16:43:29 EDT
Created attachment 523003 [details]
Patch to suppress spurious xen grub menu entries

Description of problem:

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

Version-Release number of selected component (if applicable):
grub2.x86_64      1:1.99-5.fc16

How reproducible:
always

Steps to Reproduce:
1. run grub2-mkconfig > /boot/grub2/grub.cfg
2. inspect results

Actual results:
too many menu entries

Expected results:
just the correct number of menu entries
Comment 1 Fedora Admin XMLRPC Client 2011-09-16 15:08:33 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 Jerry Amundson 2011-09-20 22:28:27 EDT
*** Bug 739134 has been marked as a duplicate of this bug. ***
Comment 3 Andy Burns 2011-09-21 02:09:16 EDT
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?
Comment 4 Konrad Rzeszutek Wilk 2011-09-29 17:04:22 EDT
hmm, your patch somehow makes "module initramfs.cpio.gz" go away (not good)
Comment 5 Andy Burns 2011-09-29 17:34:56 EDT
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.
Comment 6 Konrad Rzeszutek Wilk 2011-09-29 17:57:41 EDT
(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.
Comment 7 Mads Kiilerich 2011-10-24 10:41:51 EDT
(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.
Comment 8 Andy Burns 2011-10-24 11:16:00 EDT
(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.
Comment 9 Mads Kiilerich 2011-10-24 12:40:12 EDT
(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?
Comment 10 Andy Burns 2011-10-24 13:34:08 EDT
(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?
Comment 11 Andy Burns 2011-10-24 13:37:09 EDT
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.
Comment 12 Kyle 2011-11-23 01:13:07 EST
Created attachment 535354 [details]
Sample grub.cfg

Comment 7 asked for a sample grub.cfg showing the problem.
Comment 13 Mads Kiilerich 2011-11-23 06:29:52 EST
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
Comment 14 Konrad Rzeszutek Wilk 2012-03-23 17:04:20 EDT
So is this BZ still an issue with F17?
Comment 15 Mads Kiilerich 2012-04-16 17:16:49 EDT
(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.
Comment 16 Andy Burns 2012-04-16 17:34:23 EDT
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.
Comment 17 Mads Kiilerich 2012-04-16 17:56:21 EDT
(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.
Comment 18 Fedora End Of Life 2013-01-16 11:56:47 EST
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
Comment 19 Fedora End Of Life 2013-02-13 16:09:35 EST
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.

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