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

Bug#505609: loader varialbe in kernel maintainer scripts

On Fri, 18 Jun 2010 04:25:38 -0400 (EDT), Joachim Wiedorn wrote:
> Ben Hutchings <ben@decadent.org.uk> wrote on 2010-06-18 02:02:
>> On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote:
>>> 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
>>> putting
>>>    loader = lilo
>>> in /etc/kernel-img.conf.  ("do_bootloader = yes" was also set.)  Then I
>>> issued
>>>    dpkg-reconfigure linux-image-2.6.26-2-686
>>> There was no evidence from the output that lilo was run.
>>> [...]
>> I'm sorry, you're right.  Most of the other variables at the top of the
>> postinst script can be overridden by /etc/kernel-img.conf, but not this
>> one.  Given that, I think you are right that the 'historical' bootloader
>> setting should be restored in an update to lenny.
> Now I am a little confused. How is the recommended procedure for using the
> LILO bootloader within squeeze/sid? 
> How I understand the normal installation of lilo package have the result,
> that lilo doesn't be started after an kernel update (and also after update
> of initramfs-tools?). 
> What must I config on my squeeze machine that lilo bootloader will be
> automatically updated after kernel update?

So far, Ben has only agreed to reinstate the historic function of

   do_bootloader = yes

in /etc/kernel-img.conf for Lenny kernel maintainer scripts.
It hasn't actually happened yet, but
he has agreed to restore its former function in Lenny as it was in Etch
and previous releases.  I am trying to persuade him to restore its
function in Squeeze too.  Whether or not I am successful remains to be
seen.  In the mean time, for lilo users of Squeeze/Sid who use *only* official
stock Debian kernels, I recommend that they use the hook script described
in an earlier post to this bug log in conjunction with other appropriate
settings in /etc/kernel-img.conf.

For lilo users of Squeeze/Sid who use
custom kernels created by make-kpkg, I recommend that they use the hook
scripts provided on my unofficial kernel building web page,
http://www.wowway.com/~zlinuxman/Kernel.htm, under "Step 10: Customize
the Kernel Installation Environment".  I must add that this recommendation
is my own and not official Debian advice.  I have never used the
upstream-provided "make deb-pkg" way of building a custom kernel; so
I don't have any hook scripts pre-made for that purpose.  There doesn't
seem to be a "one size fits all" solution at this point.  If Ben agrees
to reinstate the historic function of "do_bootloader = yes" for Squeeze,
then there will be a "one size fits all" solution for lilo users, at least
as it pertains to stock kernels.  Users of custom kernels are on their own.
They need to figure out what hook scripts they need and how to customize
and configure them.  And if they don't do it right, you may be sure that
they will blame lilo!  (That's one of the reasons why I think it would
be a good idea for lilo to implement a "check sum" method of figuring
out if something changed in the kernel image or initial RAM file system
image without lilo being re-run.  But I digress.)

As for "update-initramfs -u", it *will* invoke lilo if lilo is installed
and "do_bootloader = yes" is specified in /etc/kernel-img.conf, which I
highly recommend.  There are types of upgrades which do not affect the
kernel itself but which do require that the initial RAM file system
be re-built.  And for lilo users, it is essential that lilo be run after
any changes are made to the initial RAM file system.  "update-initramfs -c"
and "update-initramfs -d", however, will *not* invoke lilo, even if
"do_bootloader = yes" is specified in /etc/kernel-img.conf.


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

Reply to: