Debian Bug report logs - #470894
grub-installer: user parameters are not added to grub.cfg for grub2

version graph

Package: grub-installer; Maintainer for grub-installer is Debian Install System Team <debian-boot@lists.debian.org>; Source for grub-installer is src:grub-installer.

Reported by: Frans Pop <elendil@planet.nl>

Date: Fri, 14 Mar 2008 11:27:04 UTC

Severity: normal

Tags: patch

Found in version 1.55

Fixed in version grub-installer/1.42

Done: Colin Watson <cjwatson@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. Full text and rfc822 format available.

Acknowledgement sent to Frans Pop <elendil@planet.nl>:
New Bug report received and forwarded. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Frans Pop <elendil@planet.nl>
To: Debian BTS Submit <submit@bugs.debian.org>
Subject: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Fri, 14 Mar 2008 12:24:19 +0100
[Message part 1 (text/plain, inline)]
Package: grub-installer
Version: 1.55
Severity: important

Currently no user parameters (such as kernel parameters, vga=, quiet) are 
included in the generated configuration file for grub2.

This is a blocker for making grub2 default.
[signature.asc (application/pgp-signature, inline)]

Severity set to `normal' from `important' Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. (Sun, 20 Apr 2008 22:12:04 GMT) Full text and rfc822 format available.

Blocking bugs of 477094 added: 470894, 473401, 477083, 477090, and 477092 Request was from Frans Pop <elendil@planet.nl> to control@bugs.debian.org. (Sun, 20 Apr 2008 22:12:09 GMT) Full text and rfc822 format available.

Blocking bugs of 470894 added: 460843 Request was from Robert Millan <rmh@aybabtu.com> to control@bugs.debian.org. (Wed, 30 Apr 2008 11:03:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Wed, 10 Jun 2009 14:42:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Wed, 10 Jun 2009 14:42:01 GMT) Full text and rfc822 format available.

Message #16 received at 470894@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Frans Pop <elendil@planet.nl>
Cc: 470894@bugs.debian.org, grub2@packages.debian.org
Subject: Re: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Wed, 10 Jun 2009 15:39:17 +0100
On Fri, Mar 14, 2008 at 12:24:19PM +0100, Frans Pop wrote:
> Package: grub-installer
> Version: 1.55
> Severity: important
> 
> Currently no user parameters (such as kernel parameters, vga=, quiet) are 
> included in the generated configuration file for grub2.
> 
> This is a blocker for making grub2 default.

The obvious way to do this seems to be to have grub-installer put the
output of user-params in GRUB_CMDLINE_LINUX or
GRUB_CMDLINE_LINUX_DEFAULT (as appropriate) in /etc/default/grub.

That file is currently a dpkg-managed conffile, though. Do people feel
that this constitutes an intentional sysadmin change to the point where
having the installer automatically modify a conffile is acceptable? (I
think it's borderline; if it would be very inconvenient to make it not
be a dpkg-managed conffile I think it would be acceptable.)

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Thu, 11 Jun 2009 12:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 11 Jun 2009 12:03:05 GMT) Full text and rfc822 format available.

Message #21 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: Colin Watson <cjwatson@debian.org>, 470894@bugs.debian.org
Cc: Frans Pop <elendil@planet.nl>, grub2@packages.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Thu, 11 Jun 2009 13:57:36 +0200
Am Mittwoch, den 10.06.2009, 15:39 +0100 schrieb Colin Watson:
> On Fri, Mar 14, 2008 at 12:24:19PM +0100, Frans Pop wrote:
> > Package: grub-installer
> > Version: 1.55
> > Severity: important
> > 
> > Currently no user parameters (such as kernel parameters, vga=, quiet) are 
> > included in the generated configuration file for grub2.
> > 
> > This is a blocker for making grub2 default.
> 
> The obvious way to do this seems to be to have grub-installer put the
> output of user-params in GRUB_CMDLINE_LINUX or
> GRUB_CMDLINE_LINUX_DEFAULT (as appropriate) in /etc/default/grub.
> 
> That file is currently a dpkg-managed conffile, though. Do people feel
> that this constitutes an intentional sysadmin change to the point where
> having the installer automatically modify a conffile is acceptable? (I
> think it's borderline; if it would be very inconvenient to make it not
> be a dpkg-managed conffile I think it would be acceptable.)

