Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[Salvatore Bonaccorso <carnil@debian.org>]

Hi,

On Sun, Feb 19, 2023 at 07:39:02PM +0100, Cyril Brulebois wrote:
> Package: preseed
> Version: 1.113
> Severity: normal
> X-Debbugs-Cc: Salvatore Bonaccorso <carnil@debian.org>
> 
> Filing this against preseed for visibility, after Salvatore Bonaccorso
> reported that D-I Bookworm Alpha 1 was dealing with preseeding
> hostname=foo just fine, and that it's no longer the case with D-I
> Bookworm Alpha 2: the hostname question is asked, with either the
> default value (“debian”) or a value determined from the DHCP hostname
> (if any).
> 
> The relevant code didn't change on the installer side, but Linux
> mainline got a relevant commit: 5a704629f2 (first released in v6.0-rc1):
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a704629f2c1ba33bbb444cb18e6957e97c76e8f
> 
> At first glance, a side effect is that the kernel seems to “eat” the
> hostname=foo parameter instead of leaving it alone as it did in earlier
> versions, possibly hiding it from the installer:
> 
>   -Unknown kernel command line parameters "--- BOOT_IMAGE=/install.amd/vmlinuz vga=788 hostname=miaou", will be passed to userspace
>   +Unknown kernel command line parameters "--- BOOT_IMAGE=/install.amd/vmlinuz vga=788", will be passed to userspace
> 
> <red herring>
> Now, parameters might be added before or after the '---' marker, and
> moving hostname=foo from after to before this marker makes this issue go
> away.
> 
> Checking the story behind that marker, i.e. debian-installer-utils
> version 1.109 first published in jessie to fix #762007, I'm not sure
> what to think about it… A cursory look at it suggests parameters found
> after that marker should be visible to both the installer and the
> kernel, but that's not the case here.
> 
> Looking at the user-space side, I'm still seeing “hostname=foo” at the
> end of /proc/cmdline, but calling user-params only returns “quiet”, and
> that's the case for both D-I Bookworm Alpha 1 and Alpha 2. Both images
> have the same /etc/preseed_aliases, which dictates what user-params
> does.
> </red herring>
> 
> Adding DEBCONF_DEBUG=developer on the kernel command line, searching for
> lines with “cdebconf” and “hostname”, the big difference is that line,
> only in Alpha 1:
> 
>   debconf: Adding [ID] -> [netcfg/get_hostname]
> 
> It happens early in the boot process (at start-up), and that comes from
> debconf's question_variable_add() function. Right after that, there's an
> extra “frontend” line (not “cdebconf” this time) marking that question
> as seen, which means the hostname prompt is skipped down the line.
> 
> Why the difference? The actual consequence of the Linux change is not in
> /proc/cmdline or user-params or preseed, it's just just about early
> start-up: /init is run without hostname=foo in its environment, which
> explains why the debconf preseeding is no longer happening.
> 
> 
> I'm not sure where to go from here though. Compensate for this change by
> adding a special case for this parameter in env2debconf? The existing
> code seems unfriendly enough as it is… maybe implement /proc/cmdline
> lookup from netcfg instead? Not doing anything? All three options seem
> suboptimal to me…

First, this was a real use case which triggered noticing the issue
with the D-I Bookworm Alpha 1 while doing some pre-testing. 

But if there is no reasy technical way to continue having the
hostname alias support for preseed, would a pracmatic solution be to
drop support for the hostname= alias, cleanup as well the
documentation on it, and have people use the longer
netcfg/get_hostname instead?

Regards,
Salvatore