[Debconf-devel] Bug#1144150: debconf exits without error message when facing a value with newline

[MichaIng]

Package: debconf
Version: 1.5.91

Not a bug, but a suggestion to make detecting invalid debconf inputs easier.

We just had a case where grub-efi-amd64's postinst script always failed 
without any error message. Debugging the shell script with "set -x" 
revealed, that "exec /usr/share/debconf/frontend ..." was reached before 
the exit. Debugging that perl script was tedious, given that only 
"perl-base" was installed (not perl debugging modules), so "perl -d" did 
not work without satisfying dpkg by moving "postinst" out of the way, to 
allow installing perl modules.

Perl debug output from the "/usr/share/debconf/frontend" call is huge, 
detecting errors difficult. We saw that it exits after
```
1 while ($confmodule->communicate)
```

Adding "set -x" to the package's "config" shell script gave these last 
commands

```
+ RET=30 question skipped
+ local _db_status=30
+ return 30
```

which is a normal exit for non-interactive configuration. It took a 
while before we recognised the unusual return code some input values 
earlier, after "db_input medium grub2/linux_cmdline":

```
+ RET=20 Bad line "" received from confmodule.
+ local _db_status=20
+ return 20
```

But where this bad line was coming from remained unclear, also when "set 
-x" debugging the "config" shell script.

It took another while before we recognised the empty line in the debug 
output

```
+ IFS=
+ printf %s\n SET grub2/linux_cmdline_default foo bar

+ IFS=
```

as well as from the "source /etc/default/grub", between two assigned 
variables:

```
+ GRUB_CMDLINE_LINUX_DEFAULT=foo bar

+ GRUB_CMDLINE_LINUX=net.ifnames=0
```

As can be seen, the faulty value was not in 
"grub2/linux_cmdline"/"GRUB_CMDLINE_LINUX", but in 
"grub2/linux_cmdline_default"/"GRUB_CMDLINE_LINUX_DEFAULT" processed before.

When editing "GRUB_CMDLINE_LINUX_DEFAULT", the user accidentally added a 
newline before the closing double-quote character. This newline was 
hence part of the "GRUB_CMDLINE_LINUX_DEFAULT" value. debconf's frontend 
script however expects a single line per input, and the newline 
character caused it to receive and fail on a separate empty line, when 
retrieving the input for the next config key.

Also interesting is, that an interactive "dpkg-reconfigure" failed as 
well. So even retrieving a valid value from whiptail output, did not 
prevent the failure. Or maybe the newline character was overlooked in 
the whiptail inputbox, not sure whether whiptail inputboxes can 
theoretically take control characters as default value, and return them 
as well.

It would really help if debconf could print meaningful error messages, 
when receiving invalid inputs. Debugging these nested shell => perl => 
shell calls with the way how the debconf frontend script calls an 
retrieves output from the "config" shell script, is not trivial, also 
since the "config" script cannot exit in place due to required "db_input 
... || true", so that the actual error in its debug output can be buried.

Best regards,

Micha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x0442B9ADE65643FE.asc
Type: application/pgp-keys
Size: 9878 bytes
Desc: OpenPGP public key
URL: <http://alioth-lists.debian.net/pipermail/debconf-devel/attachments/20260811/915b7553/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debconf-devel/attachments/20260811/915b7553/attachment.sig>