Well policy says that conffiles and maintaing the config scripts via the
maintainer scripts must not be mixed.
Though it says also `dpkg will ask about overwriting the file every time
the package is upgraded.', which maybe just means it must not be used on
the same file. That should be made more clear in policy.

I already asked once #debian-devel if policy forbids editing of
configuration files in maintainer scripts and they said it does.
But even now I fail to find where it says that.
10.7.3 only says that on package upgrades local changes must be
preserved.

If it gets edited during grub-install by a debconf prompt then this is
a) no package upgrade and b) a local change by the sysadmin

/etc/default/grub isn't that important to update on upgrades.
Then users would just not easily see if we introduce new variables
there.
But the files in /etc/grub.d really should be upgraded.
Would it maybe help if we'd switch to use ucf for them?
-- 
Felix Zielcke





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Thu, 11 Jun 2009 14:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 11 Jun 2009 14:06:02 GMT) Full text and rfc822 format available.

Message #26 received at 470894@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Felix Zielcke <fzielcke@z-51.de>
Cc: 470894@bugs.debian.org, Frans Pop <elendil@planet.nl>, grub2@packages.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Thu, 11 Jun 2009 15:03:37 +0100
On Thu, Jun 11, 2009 at 01:57:36PM +0200, Felix Zielcke wrote:
> Am Mittwoch, den 10.06.2009, 15:39 +0100 schrieb Colin Watson:
> > On Fri, Mar 14, 2008 at 12:24:19PM +0100, Frans Pop wrote:
> > > Currently no user parameters (such as kernel parameters, vga=, quiet) are 
> > > included in the generated configuration file for grub2.
> > > 
> > > This is a blocker for making grub2 default.
> > 
> > The obvious way to do this seems to be to have grub-installer put the
> > output of user-params in GRUB_CMDLINE_LINUX or
> > GRUB_CMDLINE_LINUX_DEFAULT (as appropriate) in /etc/default/grub.
> > 
> > That file is currently a dpkg-managed conffile, though. Do people feel
> > that this constitutes an intentional sysadmin change to the point where
> > having the installer automatically modify a conffile is acceptable? (I
> > think it's borderline; if it would be very inconvenient to make it not
> > be a dpkg-managed conffile I think it would be acceptable.)
> 
> Well policy says that conffiles and maintaing the config scripts via the
> maintainer scripts must not be mixed.

Oh, it certainly does, and for good reasons (I'm a policy editor so I'm
familiar with it ;-) ). However, it's not clear to me whether that
applies to changes you've requested via installer options; is that
essentially equivalent to a manual edit? Policy is silent on that aspect
of the subject and as I said I think it's a borderline question.

(grub-installer is, of course, not a maintainer script - "maintainer
script" is a technical term in policy that refers to the preinst,
postinst, etc. scripts shipped in packages' control areas - although
perhaps that is merely a distinction of wordplay.)

> Though it says also `dpkg will ask about overwriting the file every time
> the package is upgraded.', which maybe just means it must not be used on
> the same file. That should be made more clear in policy.

I don't know what "it must not be used on the same file" means here.
Could you clarify?

> I already asked once #debian-devel if policy forbids editing of
> configuration files in maintainer scripts and they said it does.
> But even now I fail to find where it says that.
> 10.7.3 only says that on package upgrades local changes must be
> preserved.

10.7.3, immediately after the bit you just quoted:

  The easy way to achieve this behavior is to make the configuration
  file a conffile. This is appropriate only if it is possible to
  distribute a default version that will work for most installations,
  although some system administrators may choose to modify it. This
  implies that the default version will be part of the package
  distribution, and must not be modified by the maintainer scripts
  during installation (or at any other time).

Please be aware of the technical distinction between "conffile" and
"configuration file"; this discussion will get very confusing if you
blur those concepts. Policy 10.7.1 describes the distinction. Conffiles
may not be edited by maintainer scripts, but configuration files which
are not conffiles may be edited by maintainer scripts if due care is
taken.

The core reason for this prohibition is to ensure that users are not
presented with spurious prompts about resolving conffile differences
while having no idea where those differences came from; the package
management system will tell them that they made a local change when they
didn't. This causes confusion and must be avoided.

The question is whether having gone and manually typed in some extra
boot options at the end of the installer's boot: prompt can be
considered as equivalent to editing a configuration file; that is, can
we expect the user to be confused when they see dpkg's conffile prompt
or not?

I think I would be prepared to defend the claim that it doesn't really
make a difference whether they typed those boot options at the boot:
prompt or in an editor. Either way, they typed them manually, explicitly
asking for their system to behave in a different way, and so a later
conffile prompt should not be overly surprising (leaving aside the
question of whether some people will forget they made the change, which
is always going to be a problem no matter what we do).

If you, and others on this list, agree with that claim, then we can
simply go ahead and have grub-installer edit /etc/default/grub to insert
the output of user-params, on the condition that the default text - i.e.
what you get if you just press enter at the boot: prompt - is
character-for-character the same as what's in the conffile shipped in
the grub-pc package. However, if you disagree, then I think it will be
necessary to convert grub-pc (and I suppose the other grub-* binary
packages) to manage /etc/default/grub using ucf.

> /etc/default/grub isn't that important to update on upgrades.
> Then users would just not easily see if we introduce new variables
> there.
> But the files in /etc/grub.d really should be upgraded.
> Would it maybe help if we'd switch to use ucf for them?

I think you're missing my point. I'm not proposing that any change
should be made to the files in /etc/grub.d/; they are just fine the way
they are, being conffiles. /etc/default/grub is the only case in
question. Would you rather leave it as a conffile and accept the
arguable policy violation of the installer modifying it (bearing in mind
all the things I said above), or move it to be a ucf-managed
configuration file? The latter is somewhat more work from you, so I
don't want to take it for granted.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Thu, 11 Jun 2009 14:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 11 Jun 2009 14:21:02 GMT) Full text and rfc822 format available.

