Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #64381 > unrolled thread

Bug#931499: initramfs hook scripts which use log_* functions die

Back to article view | Back to linux.debian.kernel

Contents

  Bug#931499: initramfs hook scripts which use log_* functions die Guenther Brunthaler <gb_about_gnu@gmx.net> - 2019-07-06 20:40 +0200
    Bug#931499: Is sourcing /usr/share/initramfs-tools/scripts/functions forbidden in hook scripts? Guenther Brunthaler <gb_about_gnu@gmx.net> - 2019-07-06 21:00 +0200
    Processed: Re: initramfs hook scripts which use log_* functions die "Debian Bug Tracking System" <owner@bugs.debian.org> - 2019-07-07 16:40 +0200
    Bug#931499: initramfs hook scripts which use log_* functions die Ben Hutchings <ben@decadent.org.uk> - 2019-07-07 16:40 +0200
    Bug#931499: [Fwd: Re: initramfs hook scripts which use log_* functions die] Ben Hutchings <ben@decadent.org.uk> - 2019-07-09 02:00 +0200
    Bug#931499: initramfs hook scripts which use log_* functions die Ben Hutchings <ben@decadent.org.uk> - 2019-07-09 02:00 +0200

#64381 — Bug#931499: initramfs hook scripts which use log_* functions die

Package: initramfs-tools-core
Version: 0.133

initramfs hook scripts which source

. /usr/share/initramfs-tools/scripts/functions

and then later use one of the log_*() functions such as

log_begin_msg "Installing terminfo entries: $tinfos"

will make the hook script fail with the message "quiet: parameter not
set", which will make the invoking "update-initramfs" also fail as a
consequence.

The reason is simple: The script contains a parameter expansion

$ grep -F 'quiet?' /usr/share/initramfs-tools/scripts/functions
         if [ "${quiet?}" = "y" ]; then return; fi

which will fail if "$quiet" is not defined at all at this place. This
can easily be tested as follows:

$ (set +e; unset quiet; echo "${quiet?}"; echo "RC: $?")
-bash: quiet: parameter not set

Note that this failure was so severe that the whole subshell terminated
even though "set -e" has been disabled!

The easiest way to make to problem go away would be to set the variable
if it is not defined, because this works:

$ (set +e; : ${quiet:=}; echo "${quiet?}"; echo "RC: $?")
RC: 0

It would suffice to add a line

: ${quiet:=}

or maybe better

: ${quiet:=n}

somewhere outside of any function to the file
/usr/share/initramfs-tools/scripts/functions.

I am using Debian 10 on branch "buster"
on branch ascii
with kernel
Linux 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64
GNU/Linux

[toc] | [next] | [standalone]

#64382 — Bug#931499: Is sourcing /usr/share/initramfs-tools/scripts/functions forbidden in hook scripts?

I just noticed that the line in Debian 9

"$quiet" = "y"

was explicitly changed into

"${quiet?}" = "y"

in Debian 10, so I wonder whether this was really a regression by
mistake, or rather a deliberate way to break all existing hook scripts
which source /usr/share/initramfs-tools/scripts/functions because they
must not do this for some reason.

If this should be the case, that fact should be mentioned in the man
page of initramfs-tools.

The man page currently does not explicitly suggest sourcing this shell
snippet, but it does not advise against it either.

And it worked fine in Debian 9.

Now many of my hook scripts are broken because of this regression in
Debian 10.

I fixed the problem for now with the following kludge:

---------------
$ cat /etc/initramfs-tools/conf.d/quiet-fix-tifgasefdz3c41npwum8msjt7
# Without this file, every initramfs hook which uses one of the log_*
# functions will fail with the message "quiet: parameter not set".
#
# This effect was introduced by upgrading from Debian "stretch" to "buster".

: ${quiet:=n}
export quiet
---------------

but of course this is not a clean solution.

[toc] | [prev] | [next] | [standalone]

#64389 — Processed: Re: initramfs hook scripts which use log_* functions die

Processing control commands:

> tag -1 moreinfo
Bug #931499 [initramfs-tools-core] initramfs hook scripts which use log_* functions die
Added tag(s) moreinfo.

-- 
931499: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931499
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#64390

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

On Sat, 6 Jul 2019 20:31:37 +0200 Guenther Brunthaler <gb_about_gnu@gmx.net> wrote:
> Package: initramfs-tools-core
> Version: 0.133
> 
> initramfs hook scripts which source
> 
> . /usr/share/initramfs-tools/scripts/functions
> 
> and then later use one of the log_*() functions such as
> 
> log_begin_msg "Installing terminfo entries: $tinfos"
> 
> will make the hook script fail with the message "quiet: parameter not
> set", which will make the invoking "update-initramfs" also fail as a
> consequence.
[...]

These functions are meant to be used by boot scripts, not by hook
scripts.  The documentation is consistent with that.

