On Fri, 26 Feb 2010 01:50:52 -0500 (EST), Raphael Hertzog wrote: > On Thu, 25 Feb 2010, Stephen Powell wrote: >> run-parts itself, of course, is binary. Do you see a problem here? > > No, what leads you to believe that this is the part that is failing ? > The error is probably later in the script.
I suppose I was thinking that since the exit is the only thing that changed, the problem must somehow be in handling the exit. But that got me thinking. If the return code is known to be zero both with and without the zipl call, yet the process fails with the zipl call in place and doesn't fail with the zipl call eliminated, then what else could explain it? The answer: output. I normally see messages written to the terminal when I invoke zipl, like so: ---------- Using config file '/etc/zipl.conf' Ignore section 'old': Image file '/boot/vmlinuz.old' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'debian' (default) Ignore #2: IPL section 'old' Preparing boot device: dasdb (0201). Done. ---------- But when I invoke zipl from within this hook script, I see no output from it. Obviously some higher-level process is redirecting standard output. And maybe that process is going through that output afterwards looking for some specific string. And maybe the output from zipl is confusing the logic. So I redirected standard output to standard error, like so: zipl >&1 This solves the problem. Apparently dpkg is invoking some type of "catch-all" error handler when it finds something in the output that confuses it, and the error message being issued is not at all indicative of what the real problem is. By the way, do you know of a way that a script being invoked as a postrm hook script can determine if it is being called from a purge versus being called from a remove? The original script logic that I inherited from the sample file in kernel-package apparently assumes that this information can be extracted from the environment variable DEB_MAINT_PARAMS, but I have verified via the "set" command with no parameters (except redirection) that DEB_MAINT_PARAMS is not in the environment. zipl only needs to be invoked on a remove, not on a purge. If the script could tell if it was being invoked from a purge versus a remove, it wouldn't need to invoke zipl in the first place. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
