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