Which hook scripts are using them?

Ben.
 
-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.

[toc] | [prev] | [next] | [standalone]

#64408 — Bug#931499: [Fwd: Re: initramfs hook scripts which use log_* functions die]

-------- Forwarded Message --------
From: Guenther Brunthaler <gb_about_gnu@gmx.net>
To: Ben Hutchings <ben@decadent.org.uk>
Subject: Re: initramfs hook scripts which use log_* functions die
Date: Sun, 7 Jul 2019 19:38:00 +0200
Message-Id: <26898f5b-40b3-d225-03c1-3f495503583b@gmx.net>

Am 2019-07-07 um 15:50 schrieb Ben Hutchings:

> These functions are meant to be used by boot scripts, not by hook
> scripts.

Thank you, this is good to know!

Unfortunatly, this wasn't so clear for me.

> The documentation is consistent with that.

Actually, the documentation is *lacking* in this area.

It does not explain at all how a hook script shall emit its diagnostic
messages.

So the reader is left to speculations.

And there are ample of such logging functions for boot scripts
documented only a few paragraphs later.

This makes someone trying to find for a way to emit messages in hook
scripts at least wonder whether the same functions could also be used in
hook scripts.

Visual inspection of the helper script revealed that its logging
functions might work in hook scripts as well - and practical tests
verified this in Debian 8 and Debian 9.

Suddenly, in Debian 10, now it won't work any longer.

So, summing up, this bug is not really a regression.

It is an unfortunate consequence of lacking information in the man page.

I would therefore suggest to enhance the text of the manual page in the
section about hook scripts either by

* Explaining where to or how a hook script should emit its diagnostic
messages

* Stating that a hook script must not emit such messages at all (i. e.
redirect it to some private file instead if absolutely required)

Then the reader knows what to do and does not have to wonder any longer.

> Which hook scripts are using them?

My own ones!

For instance, I have tmux in my initramfs for additional comfort when
repairing a damaged "/"-filesystem remotely via dropbear.

tmux requires a UTF-8 locale in order to work, so I added the following
hook script to install one:

================
$ cat /etc/initramfs-tools/hooks/locale-j2mkmlcr0gu1pkjv7vn84ksnl
#! /bin/sh
# Copyright (c) 2018 Guenther Brunthaler. All rights reserved.
#
# This script is free software.
# Distribution is permitted under the terms of the GPLv3.

locale=C.UTF-8
locale_data=/usr/lib/locale/$locale
ti_src=/lib/terminfo
ti_dst=/etc/terminfo
tinfos='linux screen xterm'

set -e

case $1 in
         prereqs) echo; exit
esac

. /usr/share/initramfs-tools/scripts/functions

log_begin_msg "Installing $locale locale"
find -H "$locale_data" \
> while IFS= read -r fso
do
         dest=$DESTDIR$fso
         if test -d "$fso"
         then
                 mode=`stat -c %a -- "$fso"`
                 mkdir -pm "$mode" -- "$dest"
         else
                 cp -Pp -- "$fso" "$dest"
         fi
done
log_end_msg
================

Although not all of my hook scripts produce output, some of them like
the one above do, and it has worked without any problems in Debian 8 and
Debian 9.

Now it does't any more, at least not without my kludge.

Of course, with the newfound knowledge obtained from your statement, I
will now replace /usr/share/initramfs-tools/scripts/functions with my
own implementation of the same functions. (Or rather with a private copy
of the Debian 8 version of the script functions, as I would like to
avoid reinventing the wheel.)
-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.

[toc] | [prev] | [next] | [standalone]

#64410

[Multipart message — attachments visible in raw view] — view raw

[Please use "reply to all", to record your messages in the bug
reporting system.]

On Sun, 2019-07-07 at 19:38 +0200, Guenther Brunthaler wrote:
> Am 2019-07-07 um 15:50 schrieb Ben Hutchings:
> 
> > These functions are meant to be used by boot scripts, not by hook
> > scripts.
> 
> Thank you, this is good to know!
> 
> Unfortunatly, this wasn't so clear for me.
> 
> > The documentation is consistent with that.
> 
> Actually, the documentation is *lacking* in this area.
> 
> It does not explain at all how a hook script shall emit its diagnostic
> messages.
> 
> So the reader is left to speculations.
[...]

Yes, I can see how you went down this path.  We should separate
functions meant for use at boot time, and those few functions meant for
use at either build or boot time; and then only include definitions of
the latter in "hook-functions".

The answer to "how to log messages" is largely the same as for any
shell script: use echo or printf, and redirect warnings and errors to
stderr.  If you have messages that should only appear in verbose mode
(mkinitramfs -v), test the "verbose" variable, e.g.:

    [ "${verbose}" = y ] && echo "Doing my thing"

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web