On 07/25/2015 06:38 AM, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Fri, 2015-07-24 at 22:32 -0400, Milan Kupcevic wrote: >> mkvmlinuz/37+deb8u1 is fixing bug #741642 already fixed in sid/testing >> to allow for smooth upgrade from wheezy to jessie. See attached diff. >> >> changelog | 6 ++++++ >> kernel-image/postinst | 2 ++ >> kernel-image/postrm | 2 ++ > > --- mkvmlinuz-37/debian/kernel-image/postinst 2012-06-28 21:01:13.000000000 -0400 > +++ mkvmlinuz-37+deb8u1/debian/kernel-image/postinst 2015-07-23 22:45:48.000000000 -0400 > @@ -1,5 +1,7 @@ > #!/bin/sh > > +echo >&2 > > Will the "mkvmlinuz" invocation later in the postinst ever possibly > produce output on stdout? The db_get debconf call does communicate with debconf through stdin/stdout by design. That is why nothing else should use stdin nor stdout at stake for not to interfere with such communication. The violation actually comes from 'run-parts --report' itself, not from the hook. Wheezy kernel package has been using 'run-parts --verbose' to run the hooks. This worked fine as run-parts printed out to stderr only. Jessie kernel package is using 'run-parts --report' instead where output depends on the behavior of the hook in question. See run-parts manual for the exact --report run-parts option description. I'm dealing with this problem by printing out a newline character to stderr from the hook itself, therefore pushing run-parts to output the hook's name to stderr, thus causing run-parts to leave the debconf communication alone. This fix is as minimalist as you possibly could get for a bug fix in a stable release. CC: debian-kernel to get possible input from there > > While I can see the intent behind the above (forcing "run-parts > --report" to output the script name to stderr rather than stdout), it > wasn't immediately obvious. The kernel handbook (in > https://kernel-handbook.alioth.debian.org/ch-update-hooks.html ), > suggests "exec </dev/null >&2", which seems much more idiomatic. > The kernel-handbook suggestion won't fix this issue because run-parts interprets debconf communication as hook output and decides that it has to print out the hook script name to the same place, thus interfering with debconf communication and causing the error described in bug reports #791868 and #741642. Milan
Attachment:
signature.asc
Description: OpenPGP digital signature