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

loader varialbe in kernel maintainer scripts

On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote:
> On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote:
>> [...]
>> I can maybe accept your proposal for Squeeze.  But for Lenny, I believe
>> that the maintainer scripts should be changed back they way they
>> were.  In other words,
>>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
>> should be set in the maintainer scripts.  After all, Lenny does
>> not have the generalized hook script environment that Squeeze does.
> But it does allow users to configure the loader to be run, using either
> the 'loader' or 'postinst_hook' variable.

And how would one go about setting this "loader" variable?
The "loader" variable is not documented in the man page for
/etc/kernel-img.conf in Lenny, which appears to be the closest thing
there is to documentation for the variables supported by official
Debian stock kernel images.  Nevertheless, at your suggestion, I tried

   loader = lilo

in /etc/kernel-img.conf.  ("do_bootloader = yes" was also set.)  Then I

   dpkg-reconfigure linux-image-2.6.26-2-686

There was no evidence from the output that lilo was run.  As for the
postinst_hook and postrm_hook variables, they do work, but one can't
simply specify

   postinst_hook = lilo
   postrm_hook = lilo

in /etc/kernel-img.conf.
That won't work because lilo doesn't like the parameters passed to it.
It is necessary to create a wrapper script around lilo that strips off
the parameters passed to it and redirects standard output to standard
error.  For example, on my unofficial kernel building web page, I
recommend that lilo users create a hook script called
/usr/sbin/lilo-update that looks like this:

   # The purpose of this script is to strip off any
   # arguments passed and simply invoke lilo, redirecting
   # standard output to standard error.  It is intended
   # to be referenced by /etc/kernel-img.conf in the
   # postinst_hook and postrm_hook variables.
   lilo >&2

Then mark it executable with

   chmod +x /usr/sbin/lilo-update

Then edit /etc/kernel-img.conf and specify

   postinst_hook = lilo-update
   postrm_hook = lilo-update

That is how I have been recommending that users circumvent
this bug (or feature, depending on your point of view).

>> I believe that this bug is severe enough to warrant inclusion of the
>> fix in stable-proposed-updates.
> The fact that the historical bootloader is not automatically run is not a
> bug; it is an intentional change.  Only the silent failure is a bug.

Preventing the historic boot loader from being run could have been
accomplished by simply setting

   do_bootloader = no

in /etc/kernel-img.conf.  By setting "my $loader" to the null string, you
made it *impossible* for the user to request that the historic boot loader
be run.  But OK, if you say it's a feature, not a bug, then I'll have to
accept that.  I must say I'm disappointed though.

>> However, to be consistent, if you're going to leave "my $loader" set to the null
>> string in i386 and amd64 kernel maintainer scripts, you should also set
>> it to the null string for s390 kernel maintainer scripts.
> Yes. I think that's probably a reasonable change for squeeze.

I was trying to use that argument to convince you to change it back for
i386 and amd64, not to convince you to "break" it for s390!  Oh well.
Now it appears that s390 users will be able to look forward to this
"feature" also.

>> [...]
>> The maintainer scripts' support for the historic boot
>> loader should be retained, in my opinion, at least for Squeeze.  Then,
>> if you want to change the design of how kernel maintainer scripts
>> work, that can be done in Squeeze+1.
> It cannot be 'retained' because it is not there at present.  Nor will it
> be reinstated.

OK, if you're determined not to set "my $loader" to the name of the
historic boot loader, then please do make a change similar to the
one you proposed so that it will tell the user to manually
run the boot loader.  Then close this bug report.

  .''`.     Stephen Powell    
 : :'  :
 `. `'`

Reply to: