Re: lilo removal in squeeze (or, "please test grub2")
On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote:
> On 05/26/2010 03:36 AM, Stephen Powell wrote:
>> ...
>> That works for now; but if a package upgrade for extlinux is ever
>> downloaded, I'm afraid that new versions of the hook scripts will
>> be copied into these directories which are marked executable, and
>> my hand-made configuration file will get wiped out.
>> ...
>
> as of current git, you can now use EXTLINUX_UPDATE=false in
> /etc/default/extlinux to prevent having update-extlinux do anything.
That's good to know, thanks. I'm looking forward to that feature
migrating into squeeze.
>> Second, it is important that any script run as a hook script not
>> produce any output at all to standard output. I found that out the
>> hard way when I was writing my own hook scripts for use with lilo.
>> That's because they run under debconf, which has redirected standard
>> output for its own purposes. Thus, anything written to standard
>> output is (1) never seen by the user and (2) has a good chance of
>> messing up debconf, which is examining the output. The invocation
>> of update-extlinux should have a redirection on it to redirect
>> output to standard error. For example,
>>
>> update-extlinux >&2
>
> none of the hooks is doing this (initramfs-tools, grub, etc), might
> needs further convincing.
It is a little-known requirement, and often you can get away with it,
but not always. I'm going from memory here, but I believe that
debconf redirects standard output, then calls the maintainer script
for the kernel, which calls the run-parts utility, which then calls
the hook script. If the standard output produced by the hook script
matches something that debconf is looking for it can mess things up.
Sometimes the
failure will occur for one type of call, such as a purge, but not
for another type of call, such as a configure or a remove. Manoj
Srivastava, author and Debian package maintainer of the kernel-package
package, mentions it in the man page for kernel-img.conf, and
I have personally been burned by it with one of my own hook scripts
that I wrote for use with lilo. The hook script failed with a
non-zero return code, which caused the kernel installation process
to fail. I could not figure out for the life of me what was wrong.
The script ran fine when invoked stand-alone, but not as a hook script.
Redirecting lilo output to standard error solved the problem.
It ran perfectly after that. But even if the stuff written to
standard output does not mess up debconf, the user still won't
see it. The safe (and informative) thing to do is for all hook
scripts to write all output to standard error.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: