Bug#470894: grub-installer: user parameters are not added to grub.cfg for grub2
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]
Reply to: