comments about /etc/default/grub

comments about /etc/default/grub

[Franklin PIAT]

Since the file /etc/default/grub really is about configuring update-grub
behaviour, couldn't it be renamed /etc/update-grub.conf ?
(It should be possible to source both, for transition)

The variable GRUB_DEFAULT seems to be counted from 0 currently. Couldn't
it be changed to count from 1.
(I can't think of any clever way to make a transition, though)


Could we add some comments, within /etc/default/grub (especially
GRUB_CMDLINE_LINUX, since many people will use it).


# This file is sourced by update-grub, and its variables are propagated
# to its childs in /etc/grub.d/

# Default menuentry to boot (counted from 0)
GRUB_DEFAULT=0

# Menu timeout. (GRUB_DEFAULT is booted after timeout)
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=Debian

# Parameter(s) to be appended to all Linux kernel entries 
#GRUB_CMDLINE_LINUX=


Thanks,

Franklin

Re: comments about /etc/default/grub

[Robert Millan]

On Tue, Feb 12, 2008 at 09:32:03AM +0100, Franklin PIAT wrote:
> Since the file /etc/default/grub really is about configuring update-grub
> behaviour, couldn't it be renamed /etc/update-grub.conf ?
> (It should be possible to source both, for transition)

No objection;  except, that since people are proposing to rename it, I think
it's better to wait untill that happens (which I hope is NOT soon).

> The variable GRUB_DEFAULT seems to be counted from 0 currently. Couldn't
> it be changed to count from 1.

But why?  :-)

> Could we add some comments, within /etc/default/grub (especially
> GRUB_CMDLINE_LINUX, since many people will use it).

Fine with me.  Note, however, that this file started being provided as
distro-specific (official GRUB doesn't ship it), and at least one of its
variables (GRUB_DISTRIBUTOR) is.

I suppose a distro-agnostic template should really be added, but I didn't
find an ellegant way to solve the GRUB_DISTRIBUTOR "problem".

For other reasons, I was thinking in a directory (let's call it
/etc/grub.source.d/) where add-ons are sourced rather than executed.  This
was in fact my initial motivation when writing update-grub (sigh ;-)).  My
idea was that specific programs could put POSIX sh scripts, for example with
things like:

  GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} foo=bar"

in case a specific Linux parameter is preferred for running such program.

This would also solve the GRUB_DISTRIBUTOR problem simply by setting that
variable from /etc/grub.source.d/xx_debian or so:

  GRUB_DISTRIBUTOR=Debian

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: comments about /etc/default/grub

[Franklin PIAT]

On Tue, 2008-02-12 at 12:47 +0100, Robert Millan wrote:
> On Tue, Feb 12, 2008 at 09:32:03AM +0100, Franklin PIAT wrote:

> > The variable GRUB_DEFAULT seems to be counted from 0 currently. Couldn't
> > it be changed to count from 1.
> 
> But why?  :-)

Human brain usually starts counting at 1 ;)

You will probably oppose "It's already a big leap to migrate from GRUB
Legacy to GRUB 2;  I suggest we don't make it bigger yet."
Which would be a good argument not to change that behaviour.


> > Could we add some comments, within /etc/default/grub (especially
> > GRUB_CMDLINE_LINUX, since many people will use it).
> 
> Fine with me.  Note, however, that this file started being provided as
> distro-specific (official GRUB doesn't ship it), and at least one of its
> variables (GRUB_DISTRIBUTOR) is.
> 
> I suppose a distro-agnostic template should really be added, but I didn't
> find an ellegant way to solve the GRUB_DISTRIBUTOR "problem".

I would love to remove GRUB_DISTRIBUTOR from the /etc/default/grub file,
since it's a user configuration file.

Couldn't GRUB_DISTRIBUTOR be set in /util/update-grub.in (just before
the line where ${sysconfdir}/default/grub is sourced)


> For other reasons, I was thinking in a directory (let's call it
> /etc/grub.source.d/) where add-ons are sourced rather than executed.  This
> was in fact my initial motivation when writing update-grub (sigh ;-)).  My
> idea was that specific programs could put POSIX sh scripts, for example with
> things like:
> 
>   GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} foo=bar"

There could be some file like "/etc/grub.d/C05_foo" where the "C" range
is reserved for "pre-configure". It could be generalized :
 "/etc/grub.d/H05_foo" => Header
 "/etc/grub.d/M05_foo" => Menu entries
 "/etc/grub.d/F05_bar" => Footer (???)
Or we could use subfolders, rather than letter prefix (like exim which
has /etc/exim4/conf.d/auth,  /etc/exim4/conf.d/transport ...)

But right now, _I_ don't know if we need such complexity.