Message #31 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: Colin Watson <cjwatson@debian.org>
Cc: 470894@bugs.debian.org, Frans Pop <elendil@planet.nl>, grub2@packages.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Thu, 11 Jun 2009 16:18:04 +0200
Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> On Thu, Jun 11, 2009 at 01:57:36PM +0200, Felix Zielcke wrote:
> > Am Mittwoch, den 10.06.2009, 15:39 +0100 schrieb Colin Watson:
> > > On Fri, Mar 14, 2008 at 12:24:19PM +0100, Frans Pop wrote:
> > > > Currently no user parameters (such as kernel parameters, vga=, quiet) are 
> > > > included in the generated configuration file for grub2.
> > > > 
> > > > This is a blocker for making grub2 default.
> > > 
> > > The obvious way to do this seems to be to have grub-installer put the
> > > output of user-params in GRUB_CMDLINE_LINUX or
> > > GRUB_CMDLINE_LINUX_DEFAULT (as appropriate) in /etc/default/grub.
> > > 
> > > That file is currently a dpkg-managed conffile, though. Do people feel
> > > that this constitutes an intentional sysadmin change to the point where
> > > having the installer automatically modify a conffile is acceptable? (I
> > > think it's borderline; if it would be very inconvenient to make it not
> > > be a dpkg-managed conffile I think it would be acceptable.)
> > 
> > Well policy says that conffiles and maintaing the config scripts via the
> > maintainer scripts must not be mixed.
> 
> Oh, it certainly does, and for good reasons (I'm a policy editor so I'm
> familiar with it ;-) ). However, it's not clear to me whether that
> applies to changes you've requested via installer options; is that
> essentially equivalent to a manual edit? Policy is silent on that aspect
> of the subject and as I said I think it's a borderline question.
> 
> (grub-installer is, of course, not a maintainer script - "maintainer
> script" is a technical term in policy that refers to the preinst,
> postinst, etc. scripts shipped in packages' control areas - although
> perhaps that is merely a distinction of wordplay.)
> 
> > Though it says also `dpkg will ask about overwriting the file every time
> > the package is upgraded.', which maybe just means it must not be used on
> > the same file. That should be made more clear in policy.
> 
> I don't know what "it must not be used on the same file" means here.
> Could you clarify?

Sorry I meant that it isn't clear to me if policy means that mixing of
conffile with maintainer script handling of configuration is just
forbidden for the same configuartion file or if it's forbidden to mix it
always in the same package but with different configuration files
For example having /etc/grub.d/* files still as dpkg conffile
and /etc/default/grub as a maintainer script based one.

> > I already asked once #debian-devel if policy forbids editing of
> > configuration files in maintainer scripts and they said it does.
> > But even now I fail to find where it says that.
> > 10.7.3 only says that on package upgrades local changes must be
> > preserved.
> 
> 10.7.3, immediately after the bit you just quoted:
> 
>   The easy way to achieve this behavior is to make the configuration
>   file a conffile. This is appropriate only if it is possible to
>   distribute a default version that will work for most installations,
>   although some system administrators may choose to modify it. This
>   implies that the default version will be part of the package
>   distribution, and must not be modified by the maintainer scripts
>   during installation (or at any other time).
> 
> Please be aware of the technical distinction between "conffile" and
> "configuration file"; this discussion will get very confusing if you
> blur those concepts. Policy 10.7.1 describes the distinction. Conffiles
> may not be edited by maintainer scripts, but configuration files which
> are not conffiles may be edited by maintainer scripts if due care is
> taken.
> 
> The core reason for this prohibition is to ensure that users are not
> presented with spurious prompts about resolving conffile differences
> while having no idea where those differences came from; the package
> management system will tell them that they made a local change when they
> didn't. This causes confusion and must be avoided.

Ah, but /etc/kernel-img.conf is AFAICS not a dpkg conffile.
dpkg -S /etc/kernel-img.conf doestn't show any package where it belongs
to, whereas dpkg -S /etc/default/grub clearly shows grub-pc.
Anyway we solved that problem with kernel-img.conf by aborting in
preinst if it still contains /sbin/update-grub in the hooks.

> The question is whether having gone and manually typed in some extra
> boot options at the end of the installer's boot: prompt can be
> considered as equivalent to editing a configuration file; that is, can
> we expect the user to be confused when they see dpkg's conffile prompt
> or not?
> 
> I think I would be prepared to defend the claim that it doesn't really
> make a difference whether they typed those boot options at the boot:
> prompt or in an editor. Either way, they typed them manually, explicitly
> asking for their system to behave in a different way, and so a later
> conffile prompt should not be overly surprising (leaving aside the
> question of whether some people will forget they made the change, which
> is always going to be a problem no matter what we do).
> 
> If you, and others on this list, agree with that claim, then we can
> simply go ahead and have grub-installer edit /etc/default/grub to insert
> the output of user-params, on the condition that the default text - i.e.
> what you get if you just press enter at the boot: prompt - is
> character-for-character the same as what's in the conffile shipped in
> the grub-pc package. However, if you disagree, then I think it will be
> necessary to convert grub-pc (and I suppose the other grub-* binary
> packages) to manage /etc/default/grub using ucf.
> 
> > /etc/default/grub isn't that important to update on upgrades.
> > Then users would just not easily see if we introduce new variables
> > there.
> > But the files in /etc/grub.d really should be upgraded.
> > Would it maybe help if we'd switch to use ucf for them?
> 
> I think you're missing my point. I'm not proposing that any change
> should be made to the files in /etc/grub.d/; they are just fine the way
> they are, being conffiles. /etc/default/grub is the only case in
> question. Would you rather leave it as a conffile and accept the
> arguable policy violation of the installer modifying it (bearing in mind
> all the things I said above), or move it to be a ucf-managed
> configuration file? The latter is somewhat more work from you, so I
> don't want to take it for granted.
> 

Well if policy allows this which is (was?) as you can see above not
clear to me that this is allowed, then we could do this.
If I understood it correctly we'd just need to move
the /etc/default/grub to /usr/share/grub/ in the .deb and then call ucf
in the postinst to actually generate/update the /etc/default/grub one.
That wouldn't be much work but I'll ask Robert if it's okay with him.

-- 
Felix Zielcke





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Thu, 11 Jun 2009 16:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 11 Jun 2009 16:24:18 GMT) Full text and rfc822 format available.

Message #36 received at 470894@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Felix Zielcke <fzielcke@z-51.de>
Cc: 470894@bugs.debian.org, Frans Pop <elendil@planet.nl>, grub2@packages.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Thu, 11 Jun 2009 17:22:50 +0100
On Thu, Jun 11, 2009 at 04:18:04PM +0200, Felix Zielcke wrote:
> Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> > On Thu, Jun 11, 2009 at 01:57:36PM +0200, Felix Zielcke wrote:
> > > Though it says also `dpkg will ask about overwriting the file every time
> > > the package is upgraded.', which maybe just means it must not be used on
> > > the same file. That should be made more clear in policy.
> > 
> > I don't know what "it must not be used on the same file" means here.
> > Could you clarify?
> 
> Sorry I meant that it isn't clear to me if policy means that mixing of
> conffile with maintainer script handling of configuration is just
> forbidden for the same configuartion file or if it's forbidden to mix it
> always in the same package but with different configuration files
> For example having /etc/grub.d/* files still as dpkg conffile
> and /etc/default/grub as a maintainer script based one.

Policy is talking at the level of individual files. There is no problem
with having /etc/grub.d/* as conffiles and /etc/default/grub as an
ordinary configuration file.

> > 10.7.3, immediately after the bit you just quoted:
> > 
> >   The easy way to achieve this behavior is to make the configuration
> >   file a conffile. This is appropriate only if it is possible to
> >   distribute a default version that will work for most installations,
> >   although some system administrators may choose to modify it. This
> >   implies that the default version will be part of the package
> >   distribution, and must not be modified by the maintainer scripts
> >   during installation (or at any other time).
> > 
> > Please be aware of the technical distinction between "conffile" and
> > "configuration file"; this discussion will get very confusing if you
> > blur those concepts. Policy 10.7.1 describes the distinction. Conffiles
> > may not be edited by maintainer scripts, but configuration files which
> > are not conffiles may be edited by maintainer scripts if due care is
> > taken.
> > 
> > The core reason for this prohibition is to ensure that users are not
> > presented with spurious prompts about resolving conffile differences
> > while having no idea where those differences came from; the package
> > management system will tell them that they made a local change when they
> > didn't. This causes confusion and must be avoided.
> 
> Ah, but /etc/kernel-img.conf is AFAICS not a dpkg conffile.
> dpkg -S /etc/kernel-img.conf doestn't show any package where it belongs
> to, whereas dpkg -S /etc/default/grub clearly shows grub-pc.

*blink* I didn't mention /etc/kernel-img.conf, so I'm not sure where
this is coming from? You're correct that it isn't a conffile.

> Anyway we solved that problem with kernel-img.conf by aborting in
> preinst if it still contains /sbin/update-grub in the hooks.

I'm sorry to have to say this, but the kernel-img.conf /sbin/update-grub
migration has been a hopelessly confusing mess. Please don't use it as
an example of anything except how *not* to do things.

Either /sbin/update-grub should have continued to be supported forever
as a symlink without warnings, or (preferably) something should have
taken care of detecting the situation and rewriting the configuration
file automatically. Robert even suggested a way to do this in #361929,
but it was never done for some reason that is mysterious to me.
Complaining about the situation and aborting is the worst of both
worlds; it often merely throws users into confusion, or at best leaves
them cursing about how Debian didn't just sort out its own mistakes
rather than making users take care of it by hand.

I understand, of course, that there are all sorts of reasons why these
sorts of things happen at the time; but if you look at the change as a
whole then it was very clearly far from optimal.

> > I think you're missing my point. I'm not proposing that any change
> > should be made to the files in /etc/grub.d/; they are just fine the way
> > they are, being conffiles. /etc/default/grub is the only case in
> > question. Would you rather leave it as a conffile and accept the
> > arguable policy violation of the installer modifying it (bearing in mind
> > all the things I said above), or move it to be a ucf-managed
> > configuration file? The latter is somewhat more work from you, so I
> > don't want to take it for granted.
> 
> Well if policy allows this which is (was?) as you can see above not
> clear to me that this is allowed, then we could do this.
> If I understood it correctly we'd just need to move

If policy allows the installer to modify /etc/default/grub, then you
(the grub2 maintainers) don't need to do anything. That's why I asked on
this list. :-)

If policy does *not* allow the installer to modify /etc/default/grub,
then:

> the /etc/default/grub to /usr/share/grub/ in the .deb and then call ucf
> in the postinst to actually generate/update the /etc/default/grub one.
> That wouldn't be much work but I'll ask Robert if it's okay with him.

ucf is quite an advanced packaging thing with plenty of potential
complicated corners, so you should definitely check with somebody who's
done it before. :-)

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Thu, 11 Jun 2009 16:51:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Thu, 11 Jun 2009 16:51:05 GMT) Full text and rfc822 format available.

Message #41 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: Colin Watson <cjwatson@debian.org>
Cc: 470894@bugs.debian.org, Frans Pop <elendil@planet.nl>, grub2@packages.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Thu, 11 Jun 2009 18:38:05 +0200
Am Donnerstag, den 11.06.2009, 17:22 +0100 schrieb Colin Watson:
> On Thu, Jun 11, 2009 at 04:18:04PM +0200, Felix Zielcke wrote:
> > Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> > > On Thu, Jun 11, 2009 at 01:57:36PM +0200, Felix Zielcke wrote:
> > > > Though it says also `dpkg will ask about overwriting the file every time
> > > > the package is upgraded.', which maybe just means it must not be used on
> > > > the same file. That should be made more clear in policy.
> > > 
> > > I don't know what "it must not be used on the same file" means here.
> > > Could you clarify?
> > 
> > Sorry I meant that it isn't clear to me if policy means that mixing of
> > conffile with maintainer script handling of configuration is just
> > forbidden for the same configuartion file or if it's forbidden to mix it
> > always in the same package but with different configuration files
> > For example having /etc/grub.d/* files still as dpkg conffile
> > and /etc/default/grub as a maintainer script based one.
> 
> Policy is talking at the level of individual files. There is no problem
> with having /etc/grub.d/* as conffiles and /etc/default/grub as an
> ordinary configuration file.
> 
> > > 10.7.3, immediately after the bit you just quoted:
> > > 
> > >   The easy way to achieve this behavior is to make the configuration
> > >   file a conffile. This is appropriate only if it is possible to
> > >   distribute a default version that will work for most installations,
> > >   although some system administrators may choose to modify it. This
> > >   implies that the default version will be part of the package
> > >   distribution, and must not be modified by the maintainer scripts
> > >   during installation (or at any other time).
> > > 
> > > Please be aware of the technical distinction between "conffile" and
> > > "configuration file"; this discussion will get very confusing if you
> > > blur those concepts. Policy 10.7.1 describes the distinction. Conffiles
> > > may not be edited by maintainer scripts, but configuration files which
> > > are not conffiles may be edited by maintainer scripts if due care is
> > > taken.
> > > 
> > > The core reason for this prohibition is to ensure that users are not
> > > presented with spurious prompts about resolving conffile differences
> > > while having no idea where those differences came from; the package
> > > management system will tell them that they made a local change when they
> > > didn't. This causes confusion and must be avoided.
> > 
> > Ah, but /etc/kernel-img.conf is AFAICS not a dpkg conffile.
> > dpkg -S /etc/kernel-img.conf doestn't show any package where it belongs
> > to, whereas dpkg -S /etc/default/grub clearly shows grub-pc.
> 
> *blink* I didn't mention /etc/kernel-img.conf, so I'm not sure where
> this is coming from? You're correct that it isn't a conffile.
> 
> > Anyway we solved that problem with kernel-img.conf by aborting in
> > preinst if it still contains /sbin/update-grub in the hooks.
> 
> I'm sorry to have to say this, but the kernel-img.conf /sbin/update-grub
> migration has been a hopelessly confusing mess. Please don't use it as
> an example of anything except how *not* to do things.
> 
> Either /sbin/update-grub should have continued to be supported forever
> as a symlink without warnings, or (preferably) something should have
> taken care of detecting the situation and rewriting the configuration
> file automatically. Robert even suggested a way to do this in #361929,
> but it was never done for some reason that is mysterious to me.
> Complaining about the situation and aborting is the worst of both
> worlds; it often merely throws users into confusion, or at best leaves
> them cursing about how Debian didn't just sort out its own mistakes
> rather than making users take care of it by hand.
> 
> I understand, of course, that there are all sorts of reasons why these
> sorts of things happen at the time; but if you look at the change as a
> whole then it was very clearly far from optimal.

I saw that bug report now for the first time.
(I just jumped in almost exactly a year ago into the grub packages).
I thought about running sed over kernel-imf.conf too but both Robert and
me were unsure if policy allowed that and #grub-devel said so.
But if even you would prefer to just automatically edit it then we'll do
so.
I looked it up in the changelog of grub-legacy. Since the release of
etch the wrapper in /sbin/update-grub which warns the user is in place.
Though it could have mentioned that you probable need to edit
kernel-img.conf
We got a pretty recent bug report in grub2 (500631) that there is at
least one user who didn't change it yet.

> > > I think you're missing my point. I'm not proposing that any change
> > > should be made to the files in /etc/grub.d/; they are just fine the way
> > > they are, being conffiles. /etc/default/grub is the only case in
> > > question. Would you rather leave it as a conffile and accept the
> > > arguable policy violation of the installer modifying it (bearing in mind
> > > all the things I said above), or move it to be a ucf-managed
> > > configuration file? The latter is somewhat more work from you, so I
> > > don't want to take it for granted.
> > 
> > Well if policy allows this which is (was?) as you can see above not
> > clear to me that this is allowed, then we could do this.
> > If I understood it correctly we'd just need to move
> 
> If policy allows the installer to modify /etc/default/grub, then you
> (the grub2 maintainers) don't need to do anything. That's why I asked on
> this list. :-)

Ah okay, but ucf would be given us anyway the advantage of 3-way merge.
Though /etc/default/grub probable won't change that often.

> If policy does *not* allow the installer to modify /etc/default/grub,
> then:
> 
> > the /etc/default/grub to /usr/share/grub/ in the .deb and then call ucf
> > in the postinst to actually generate/update the /etc/default/grub one.
> > That wouldn't be much work but I'll ask Robert if it's okay with him.
> 
> ucf is quite an advanced packaging thing with plenty of potential
> complicated corners, so you should definitely check with somebody who's
> done it before. :-)

Luckly I remembered that dovecot switched to ucf.
Seems like they removed all the ucf upgrade stuff from the package but
the original bug report about it has the patch which handles it.
-- 
Felix Zielcke





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Sat, 13 Jun 2009 09:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Sat, 13 Jun 2009 09:09:02 GMT) Full text and rfc822 format available.

Message #46 received at 470894@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Felix Zielcke <fzielcke@z-51.de>
Cc: 470894@bugs.debian.org, Frans Pop <elendil@planet.nl>, grub2@packages.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Sat, 13 Jun 2009 10:04:01 +0100
On Thu, Jun 11, 2009 at 06:38:05PM +0200, Felix Zielcke wrote:
> Am Donnerstag, den 11.06.2009, 17:22 +0100 schrieb Colin Watson:
> > I'm sorry to have to say this, but the kernel-img.conf /sbin/update-grub
> > migration has been a hopelessly confusing mess. Please don't use it as
> > an example of anything except how *not* to do things.
> > 
> > Either /sbin/update-grub should have continued to be supported forever
> > as a symlink without warnings, or (preferably) something should have
> > taken care of detecting the situation and rewriting the configuration
> > file automatically. Robert even suggested a way to do this in #361929,
> > but it was never done for some reason that is mysterious to me.
> > Complaining about the situation and aborting is the worst of both
> > worlds; it often merely throws users into confusion, or at best leaves
> > them cursing about how Debian didn't just sort out its own mistakes
> > rather than making users take care of it by hand.
> > 
> > I understand, of course, that there are all sorts of reasons why these
> > sorts of things happen at the time; but if you look at the change as a
> > whole then it was very clearly far from optimal.
> 
> I saw that bug report now for the first time.
> (I just jumped in almost exactly a year ago into the grub packages).
> I thought about running sed over kernel-imf.conf too but both Robert and
> me were unsure if policy allowed that and #grub-devel said so.
> But if even you would prefer to just automatically edit it then we'll do
> so.

I'd definitely prefer that, yes. If you're just going to fail hard if
kernel-img.conf contains /sbin/update-grub, and the only way to fix the
situation is to edit that file, then the preinst might as well just edit
the file itself. I don't see that we're really doing anyone any favours
by just bailing out.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Fri, 31 Jul 2009 08:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Fri, 31 Jul 2009 08:30:03 GMT) Full text and rfc822 format available.

Message #51 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: 470894@bugs.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Fri, 31 Jul 2009 10:25:06 +0200
Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> If you, and others on this list, agree with that claim, then we can
> simply go ahead and have grub-installer edit /etc/default/grub to
> insert
> the output of user-params, on the condition that the default text -
> i.e.
> what you get if you just press enter at the boot: prompt - is
> character-for-character the same as what's in the conffile shipped in
> the grub-pc package. However, if you disagree, then I think it will be
> necessary to convert grub-pc (and I suppose the other grub-* binary
> packages) to manage /etc/default/grub using ucf. 

Now that we use ucf for it, it should be easy to implement for someone
who knows sed.
Which I don't unfortunately, so I don't know how to do it.

Should there be then a check for the version with ucf in case people
install lenny with current grub-installer to be real policy compliant?
In that case the version would be 1.96+20090611-1.

-- 
Felix Zielcke
Proud Debian Maintainer





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Tue, 04 Aug 2009 09:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 04 Aug 2009 09:48:03 GMT) Full text and rfc822 format available.

Message #56 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: 470894@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Tue, 04 Aug 2009 11:45:49 +0200
[Message part 1 (text/plain, inline)]
bts tag 470894 patch
thanks
Am Freitag, den 31.07.2009, 10:25 +0200 schrieb Felix Zielcke:
> Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> > If you, and others on this list, agree with that claim, then we can
> > simply go ahead and have grub-installer edit /etc/default/grub to
> > insert
> > the output of user-params, on the condition that the default text -
> > i.e.
> > what you get if you just press enter at the boot: prompt - is
> > character-for-character the same as what's in the conffile shipped in
> > the grub-pc package. However, if you disagree, then I think it will be
> > necessary to convert grub-pc (and I suppose the other grub-* binary
> > packages) to manage /etc/default/grub using ucf. 
> 
> Now that we use ucf for it, it should be easy to implement for someone
> who knows sed.
> Which I don't unfortunately, so I don't know how to do it.
> 
> Should there be then a check for the version with ucf in case people
> install lenny with current grub-installer to be real policy compliant?
> In that case the version would be 1.96+20090611-1.


Here's now a patch which does it without a version check.

-- 
Felix Zielcke
Proud Debian Maintainer
[preserve_user_params.diff (text/x-patch, attachment)]

Added tag(s) patch. Request was from Felix Zielcke <fzielcke@z-51.de> to control@bugs.debian.org. (Tue, 04 Aug 2009 09:57:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Fri, 07 Aug 2009 06:00:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Fri, 07 Aug 2009 06:00:02 GMT) Full text and rfc822 format available.

Message #63 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: 470894@bugs.debian.org
Cc: Colin Watson <cjwatson@debian.org>
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Fri, 07 Aug 2009 07:59:04 +0200
Am Dienstag, den 04.08.2009, 11:45 +0200 schrieb Felix Zielcke:
> bts tag 470894 patch
> thanks
> Am Freitag, den 31.07.2009, 10:25 +0200 schrieb Felix Zielcke:
> > Am Donnerstag, den 11.06.2009, 15:03 +0100 schrieb Colin Watson:
> > > If you, and others on this list, agree with that claim, then we can
> > > simply go ahead and have grub-installer edit /etc/default/grub to
> > > insert
> > > the output of user-params, on the condition that the default text -
> > > i.e.
> > > what you get if you just press enter at the boot: prompt - is
> > > character-for-character the same as what's in the conffile shipped in
> > > the grub-pc package. However, if you disagree, then I think it will be
> > > necessary to convert grub-pc (and I suppose the other grub-* binary
> > > packages) to manage /etc/default/grub using ucf. 
> > 
> > Now that we use ucf for it, it should be easy to implement for someone
> > who knows sed.
> > Which I don't unfortunately, so I don't know how to do it.
> > 
> > Should there be then a check for the version with ucf in case people
> > install lenny with current grub-installer to be real policy compliant?
> > In that case the version would be 1.96+20090611-1.
> 
> 
> Here's now a patch which does it without a version check.
> 

I suggest to change the sed expression to
"s!^GRUB_CMDLINE_LINUX=\"\?\([^\"]*\)\"\?!GRUB_CMDLINE_LINUX=\"\1 xyz\"!"
because in lenny we just have GRUB_CMDLINE_LINUX= in /etc/defaul/grub
or does someone have a better one?

-- 
Felix Zielcke
Proud Debian Maintainer





Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Mon, 31 Aug 2009 23:24:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Colin Watson <cjwatson@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Mon, 31 Aug 2009 23:24:04 GMT) Full text and rfc822 format available.

Message #68 received at 470894@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: Felix Zielcke <fzielcke@z-51.de>
Cc: 470894@bugs.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Tue, 1 Sep 2009 00:14:32 +0100
On Fri, Aug 07, 2009 at 07:59:04AM +0200, Felix Zielcke wrote:
> Am Dienstag, den 04.08.2009, 11:45 +0200 schrieb Felix Zielcke:
> > Here's now a patch which does it without a version check.
> 
> I suggest to change the sed expression to
> "s!^GRUB_CMDLINE_LINUX=\"\?\([^\"]*\)\"\?!GRUB_CMDLINE_LINUX=\"\1 xyz\"!"
> because in lenny we just have GRUB_CMDLINE_LINUX= in /etc/defaul/grub
> or does someone have a better one?

Better to sed s!^GRUB_CMDLINE_LINUX=$!GRUB_CMDLINE_LINUX=""! first. But
then that also leaves unsightly leading spaces. There's no obvious
reason why we need to preserve any existing value in these variables, of
course.

However, now that grub2/linux_cmdline and grub2/linux_cmdline_default
debconf questions exist, we need to preseed them anyway to stop them
being asked in a default installation. As long as we have to do that, it
seems to me that we might as well set them to reasonable values.

How does this patch look?

Index: grub-installer
===================================================================
--- grub-installer	(revision 60561)
+++ grub-installer	(working copy)
@@ -394,6 +394,25 @@
 	;;
 esac
 
+user_params=$(user-params) || true
+defopt_params=""
+kopt_params=""
+for u_param in $user_params; do
+	case "$u_param" in
+	    quiet)
+		defopt_params=${defopt_params:+$defopt_params }$u_param ;;
+	    *)
+		kopt_params=${kopt_params:+$kopt_params }$u_param ;;
+	esac
+done
+if [ "$grub_version" = grub2 ]; then
+	# quoting to deconfuse vim
+	chroot /target 'debconf-set-selections' <<EOF
+$grub_package grub2/linux_cmdline string $kopt_params
+$grub_package grub2/linux_cmdline_default string $defopt_params
+EOF
+fi
+
 db_progress START 0 6 grub-installer/progress/title
 
 db_subst grub-installer/progress/step_install GRUB "$grub_version"
@@ -726,17 +745,6 @@
 
 # Add user parameters to menu.list; some options are only added to the
 # default entry for a kernel instead of all entries
-user_params=$(user-params) || true
-defopt_params=""
-kopt_params=""
-for u_param in $user_params; do
-	case "$u_param" in
-	    quiet)
-		defopt_params=${defopt_params:+$defopt_params }$u_param ;;
-	    *)
-		kopt_params=${kopt_params:+$kopt_params }$u_param ;;
-	esac
-done
 if [ "$defopt_params" ]; then
 	sed -i "s!^\(# defoptions=.*\)!\1 $defopt_params!" $ROOT/boot/grub/$menu_file
 fi

-- 
Colin Watson                                       [cjwatson@debian.org]




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Install System Team <debian-boot@lists.debian.org>:
Bug#470894; Package grub-installer. (Tue, 01 Sep 2009 07:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Felix Zielcke <fzielcke@z-51.de>:
Extra info received and forwarded to list. Copy sent to Debian Install System Team <debian-boot@lists.debian.org>. (Tue, 01 Sep 2009 07:21:10 GMT) Full text and rfc822 format available.

Message #73 received at 470894@bugs.debian.org (full text, mbox):

From: Felix Zielcke <fzielcke@z-51.de>
To: Colin Watson <cjwatson@debian.org>
Cc: 470894@bugs.debian.org
Subject: Re: Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
Date: Tue, 01 Sep 2009 09:15:32 +0200
Am Dienstag, den 01.09.2009, 00:14 +0100 schrieb Colin Watson:
> On Fri, Aug 07, 2009 at 07:59:04AM +0200, Felix Zielcke wrote:
> > Am Dienstag, den 04.08.2009, 11:45 +0200 schrieb Felix Zielcke:
> > > Here's now a patch which does it without a version check.
> > 
> > I suggest to change the sed expression to
> > "s!^GRUB_CMDLINE_LINUX=\"\?\([^\"]*\)\"\?!GRUB_CMDLINE_LINUX=\"\1 xyz\"!"
> > because in lenny we just have GRUB_CMDLINE_LINUX= in /etc/defaul/grub
> > or does someone have a better one?
> 
> Better to sed s!^GRUB_CMDLINE_LINUX=$!GRUB_CMDLINE_LINUX=""! first. But
> then that also leaves unsightly leading spaces. There's no obvious
> reason why we need to preserve any existing value in these variables, of
> course.
> 
> However, now that grub2/linux_cmdline and grub2/linux_cmdline_default
> debconf questions exist, we need to preseed them anyway to stop them
> being asked in a default installation. As long as we have to do that, it
> seems to me that we might as well set them to reasonable values.
> 
> How does this patch look?
> 
> Index: grub-installer
> ===================================================================
> --- grub-installer	(revision 60561)
> +++ grub-installer	(working copy)
> @@ -394,6 +394,25 @@
>  	;;
>  esac
>  
> +user_params=$(user-params) || true
> +defopt_params=""
> +kopt_params=""
> +for u_param in $user_params; do
> +	case "$u_param" in
> +	    quiet)
> +		defopt_params=${defopt_params:+$defopt_params }$u_param ;;
> +	    *)
> +		kopt_params=${kopt_params:+$kopt_params }$u_param ;;
> +	esac
> +done
> +if [ "$grub_version" = grub2 ]; then
> +	# quoting to deconfuse vim
> +	chroot /target 'debconf-set-selections' <<EOF
> +$grub_package grub2/linux_cmdline string $kopt_params
> +$grub_package grub2/linux_cmdline_default string $defopt_params
> +EOF
> +fi
> +
>  db_progress START 0 6 grub-installer/progress/title
>  
>  db_subst grub-installer/progress/step_install GRUB "$grub_version"
> @@ -726,17 +745,6 @@
>  
>  # Add user parameters to menu.list; some options are only added to the
>  # default entry for a kernel instead of all entries

You forgot to move that comment and maybe it shouldn't say anymore
menu.list but menu.lst or /etc/default/grub or something like that.
Except of this, it looks fine to me.

> -user_params=$(user-params) || true
> -defopt_params=""
> -kopt_params=""
> -for u_param in $user_params; do
> -	case "$u_param" in
> -	    quiet)
> -		defopt_params=${defopt_params:+$defopt_params }$u_param ;;
> -	    *)
> -		kopt_params=${kopt_params:+$kopt_params }$u_param ;;
> -	esac
> -done
>  if [ "$defopt_params" ]; then
>  	sed -i "s!^\(# defoptions=.*\)!\1 $defopt_params!" $ROOT/boot/grub/$menu_file
>  fi
> 






Reply sent to Colin Watson <cjwatson@debian.org>:
You have taken responsibility. (Tue, 01 Sep 2009 12:36:49 GMT) Full text and rfc822 format available.

Notification sent to Frans Pop <elendil@planet.nl>:
Bug acknowledged by developer. (Tue, 01 Sep 2009 12:36:49 GMT) Full text and rfc822 format available.

Message #78 received at 470894-close@bugs.debian.org (full text, mbox):

From: Colin Watson <cjwatson@debian.org>
To: 470894-close@bugs.debian.org
Subject: Bug#470894: fixed in grub-installer 1.42
Date: Tue, 01 Sep 2009 12:17:12 +0000
Source: grub-installer
Source-Version: 1.42

We believe that the bug you reported is fixed in the latest version of
grub-installer, which is due to be installed in the Debian FTP archive:

grub-installer_1.42.dsc
  to pool/main/g/grub-installer/grub-installer_1.42.dsc
grub-installer_1.42.tar.gz
  to pool/main/g/grub-installer/grub-installer_1.42.tar.gz
grub-installer_1.42_i386.udeb
  to pool/main/g/grub-installer/grub-installer_1.42_i386.udeb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 470894@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated grub-installer package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 01 Sep 2009 13:03:09 +0100
Source: grub-installer
Binary: grub-installer
Architecture: source i386
Version: 1.42
Distribution: unstable
Urgency: low
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Description: 
 grub-installer - Install GRUB on a hard disk (udeb)
Closes: 470894
Changes: 
 grub-installer (1.42) unstable; urgency=low
 .
   [ Felix Zielcke ]
   * Check that /etc/kernel-img.conf exists before running sed over it.
 .
   [ Colin Watson ]
   * Don't create /etc/grub.d/30_otheros if os-prober is already installed
     for grub2 to use (LP: #419044).
   * Pass user parameters to grub2 (closes: #470894).
   * Add myself to Uploaders.
 .
   [ Updated translations ]
   * Korean (ko.po) by Changwoo Ryu
Checksums-Sha1: 
 455a53840ccddceef5514f8ce0e10a8cab5be292 1146 grub-installer_1.42.dsc
 e39cd47789296f86f433061f9cb9a14a26e8496f 162573 grub-installer_1.42.tar.gz
 52f161247f949a149c228935a8a510e8e22b5e55 154156 grub-installer_1.42_i386.udeb
Checksums-Sha256: 
 55c1fe47ad4f61e66ccbf57295167d59cfbda09208b31a54d041c41f8317dcfa 1146 grub-installer_1.42.dsc
 db9e8a100c621485f749a5438d5a7aa0a7665bff42d9f595fc59521b312e9f19 162573 grub-installer_1.42.tar.gz
 444b5806bb1a19939e8e7be0a67cb4b4f733ef0b5e550b5c39a9bc84436e259e 154156 grub-installer_1.42_i386.udeb
Files: 
 5e10618263bad0b496b7005c9a48c5f0 1146 debian-installer standard grub-installer_1.42.dsc
 52d6147dd716f7d36b40d0dfa0f4bb69 162573 debian-installer standard grub-installer_1.42.tar.gz
 3fae6a5867ee65f8a81c5eac278c9aec 154156 debian-installer standard grub-installer_1.42_i386.udeb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Colin Watson <cjwatson@debian.org> -- Debian developer

iD8DBQFKnQ3Y9t0zAhD6TNERApCPAJ96UX75WNl136BrAJaeQAG2+8xGeQCcC0aF
hvizoxgYqKchaJqA/T/JQ28=
=RbYT
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 30 Sep 2009 08:07:46 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 15:59:37 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.