I have a problem with the debian installer, at the finish-install stage
in the udeb clock-setup.

The following code path produces a strange protocol interaction:


if db_fget clock-setup/utc seen && [ "$RET" = true ]; then
    # keep preseeded value
    :
else
    probed=""

    if arch_has_os_needing_local_clock; then
        # os-prober may not yet be installed...
        anna-install os-prober-udeb || true

        probed=$(os-prober) || true

    if [ -z "$probed" ]; then
        # installing the only OS, so use UTC
        db_set clock-setup/utc true
        pri=low
    fi
fi

db_input $pri clock-setup/utc || true
if ! db_go; then
|   exit 10 # back to main menu
fi

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:

### 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 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..

Kind regards,

Wilco Baan Hofman

Hi,

Excuse me if I totally got this wrong, but to an outsider this looks
like a typo...
                        ^ slash
                                     ^ hyphen
           ^ hyphen
Paul

(cc-ing Paul for information, due to interest in RC bugs)

Hello Wilco,

Wilco Baan Hofman <wilco@baanhofman.nl> (2020-09-26):

I can't replicate it with a current-ish installation image
(debian-10.7.0-amd64-netinst.iso)

I don't have VMWare ESXi, but I couldn't replicate this on bullseye's
QEMU.

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.

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).


Cheers,

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 Baan Hofman <wilco@baanhofman.nl> (2021-02-13):

That's interesting. in-target mostly sets up a passthrough mode for
debconf, which could explain the differences between `in-target` and
`chroot /target` calls. I'm not sure why this would interfere with
debconf though.

Any chance you could be more specific about what you were doing via
in-target? Having some way to reproduce the issue would be a start.


Cheers,

access and putting in SSH keys + cron job for maintaining those, postfix
config file, adding central syslog to rsyslog.conf, etc... But I'm
guessing those are all irrelevant.

What could be relevant (cobbler syntax):
====
#if $getVar("$init", "sysvinit") != "systemd"
# Remove systemd and dbus
dpkg -P systemd dbus libpam-systemd libnss-systemd

# Add systemd removal hints to APT
printf "Package: systemd-sysv\nPin: release o=Debian\nPin-Priority:
-1\n" > /etc/apt/preferences.d/use-sysvinit
#end if

#
# Stop quiet boot, we want debuggable boot and serial.
#
sed -i 's#^\(GRUB_CMDLINE_LINUX_DEFAULT\)="quiet"$#\1="console=tty0
console=ttyS0,115200n8"#' /etc/default/grub
update-grub
====

I'm guessing either update-grub or dpkg at that point may have some effect.


Kind regards,