Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname
On Mon, 1 May 2023 at 16:00, Cyril Brulebois <kibi@debian.org> wrote:
> James Addison <jay@jp-hosting.net> (2023-05-01):
> > Conditions:
> >
> > * Preseed alias 'hostname' configured on the kernel command-line
> > * There is a DHCP server on the installation-target's network that will provide a hostname
> >
> > Expected behaviour:
> >
> > * Installer does not ask for installation-target hostname
> > * Installation-target hostname is received and configured using DHCP
> >
> > Actual behaviour:
> >
> > * [good] Installer does not ask for hostname
> > * [bad] Hostname is configured from the command-line, ignoring the DHCP-negotiated hostname.
> > * This is similar to 'netcfg/hostname' -- a different setting from 'netcfg/get_hostname'.
>
> Given the proximity of the tentative Bookworm release, my gut feeling
> would be to special-case the hostname=unassigned-hostname setting that's
> been documented since at least 2004, and limit “unsetting hostname” to
> this particular case.
>
> This should:
> 1. be good enough for anyone having followed the example preseed from
> any point in the past;
> 2. and equally importantly: limit possible side-effects.
>
> If that's not the case for (1), we should get bug reports with details
> about what people have actually been doing, and whether it makes sense
> to unset it unconditionally. If that's the case, we can let this thing
> mature in unstable/testing post-Bookworm, and once we're absolutely
> certain this isn't going to regress in some other weird way, we can
> consider backporting this to Bookworm, via a point release.
I understand that line of thinking, but we note that we have already
received feedback on Salsa[1] from a user whose Bookworm installation
workflow has been affected, and confirmed that the reported problem
exists.
One datapoint isn't huge, but it's non-zero - and I'd expect that any
installation using the 'hostname' preseed alias in combination with
DHCP-as-hostname-provider would be similarly affected.
The bug here is essentially that the 'hostname' alias used to provide
a fallback value, and in RC 2 d-i is used as the source of the primary
value (ignoring DHCP). If we know that that change has taken place, I
think that we should either document it, or attempt to restore the
existing behaviour.
The possibility about introducing other regressions with any further
changes is a valid point.. I'm not sure how best to address that,
other than testing the results in various configurations.
It feels to me like 'installer begins running without its own
hostname' was likely a reasonable baseline assumption before Linux 6.0
began reading the same-named 'hostname' parameter, and so as a result
it feels like unsetting the hostname early in the installer
initialization would be safe (maybe even a good idea, to reduce a
source of input variation between install sessions).
[1] - https://salsa.debian.org/installer-team/installation-guide/-/merge_requests/25
Reply to: