grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support for howmany option in grub2


From: jezz
Subject: Re: Support for howmany option in grub2
Date: Sat, 3 Oct 2009 12:38:22 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Pá  2.říj, address@hidden wrote:
> On Fri, Oct 2, 2009 at 3:53 PM, Robert Millan <address@hidden> wrote:
> > On Sun, Sep 27, 2009 at 08:04:51PM +0200, address@hidden wrote:
> >> Hello,
> >> I am using Debian GNU/Linux as my primary system. As a loader I am using 
> >> GRUB.
> >> Actually I have upgraded to GRUB2. I don't know, if it was feature of 
> >> original
> >> (legacy) GRUB or it was functionality provided by debian scripts 
> >> (update-grub),
> >> for generating menu.lst. There was feature - howmany. This option specifies
> >> number of kernels, that user wants to have in boot menu. Script, that 
> >> modifies
> >> menu.lst, use this variable. I like this feature, because I have usually 
> >> more
> >> kernels, but I want to see only last two versions in GRUB menu. I have 
> >> created
> >> patch, that add support for this to /etc/grub.d/10_linux. I have created 
> >> this
> >> patch against version shipped with Debian (1.97~beta3-1) - I don't know if
> >> there are some Debian specific modifications. Also there should be variable
> >> GRUB_HOW_MANY propagated from /etc/default/grub (my patch don't do
> >> this).
> >> Kernel and it's rescue variant is counted as one kernel.
> >>
> >> I have already reported this bug to Debian BTS:
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548600
> >
> > Does anyone else think we want an option for this?  It seems like "feature
> > creep".
> 
> IMO this is the responsibility of the distro.  The distro's package
> manager is presumably what adds and removes kernels, there's no way
> that the grub scripts should be expected to know when past kernels
> have been removed.
> 
> With more manual-install oriented distros like gentoo, trying to have
> grub maintain the kernel list like this would be insane, since the
> local admin determines the naming convention.
> 
I thought that 10_linux script belongs to debian, so I have reported this
enhancement to debian first. Now I know, that this script is distributed with
grub. Debian developer suggests me to submit this to upstream.

I know, that distribution is responsible for adding/removing kernels. That is
the standard way - if I have two kernels installed, then I have two kernels in
menu. With old grub (and debian infrastructure) I have option to limit number
of kernels in menu. So I have three kernels, but only two kernels in menu.
With grub it is possible to boot kernel not listened in configuration - this
was my use case.

This feature means only to modify shell script - grub is not modified. And it
is really simple modification. The script is already doing some black magic -
sorting list of kernels by version. When you add limit then you will have last
two (or what is configured) kernels in menu.

> >
> > --
> > Robert Millan
> >
> >  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
> >  how) you may access your data; but nobody's threatening your freedom: we
> >  still allow you to remove your data and not access it at all."
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel

-- 
Jezz
mail:   address@hidden
jabber: address@hidden

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]