Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)

[Ben Hutchings]

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.

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.

All packages that need to react to kernel installation or removal should
install appropriate hook scripts in the directories under /etc/kernel
instead of relying on specific support in the kernel maintainer scripts.

Again, I can maybe accept that argument for Squeeze, but not for Lenny.
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.

[...]

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.

Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus

[Stephen Powell]

Post by Ben Hutchings

[...]
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
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. 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:

#!/bin/sh
# 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).

Post by Ben Hutchings

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.

Post by Ben Hutchings

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.

Post by Ben Hutchings

[...]
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
: :' :
`. `'`
`-