> in case a specific Linux parameter is preferred for running such program.
> 
> This would also solve the GRUB_DISTRIBUTOR problem simply by setting that
> variable from /etc/grub.source.d/xx_debian or so:
> 
>   GRUB_DISTRIBUTOR=Debian


Franklin

Re: comments about /etc/default/grub

[Pavel Roskin]

On Tue, 2008-02-12 at 12:47 +0100, Robert Millan wrote:
> I suppose a distro-agnostic template should really be added, but I
> didn't
> find an ellegant way to solve the GRUB_DISTRIBUTOR "problem".
> 
> For other reasons, I was thinking in a directory (let's call it
> /etc/grub.source.d/) where add-ons are sourced rather than executed. 

Let's use the same grub.d (in /usr/local/etc for local install and
in /etc for system install).  What we need is a site template and a
vendor template.

I think the templates should be sourced before 00_header.  Maybe the
numbers should be shifted, so that we have 10_site, 20_vendor, 30_header
etc and still have gaps for more stuff.  Or the templates should have a
distinctive suffix.

The assignments should be careful to preserve already set variables.
The assignments should be written like this:

: ${GRUB_CMDLINE_LINUX=foo=bar quux=1}

In some cases, appending more stuff would be preferred, but for
GRUB_CMDLINE_LINUX, it's better to allow the earlier templates or the
environment to cancel the additions.

The site template could be installed unless it's installed already.  Or
it could be installed under a name under which it won't be sourced, and
should have an explanation how to rename it to make it work.

-- 
Regards,
Pavel Roskin

Re: comments about /etc/default/grub

[Robert Millan]

On Tue, Feb 12, 2008 at 05:55:10PM -0500, Pavel Roskin wrote:
> 
> Let's use the same grub.d (in /usr/local/etc for local install and
> in /etc for system install).  What we need is a site template and a
> vendor template.
> 
> I think the templates should be sourced before 00_header.  Maybe the
> numbers should be shifted, so that we have 10_site, 20_vendor, 30_header
> etc and still have gaps for more stuff.  Or the templates should have a
> distinctive suffix.

That would require some redesign;  note that the current process is:

  - update-grub sources /etc/default/grub
  - update-grub exports a number of predefined variables
  - update-grub execs every script in /etc/grub.d/

So right now variables set in /etc/grub.d/00_foo can't be used by
/etc/grub.d/10_bar.

> The assignments should be written like this:
> 
> : ${GRUB_CMDLINE_LINUX=foo=bar quux=1}

What does this do?  It doesn't seem to have effect when GRUB_CMDLINE_LINUX
is already set.

> In some cases, appending more stuff would be preferred, but for
> GRUB_CMDLINE_LINUX, it's better to allow the earlier templates or the
> environment to cancel the additions.

How would this work?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)

Re: comments about /etc/default/grub

[Pavel Roskin]

On Wed, 2008-02-13 at 16:56 +0100, Robert Millan wrote:
> On Tue, Feb 12, 2008 at 05:55:10PM -0500, Pavel Roskin wrote:
> > 
> > Let's use the same grub.d (in /usr/local/etc for local install and
> > in /etc for system install).  What we need is a site template and a
> > vendor template.
> > 
> > I think the templates should be sourced before 00_header.  Maybe the
> > numbers should be shifted, so that we have 10_site, 20_vendor, 30_header
> > etc and still have gaps for more stuff.  Or the templates should have a
> > distinctive suffix.
> 
> That would require some redesign;  note that the current process is:
> 
>   - update-grub sources /etc/default/grub
>   - update-grub exports a number of predefined variables
>   - update-grub execs every script in /etc/grub.d/
> 
> So right now variables set in /etc/grub.d/00_foo can't be used by
> /etc/grub.d/10_bar.

That's a good point.  Perhaps the templates should have distinctive
names.

> > The assignments should be written like this:
> > 
> > : ${GRUB_CMDLINE_LINUX=foo=bar quux=1}
> 
> What does this do?  It doesn't seem to have effect when GRUB_CMDLINE_LINUX
> is already set.

That's exactly the idea.  I wanted to keep already set variables and go
from the higher priority to the lower, i.e. environment, site template,
vendor template.

But we can probably do standard assignments, process lower priority
first and drop support for the environment.

> > In some cases, appending more stuff would be preferred, but for
> > GRUB_CMDLINE_LINUX, it's better to allow the earlier templates or the
> > environment to cancel the additions.
> 
> How would this work?

If I don't like the value for GRUB_CMDLINE_LINUX in the vendor template,
I can put a different value in the site template.  I can add or remove
parameters at will, knowing that the value in the vendor template would
have no effect.

-- 
Regards,
Pavel Roskin