Debian Bug report logs - #1035349
regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: James Addison <jay@jp-hosting.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Mon, 01 May 2023 15:44:47 +0100

Source: preseed
Version: 1.115
Severity: important
Tags: d-i

Dear Maintainer,

This bugreport is a subset/related-to bug #1031643, also in preseed.

When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to
Bookworm's RC 2 installer as a kernel command-line argument, the value that
it contains unexpectedly takes higher precedence over a hostname received from
DHCP, contrary to the Installation Guide documentation[1] in combination with
the corresponding netcfg documentation[2].


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



Context:

Since Linux 6.0, a 'hostname=...' parameter provided in the kernel command-line
is no-longer loaded into the init process environment as a variable, but is
instead used to set the hostname of the running system (skipping the
need for userspace tooling to achieve that).

That caused a conflict for the preseed aliases in the Debian Installer, because
one of the aliases is also 'hostname', mapped to 'netcfg/get_hostname'.

The fix applied in #1031643 loads the 'running system hostname' into the
environment if it is non-empty and not equal to '(none)'.  This allows
unattended installs to work again.

The 'netcfg' component that determines the system hostname (prompting for it
from the operator if required) to be installed will prefer a non-empty hostname
(as long as it is not the literal string '(none)') over one provided by DHCP
in this block of code: https://sources.debian.org/src/netcfg/1.185/dhcp.c/#L578

Thanks,
James

[1] - https://www.debian.org/releases/stable/amd64/apbs02.en.html#preseed-aliases

[2] - https://sources.debian.org/src/netcfg/1.185/debian/netcfg-common.templates/?hl=145#L160

Message #10 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: James Addison <jay@jp-hosting.net>, 1035349@bugs.debian.org

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Mon, 1 May 2023 17:00:30 +0200

[Message part 1 (text/plain, inline)]

Hi James,

And thanks for the report/forward from elsewhere, much appreciated

James Addison <jay@jp-hosting.net> (2023-05-01):
> This bugreport is a subset/related-to bug #1031643, also in preseed.
> 
> When the 'hostname' preseed alias for 'netcfg/get_hostname' is provided to
> Bookworm's RC 2 installer as a kernel command-line argument, the value that
> it contains unexpectedly takes higher precedence over a hostname received from
> DHCP, contrary to the Installation Guide documentation[1] in combination with
> the corresponding netcfg documentation[2].
> 
> 
> 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.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: James Addison <jay@jp-hosting.net>

To: Cyril Brulebois <kibi@debian.org>

Cc: 1035349@bugs.debian.org

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Mon, 1 May 2023 17:32:14 +0100

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

Message #20 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: James Addison <jay@jp-hosting.net>

Cc: 1035349@bugs.debian.org

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Mon, 1 May 2023 18:53:18 +0200

[Message part 1 (text/plain, inline)]

James Addison <jay@jp-hosting.net> (2023-05-01):
> 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.

And that user mentioned hostname=unassigned-hostname which would be
addressed if we were to implement what I mentioned?

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

Given the following comment above the netcfg/get_* lines, I tend to
agree.

    # Any hostname and domain names assigned from dhcp take precedence over
    # values set here. However, setting the values still prevents the questions
    # from being shown, even if values come from dhcp.
    d-i netcfg/get_hostname string unassigned-hostname
    d-i netcfg/get_domain string unassigned-domain

Initially it looked like specific values were expected to lead to a
particular behaviour, but if we've been encouraging people to expect
*any* fallback values specified there, that's indeed another story.

(I had mentioned before “unassigned-hostname” wasn't to be seen in any
packages but “unassigned-domain”/“unnassigned-domain” definitely have
some specific handling.)

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

Well, yes. But that isn't what we've been doing for several releases,
and going back to something-that-used-to-be-safe still worries me, esp.
with 12.0 around the corner.

I have some pending yet unrelated things to investigate on the preseed
side; I'm not sure I'll want to be testing each and every possible
combination (esp. tweaking the configuration of the DHCP server behind
the virtualization layer), but I should be able to test the water.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: James Addison <jay@jp-hosting.net>

To: Cyril Brulebois <kibi@debian.org>

Cc: 1035349@bugs.debian.org

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Mon, 1 May 2023 19:18:23 +0100

On Mon, 1 May 2023 at 17:53, Cyril Brulebois <kibi@debian.org> wrote:
>
> James Addison <jay@jp-hosting.net> (2023-05-01):
> > 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.
>
> And that user mentioned hostname=unassigned-hostname which would be
> addressed if we were to implement what I mentioned?

Yep, fair point!

> Initially it looked like specific values were expected to lead to a
> particular behaviour, but if we've been encouraging people to expect
> *any* fallback values specified there, that's indeed another story.
>
> (I had mentioned before “unassigned-hostname” wasn't to be seen in any
> packages but “unassigned-domain”/“unnassigned-domain” definitely have
> some specific handling.)

I do see that guestfs-tools references[1] them, and I suppose other
downstream software could do as well.  But within the installer's
components, I don't think that they have any special meaning.

> I have some pending yet unrelated things to investigate on the preseed
> side; I'm not sure I'll want to be testing each and every possible
> combination (esp. tweaking the configuration of the DHCP server behind
> the virtualization layer), but I should be able to test the water.

Totally reasonable, yep.  I'll try to get familiar with the process of
rebuilding the installer's initrd.

Currently I think that a relevant patch should:

  * Unset the hostname, or set the hostname to '(none)', so that the
installer's netcfg ignores[2] and is unaware of an install-time
hostname.
  * Within env2debconf, attempt to find a hostname specified on the
kernel command-line:
    * The parameter may appear as a 'hostname=value', or
'hostname?=value' key=value pair.
    * The parameter must appear strictly before any '---' delimiter_
in the line.
  * If a hostname was found:
    * Create a local 'hostname' variable within the env2debconf'
script containing the hostname's value.
    * Ensure that the 'seen' flag is assigned appropriately:
      * The value should be empty if the hostname was matched using
'hostname=value'.
      * The value should be non-empty if the hostname as matched using
'hostname?=value'.
  * If no hostname was found:
    * Do nothing.

As I wrote up those criteria, they expanded and became more
complicated than I initially realized, so perhaps there could be
further hidden complexity here.  I'll do my best to prepare and test a
patch anyway.

[1] - https://sources.debian.org/src/guestfs-tools/1.48.3-4/customize/hostname.ml/?hl=125#L129

[2] - https://sources.debian.org/src/netcfg/1.185/dhcp.c/?hl=578#L580

Message #30 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: James Addison <jay@jp-hosting.net>, 1035349@bugs.debian.org

Cc: carnil@debian.org, andi@debian.org, freyermuth@physik.uni-bonn.de

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Wed, 3 May 2023 05:03:30 +0200

[Message part 1 (text/plain, inline)]

Hi James,

[ Sorry, insisting on a new bug report lost us a valuable thing: the
people you had cc'd initially. Adding them now. ]

James Addison <jay@jp-hosting.net> (2023-05-01):
> On Mon, 1 May 2023 at 17:53, Cyril Brulebois <kibi@debian.org> wrote:
> > And that user mentioned hostname=unassigned-hostname which would be
> > addressed if we were to implement what I mentioned?
> 
> Yep, fair point!

OK. :)

> I do see that guestfs-tools references[1] them, and I suppose other
> downstream software could do as well.  But within the installer's
> components, I don't think that they have any special meaning.

Thanks for mentioning guestfs-tools, we have other occurrences of that
particular setting in various packages:
  https://codesearch.debian.net/search?q=unassigned-hostname

As usual (not the first time you'll see me write this, not the last one):
a quick glance suggests those are mostly used inside preseed files, not on
the command line, for netcfg/get_hostname or netcfg/hostname, though.

> > I have some pending yet unrelated things to investigate on the preseed
> > side; I'm not sure I'll want to be testing each and every possible
> > combination (esp. tweaking the configuration of the DHCP server behind
> > the virtualization layer), but I should be able to test the water.
> 
> Totally reasonable, yep.

OK, thanks for the sanity check.

> Currently I think that a relevant patch should:
> 
>   * Unset the hostname, or set the hostname to '(none)', so that the
> installer's netcfg ignores[2] and is unaware of an install-time
> hostname.

Yes.

>   * Within env2debconf, attempt to find a hostname specified on the
> kernel command-line:
>     * The parameter may appear as a 'hostname=value', or
> 'hostname?=value' key=value pair.
>     * The parameter must appear strictly before any '---' delimiter_
> in the line.
>   * If a hostname was found:
>     * Create a local 'hostname' variable within the env2debconf'
> script containing the hostname's value.
>     * Ensure that the 'seen' flag is assigned appropriately:
>       * The value should be empty if the hostname was matched using
> 'hostname=value'.
>       * The value should be non-empty if the hostname as matched using
> 'hostname?=value'.
>   * If no hostname was found:
>     * Do nothing.

FWIW: This kind of heavy headscratching is exactly why I was wondering
whether to fix #1031643 in the first place. :) Spoiler alert though, I
don't think it's actually that complicated, thanks to Andreas and the
clever side-stepping of the entire problem.


Call me an optimist (famous last words…), but isn't that sufficient?
 - hostname=foo case:
    + The kernel consumes the parameter, acts on it.
    + We detect it in env2debconf (the hostname isn't “(none)”) and I
      guess we set the variable as today, but unset the hostname in
      Linux/UTS.
    + We get all the rest of the logic as previously?
 - hostname?=foo case:
    + The kernel doesn't consume the parameter, so there's no change
      from previous situation.
    + Things are as they have always been?

I don't think before/after --- changes anything there (see my initial
report, filed on Salvatore's behalf, and the red herring section there)
and I clearly don't see why one would prefer a specific one anyway.

A bit of warning: if one opens up a shell right after passing the
bootloader (e.g. the language screen is still shown, and the network
screen hasn't been reached yet – let's keep things simple), one won't
see hostname=foo there; but one will see vga=788 (assuming graphical
installer). That's probably because this particular env is inherited
from the kernel, who ate the variable away already. That doesn't mean
it's not taken into account, as can be checked in /var/lib/preseed/log:

    d-i netcfg/get_hostname string foo

IOW: It has been created within the env2debconf process, acted on, but
     it's not going to show up in other places, like in a random shell.


In summary:
 - It looks to me the first patch did make sure hostname=foo is still
   seen and acted on in userland, using the traditional logic.
 - It looks to me tweaking it to unset the hostname if it's set should
   restore “hostname is only a fallback, not actually taking priority”
   problem, while retaining the “abracadebconf” part.
 - It looks to me the kernel change should have zero impact on the
   hostname?=foo case.


Having performed the quick checking leading to this very mail, I fear
I might back out of what I thought I was going to do (testing various
combinations in some systematic manner), and instead: concentrate on
unsetting hostname in Linux/UTS, run a test or two, upload the
package, and let the rest of you all check all the combinations you
want (hostname=foo, hostname?=foo, before/after ---, with or without
DHCP supplied hostnames, etc.) using daily builds.

And if there are still actual and relevant changes from Bullseye,
please open up a new bug report detailing the use case, the past
behaviour (Bullseye) and the new behaviour (latest preseed)?


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[signature.asc (application/pgp-signature, inline)]

Message #33 received at 1035349-submitter@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <noreply@salsa.debian.org>

To: 1035349-submitter@bugs.debian.org

Subject: Bug#1035349 marked as pending in preseed

Date: Wed, 03 May 2023 04:05:54 +0000

Control: tag -1 pending

Hello,

Bug #1035349 in preseed reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/installer-team/preseed/-/commit/2d83a156b3e50e3a35dd9964090967ac1761f85f

------------------------------------------------------------------------
env2debconf: reset hostname to '(none)' if set (#1035349).

env2debconf: if hostname is set, keep propagating it (see previous
changelog entry) but also reset it to the default “(none)” value so
that netcfg considers DHCP-provided hostnames. This restores the
longstanding semantics, i.e. defining a fallback instead of taking
priority (Closes: #1035349).
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1035349

Message #40 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: James Addison <jay@jp-hosting.net>, 1035349@bugs.debian.org

Cc: carnil@debian.org, andi@debian.org, freyermuth@physik.uni-bonn.de

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Wed, 3 May 2023 06:10:48 +0200

[Message part 1 (text/plain, inline)]

Control: tag -1 patch

Hi again,

Cyril Brulebois <kibi@debian.org> (2023-05-03):
> In summary:
>  - It looks to me the first patch did make sure hostname=foo is still
>    seen and acted on in userland, using the traditional logic.
>  - It looks to me tweaking it to unset the hostname if it's set should
>    restore “hostname is only a fallback, not actually taking priority”
>    problem, while retaining the “abracadebconf” part.
>  - It looks to me the kernel change should have zero impact on the
>    hostname?=foo case.
> 
> 
> Having performed the quick checking leading to this very mail, I fear
> I might back out of what I thought I was going to do (testing various
> combinations in some systematic manner), and instead: concentrate on
> unsetting hostname in Linux/UTS, run a test or two, upload the
> package, and let the rest of you all check all the combinations you
> want (hostname=foo, hostname?=foo, before/after ---, with or without
> DHCP supplied hostnames, etc.) using daily builds.

It's entirely untested for the time being, but I've tested a few things
inside an installer context, checking how hostname behaves when setting
and when getting the hostname (even if I already alluded to it in the
other bug report), and picking one of two possible options. You can find
details in the comments above the command getting added:
  https://salsa.debian.org/installer-team/preseed/-/commit/2d83a156b3e50e3a35dd9964090967ac1761f85f

I'll probably just find a dnsmasq config to tweak to force hostnames,
check a netboot/gtk/mini.iso against it, and upload if that behaves
better than D-I Bookworm RC 2.

In the meanwhile, if you spot something fishy in the reasoning or in the
implementation, please let me know.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[signature.asc (application/pgp-signature, inline)]

Message #47 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: Cyril Brulebois <kibi@debian.org>

To: James Addison <jay@jp-hosting.net>, 1035349@bugs.debian.org

Cc: carnil@debian.org, andi@debian.org, freyermuth@physik.uni-bonn.de

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Wed, 3 May 2023 07:33:29 +0200

[Message part 1 (text/plain, inline)]

Hi,

Cyril Brulebois <kibi@debian.org> (2023-05-03):
> It's entirely untested for the time being, but I've tested a few things
> inside an installer context, checking how hostname behaves when setting
> and when getting the hostname (even if I already alluded to it in the
> other bug report), and picking one of two possible options. You can find
> details in the comments above the command getting added:
>   https://salsa.debian.org/installer-team/preseed/-/commit/2d83a156b3e50e3a35dd9964090967ac1761f85f
> 
> I'll probably just find a dnsmasq config to tweak to force hostnames,
> check a netboot/gtk/mini.iso against it, and upload if that behaves
> better than D-I Bookworm RC 2.

Setting “hostname=foo” at the very end of the ISOLINUX or GRUB prompts,
respectively under KVM and its default configuration (no DHCP-provided
hostnames) and on a Dell laptop connected to a dnsmasq assigning DHCP
hostnames:

 - With RC 2, the hostname prompt is skipped, and “foo” is used in both
   cases.

 - With the modified netboot/gtk/mini.iso, the hostname prompt is
   skipped as well, “foo” is used under KVM, but “dellicious” is used on
   baremetal despite the hostname=foo trap.

And when I say “is used”, I mean ends up being stored for cdebconf under
netcfg/get_hostname (at least according to /var/lib/preseed/log), instead
of “foo” previously.

Notes:
 - I didn't actually perform any of those 4 installations in full.
 - Package just uploaded.
 - Daily builds dated 2023-05-04 should have all the required bits;
   I might trigger an out-of-crontab build for amd64/i386 later today
   if that helps people start testing right away.

> In the meanwhile, if you spot something fishy in the reasoning or in
> the implementation, please let me know.

Still valid.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[signature.asc (application/pgp-signature, inline)]

Message #52 received at 1035349-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 1035349-close@bugs.debian.org

Subject: Bug#1035349: fixed in preseed 1.116

Date: Wed, 03 May 2023 06:21:24 +0000

Source: preseed
Source-Version: 1.116
Done: Cyril Brulebois <kibi@debian.org>

We believe that the bug you reported is fixed in the latest version of
preseed, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1035349@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois <kibi@debian.org> (supplier of updated preseed package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Wed, 03 May 2023 07:20:10 +0200
Source: preseed
Architecture: source
Version: 1.116
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Changed-By: Cyril Brulebois <kibi@debian.org>
Closes: 1035349
Changes:
 preseed (1.116) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * env2debconf: if hostname is set, keep propagating it (see previous
     changelog entry) but also reset it to the default “(none)” value so
     that netcfg considers DHCP-provided hostnames. This restores the
     longstanding semantics, i.e. defining a fallback instead of taking
     priority (Closes: #1035349).
 .
   [ Updated translations ]
   * Georgian (ka.po) by Temuri Doghonadze
Checksums-Sha1:
 49190e79a72317842a8b14a0088eafb5786c071f 1887 preseed_1.116.dsc
 9893af560aa77b94909c5bcd8db897b2ba9fa25a 87748 preseed_1.116.tar.xz
 c5034dd78c29974d5b82f19f5dc8b6dca8fa59ba 6407 preseed_1.116_source.buildinfo
Checksums-Sha256:
 bc9ff0a75e1a7f5d956b08c14410a77986f776b526a122e7fd98365fd974e370 1887 preseed_1.116.dsc
 933e924b3d43ff58592c7009ddf92cf9656150009ba1f3fd747db0e48f0f3326 87748 preseed_1.116.tar.xz
 8a741e6a764e3c99270086459be208d734c682d0c13f68c06f79d59eddfbb75c 6407 preseed_1.116_source.buildinfo
Files:
 4700c408a59f638f11bba7080ad2bae8 1887 debian-installer optional preseed_1.116.dsc
 2d3329e7e1c9bec3fec1c5c01fdb8a15 87748 debian-installer optional preseed_1.116.tar.xz
 e62b7264431f1ece934e35fa03da3d5c 6407 debian-installer optional preseed_1.116_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRR738QHGtpYmlAZGVi
aWFuLm9yZwAKCRD/kUrwwrNVIC9QEADBJk6oPcg6JMwpJGZnMJBgcq2ALf+R4Pab
x24sZmDrSOuOcdL3Jm0bIDvXr0IG7JK2aPhbFhhSsUypPhHsaJ8bGqGTeETpldRq
ag0Ohr4nnx5yoVtM6Qh34aDdXL3NqUxyv9Hy4YWzUbzzxaSRYSYcl96OFdfAVREP
gOWb2TJhE7pa3wRYF7oILqM5EwGrMrYW2aSlSbAIKD9iJmE8D4etyKNxiXfksIGD
m0jpMBKLpAxVb0TNOwW1z6KNtBm+t0seMM9AZrPxBbP13mh4T5v09dRvmj/WE/rP
jkAFP3VjRIc5CDbV/7pMiIe78+7aJNl+VTNZMUUUXFBnKjK/X8O5GOzwfaTS8JiY
Ojb7CPLD/nW4iRKmXgEJQ8fF8gf7MyWHz4kNdGvUlmngPuuoY4/wp44b2aQCJbWP
4whu0J/zlNC2rpbHjMDNbed3bGcm+2O2hgIx99WhdsXAaWlM4cmEmhIioFW6/lLr
Y6Hp9JXHiP5nS4cQ77lFq6/5jZKi2m/RCNf4vRqrMBzBue4XAC/QydK1d9fioJdl
Xiy1aElh0E3f1+lkVJGgPsige2E2MeG7hGE+yDVCUwTE32fx+bVqHm4OISE+Dp9+
adjHIQTXeBzfu9JDOiNEA0N6DDHMglMl6RjdUwupr6ursqre+OKvuMZ8GwB19ziq
Rg5YIV7EsA==
=dWy/
-----END PGP SIGNATURE-----

Message #57 received at 1035349@bugs.debian.org (full text, mbox, reply):

From: James Addison <jay@jp-hosting.net>

To: Cyril Brulebois <kibi@debian.org>

Cc: 1035349@bugs.debian.org, carnil@debian.org, andi@debian.org, freyermuth@physik.uni-bonn.de

Subject: Re: Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

Date: Wed, 3 May 2023 13:24:52 +0100

On Wed, 3 May 2023 at 04:03, Cyril Brulebois <kibi@debian.org> wrote:
> James Addison <jay@jp-hosting.net> (2023-05-01):
> > On Mon, 1 May 2023 at 17:53, Cyril Brulebois <kibi@debian.org> wrote:
> > I do see that guestfs-tools references[1] them, and I suppose other
> > downstream software could do as well.  But within the installer's
> > components, I don't think that they have any special meaning.
>
> Thanks for mentioning guestfs-tools, we have other occurrences of that
> particular setting in various packages:
>   https://codesearch.debian.net/search?q=unassigned-hostname
>
> As usual (not the first time you'll see me write this, not the last one):
> a quick glance suggests those are mostly used inside preseed files, not on
> the command line, for netcfg/get_hostname or netcfg/hostname, though.

Agreed, I think.

Rephrasing it, to check: 'unassigned-hostname' (and similarly,
'unassigned-domain') commonly appears as an input to preseed
configuration (usually as a placeholder or sample value).  A limited
number of tools may have code that compares against that value, but
those should be rare.

> > > I have some pending yet unrelated things to investigate on the preseed
> > > side; I'm not sure I'll want to be testing each and every possible
> > > combination (esp. tweaking the configuration of the DHCP server behind
> > > the virtualization layer), but I should be able to test the water.
> >
> > Totally reasonable, yep.
>
> OK, thanks for the sanity check.
>
> > Currently I think that a relevant patch should:
> >
> >   * Unset the hostname, or set the hostname to '(none)', so that the
> > installer's netcfg ignores[2] and is unaware of an install-time
> > hostname.
>
> Yes.

Thanks - your patch in src:preseed to do that looks good.

> >   * Within env2debconf, attempt to find a hostname specified on the
> > kernel command-line:
> > ...
>
> FWIW: This kind of heavy headscratching is exactly why I was wondering
> whether to fix #1031643 in the first place. :) Spoiler alert though, I
> don't think it's actually that complicated, thanks to Andreas and the
> clever side-stepping of the entire problem.
>
>
> Call me an optimist (famous last words…), but isn't that sufficient?
>  - hostname=foo case:
>     + The kernel consumes the parameter, acts on it.
>     + We detect it in env2debconf (the hostname isn't “(none)”) and I
>       guess we set the variable as today, but unset the hostname in
>       Linux/UTS.
>     + We get all the rest of the logic as previously?
>  - hostname?=foo case:
>     + The kernel doesn't consume the parameter, so there's no change
>       from previous situation.
>     + Things are as they have always been?

Perfect, I think that's true.

I'd _noticed_ Andi's mention of the 'hostname?=' testing.. hadn't
properly parsed or understood what it meant (rephrasing again: it's
not a recognized kernel parameter, so it's unaffected).

Thanks for the recap, and that reassures me (mostly!) that this is
safe.  I'll continue to try to think of edge cases, but hopefully will
only spend my own time by doing that.

A probably-irrelevant thought: the fixes applied for  #1031643 and
#1035349 also seem like they should be backwards-compatible with
pre-6.x kernels.

> I don't think before/after --- changes anything there (see my initial
> report, filed on Salvatore's behalf, and the red herring section there)
> and I clearly don't see why one would prefer a specific one anyway.
>
> A bit of warning: if one opens up a shell right after passing the
> bootloader (e.g. the language screen is still shown, and the network
> screen hasn't been reached yet – let's keep things simple), one won't
> see hostname=foo there; but one will see vga=788 (assuming graphical
> installer). That's probably because this particular env is inherited
> from the kernel, who ate the variable away already. That doesn't mean
> it's not taken into account, as can be checked in /var/lib/preseed/log:
>
>     d-i netcfg/get_hostname string foo
>
> IOW: It has been created within the env2debconf process, acted on, but
>      it's not going to show up in other places, like in a random shell.

Understood.

And in particular: yes, the hostname variable that we're creating (and
then reading-back by invoking 'set') is local to the env2debconf
script, and that's good.

> In summary:
>  - It looks to me the first patch did make sure hostname=foo is still
>    seen and acted on in userland, using the traditional logic.
>  - It looks to me tweaking it to unset the hostname if it's set should
>    restore “hostname is only a fallback, not actually taking priority”
>    problem, while retaining the “abracadebconf” part.
>  - It looks to me the kernel change should have zero impact on the
>    hostname?=foo case.

Agreed on all three of these.

> Having performed the quick checking leading to this very mail, I fear
> I might back out of what I thought I was going to do (testing various
> combinations in some systematic manner), and instead: concentrate on
> unsetting hostname in Linux/UTS, run a test or two, upload the
> package, and let the rest of you all check all the combinations you
> want (hostname=foo, hostname?=foo, before/after ---, with or without
> DHCP supplied hostnames, etc.) using daily builds.
>
> And if there are still actual and relevant changes from Bullseye,
> please open up a new bug report detailing the use case, the past
> behaviour (Bullseye) and the new behaviour (latest preseed)?

Will do (both testing, and filing any other behavioural-change
bugreports separately).

Thanks again,
James

Send a report that this bug log contains spam.