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
Attachment:
signature.asc
Description: PGP signature