Bug#971019: accidental chaining of debconf commands
On 13/02/2021 00:46, Cyril Brulebois wrote:
> Control: severity -1 important
>
> (cc-ing Paul for information, due to interest in RC bugs)
>
> Hello Wilco,
>
> Wilco Baan Hofman <wilco@baanhofman.nl> (2020-09-26):
>> Package: cdebconf
>> Version: 0.249
>> Severity: critical
>>
>> I have a problem with the debian installer, at the finish-install
>> stage in the udeb clock-setup.
>
> I can't replicate it with a current-ish installation image
> (debian-10.7.0-amd64-netinst.iso)
>
>> The interaction in the syslog during install (manually copied from screen):
>> finish-install: info: Running /usr/lib/finish-install.d/10clock-setup
>> debconf: --> FGET clock-setup/utc seen
>> debconf: <-- 0 true
>> debconf: --> SET clock-setup/utc true INPUT low clock-setup/utc
>> debconf: <-- 0 value set
>> debconf: --> GO
>> debconf: <-- 0 ok
>> debconf: --> GET clock/setup/utc
>> debconf: <-- 0 true INPUT low clock-setup/utc
>> debconf: --> GET clock-setup/system-time-changed
>> debconf: <-- 0 false
>> finish-install: /usr/lib/finish-install.d/10clock-setup: return: line
>> 46: illegal number: INPUT
>> finish-install: warning: /usr/lib/finish-install.d/10clock-setup
>> returned error code 2
>
>> For reproducing the error if that's required:
>> This is a preseeded Debian Buster install on VMWare ESXi, relevant
>> preseed config:
>
> I don't have VMWare ESXi, but I couldn't replicate this on bullseye's
> QEMU.
>
>> ### Clock and timezone setup
>> # Controls whether or not the hardware clock is set to UTC.
>> d-i clock-setup/utc boolean true
>>
>> # You may set this to any valid setting for $TZ; see the contents of
>> # /usr/share/zoneinfo/ for valid values.
>> d-i time/zone string Europe/Amsterdam
>>
>> # Controls whether to use NTP to set the clock during the install
>> d-i clock-setup/ntp boolean true
>> # NTP server to use. The default is almost always fine here.
>> #d-i clock-setup/ntp-server string ntp.example.org
>
> I've added a few variables on my own, just to make sure I wouldn't have
> to answer too many questions. The full file is attached for reference.
>
> d-i started from the “Automated Graphical Install” menu with the
> following additions on the kernel command line:
>
> url=https://mraw.org/~kibi/preseed.cfg DEBCONF_DEBUG=developer
>
> with a 5G qemu-img-created as hda disk, and the iso as a cdrom.
>
>> I can't really see why this path would be hit, "db_fget
>> clock-setup/utc seen" should return true and this whole thing should
>> be skipped, but somehow that is not how it works out.. and the debconf
>> confmodule just chains 2 commands together without any separation or
>> wait time, causing an error during finish-install, effectively halting
>> all installs.
>>
>> seems like either a clear separator is missing (newline?) or a buffer
>> must be flushed after every SET..
>
> That's quite surprising, given that's not exactly a new feature, or a
> fast-paced changing codebase…
>
> I'm lowering severity for the time being, I think we'd need a way to
> reproduce this before proceeding any further (that wouldn't involve a
> proprietary hypervisor as far as I'm concerned).
>
>
I managed to work around it. It seems as when you use 'in-target' in the
late script, that the problem starts to occur. chroot /target xxxx does
not trigger it.
Still, it's a bit strange to have it start to chain to individual
commands together as if it is one.
-- Wilco
Reply to: