#848597 handling non-preseed files

#848597#5
Date:
2016-12-18 19:33:47 UTC
From:
To:
Dear Maintainer,

when DHCP server is configured to send bootfile option with iPXE script
then debian-installer fails with following "red" error:

  [!!] Download debconf preconfiguration file

  Failed to process the preconfiguration file

  The installer failed to process the preconfiguration file from <bootfile>.
  The file may be corrupt.

(where <bootfile> is value of that DHCP option)

It looks like debian-installer expects that DHCP bootfile option will
contains correct preseed file. And if that DHCP option contains not
Debian preseed file, then it show above "red" error message.

On the other hand, DHCP bootfile option is used for iPXE to specify boot
script too (can be detected by first shebang '#!ipxe' line).

Debian installer should not try to always process DHCP bootfile option
as it does not have to contain Debian preseed file...

Due to this bug booting Debian installer from iPXE setup is broken.

On http://boot.oskarcz.net/ is running such iPXE setup. You can easily
reproduce this problem by starting iPXE in qemu and trying to start
installation of Debian.

  qemu-system-x86_64 -net nic -net user,bootfile=http://boot.oskarcz.net/

#848597#10
Date:
2016-12-18 20:32:32 UTC
From:
To:
     <snip/>

That is why Debian-Installer manual has this

<quote from="https://www.debian.org/releases/jessie/armhf/apbs02.html.en#preseed-dhcp">

B.2.5. Using a DHCP server to specify preconfiguration files

It's also possible to use DHCP to specify a preconfiguration file to
download from the network. DHCP allows specifying a filename. Normally
this is a file to netboot, but if it appears to be an URL then
installation media that support network preseeding will download the file
from the URL and use it as a preconfiguration file. Here is an example of
how to set it up in the dhcpd.conf for version 3 of the ISC DHCP server
(the isc-dhcp-server Debian package).

if substring (option vendor-class-identifier, 0, 3) = "d-i" {
    filename "http://host/preseed.cfg";
}

Note that the above example limits this filename to DHCP clients that
identify themselves as "d-i", so it will not affect regular DHCP clients,
but only the installer. You can also put the text in a stanza for only
one particular host to avoid preseeding all installs on your network.
</quote>

    :-)

Please note that there is difference
between "bug" and "does not work I expect it to work"

I think that bugreporter is missing that there are *2* DHCP requests.

One from a bootROM as iPXE and the other DHCP request by Debian-Installer.
(Hence the "if statement" in the manual ( quoted above ) that should go
into DHCP server configuration)

On "CDROM boot" or "USBstick boot" there is the same Debian-Installer code
that does network configuration, which uses DHCP.


Advice: Networksniff (tcpdump, wireshark, tshark) the whole installation.
Pay special attention to the DHCP request by Debian-Installer which
can be recognisted on "d-i". Check that the DHCP reply as the URL
of the wanted preseed file. [1]

Please report the results to this bugreport.
( Keep  848597@bugs.debian.org in the loop )


Groeten
Geert Stappers

[1] If not, come back with "My setup work does not work"
  (or other wording which saves "bug" for later.)

#848597#15
Date:
2016-12-18 21:28:03 UTC
From:
To:
I have not able to find anything about it... Nor in documentation.
Thanks for link & explanation.

Yes, understood.

I know that they are two DHCP requests. Problem is that Debian installer
try to interpret bootfile (returned by second request) as preseed file
even it is not preseed file (but looks like URL).

And I consider this as a bug. As more things can look like URL, e.g.
iPXE script which can also be in bootfile option.

I know what is happening there...

#848597#20
Date:
2016-12-18 22:56:30 UTC
From:
To:
<snip/>

The DHCP bootfilename in the second request, the d-i request,
should point to a preseedfile ...
[1]

Then show your networksniff to the world.

I here by volenteer to analyze .pcap files.



Groeten
Geert Stappers

[1] Space left blank, because it is way too easy to fuel a flame war.

#848597#25
Date:
2016-12-18 23:05:45 UTC
From:
To:
For this is needed to configure DHCP in such way (that for different
DHCP clients it returns different response). And for example qemu does
not support it.

#848597#30
Date:
2016-12-18 23:19:02 UTC
From:
To:
Control: reassign -1 preseed
Control: severity -1 wishlist
Control: retitle -1 handling non-preseed files

And when it is not a preseedfile
then debian-installer fails with following "red" error:

  [!!] Download debconf preconfiguration file

  Failed to process the preconfiguration file

  The installer failed to process the preconfiguration file from <bootfile>.
  The file may be corrupt.


At least the text 'The file may be corrupt' could be changed into
'The file is not in expected format or simply corrupt'


Another change might be offering a way to retrieve preseed file from another
location. (not checked it that is allready existing)
Please do.
That still stands.


Groeten
Geert Stappers
[1] Space left blank, because it is way too easy to fuel a flame war.
--
Leven en laten leven

#848597#41
Date:
2016-12-18 23:48:12 UTC
From:
To:
Yes. (see above)

I think it does[1]. And if not, use qemu with other network options.

Please do document your solution to this (bug)report.



Groeten
Geert Stappers
[1] IIRC is QEMU using dnsmasq as DHCP server. Dnsmasq can do
  "if DHCP_vendor_class == "d-i" then reply_special()"

#848597#46
Date:
2016-12-19 00:00:35 UTC
From:
To:
With it first line like '#!preseed' or '#!debconf'
could be detected if it was a preseed file.


Groeten
Geert Stappers

#848597#51
Date:
2016-12-19 11:49:40 UTC
From:
To:
Debian preseed format or is simply corrupted.

That would be better. The whole problem is that one DHCP option is used
for several different things and recipients (in this case debian
installer) cannot distinguish if received option is for them or not.

#848597#56
Date:
2016-12-19 11:53:19 UTC
From:
To:
Looks like not, at least not my version. I checked and there is no
dnsmasq running when qemu is booting and iPXE correctly got DHCP
response. So qemu has own internal-in-qemu dhcp server.

#848597#61
Date:
2016-12-21 09:16:24 UTC
From:
To:
Pali Rohár <pali.rohar@gmail.com> writes:

Is it the case that iPXE config files are the only things we need to
worry about here?  (seems probable given the lack of previous reports)

If so, we could just check for '#!ipxe' and if found downgrade the error
to a warning, or perhaps to log what happened but otherwise ignore it.

Cheers, Phil.

#848597#66
Date:
2016-12-21 09:16:24 UTC
From:
To:
Pali Rohár <pali.rohar@gmail.com> writes:

Is it the case that iPXE config files are the only things we need to
worry about here?  (seems probable given the lack of previous reports)

If so, we could just check for '#!ipxe' and if found downgrade the error
to a warning, or perhaps to log what happened but otherwise ignore it.

Cheers, Phil.

#848597#71
Date:
2016-12-21 09:36:30 UTC
From:
To:
Philip Hands <phil@hands.com> writes:

It occurs to me that we could fix this by adding a feature.

If we had something that looked out for some string, and would interpret
it as an instruction to immediately chain into a new file, ignoring the
rest of the current file, then one could specify the preseed to use in
the iPXE config, by adding something like this near the start:

  # DEBCONF_CHAIN_LOAD(preseed.cfg)

If we were looking for /DEBCONF_CHAIN_LOAD([^(]*)/ then it would
probably work in anything that has a way of specifying comments, since
it could as easily find it after '// ', '<!-- ' or whatever, although
we'd need to survive whatever preamble such files might have -- I guess
we could additionally scan for that string anywhere in the file before
throwing the problematic error.

This ought only require us to use the parameter to populate
preseed/include and then stop processing the current file.

Cheers, Phil.

#848597#76
Date:
2016-12-21 12:38:23 UTC
From:
To:
I do not know. Maybe there are other applications which uses DHCP
bootfile option for own setup...

As DHCP bootfile can be served for any application, I think that Debian
Installer should check that file is for him, not that file is for PXE...

With your way, to just check for '#!ipxe' can be broken again in future
once there will be another application which will use bootfile option.
And it could be any fork of ipxe with new name... as it was before with
gpxe...

#848597#81
Date:
2016-12-21 12:38:23 UTC
From:
To:
I do not know. Maybe there are other applications which uses DHCP
bootfile option for own setup...

As DHCP bootfile can be served for any application, I think that Debian
Installer should check that file is for him, not that file is for PXE...

With your way, to just check for '#!ipxe' can be broken again in future
once there will be another application which will use bootfile option.
And it could be any fork of ipxe with new name... as it was before with
gpxe...

#848597#86
Date:
2016-12-21 12:43:19 UTC
From:
To:
This sounds good. With this regex we can check if file provided in DHCP
bootfile can be processed by Debian installer or not.

#848597#91
Date:
2016-12-21 21:13:38 UTC
From:
To:
True

In #848726 ( https://bugs.debian.org/848726 848726@bugs.debian.org )
is a discussion about choosing a string that makes a preseed file
easy identifable by computer.


Groeten
Geert Stappers

#848597#96
Date:
2021-04-08 05:46:29 UTC
From:
To:
I realize it's been five years since the last message here, but wanted to
chime in with a workaround for a particular use case.

Ideally there would be a way (most likely kernel param) for the installer
to either ignore DHCP filenames entirely or to carry on without complaint
if it encountered one that it considered malformed. This would allow users
who don't have control over the DHCP server to carry on.

I ran into this behavior with a libvirt/chainloaded ipxe setup. I needed
the libvirt provisioned dnsmasq instance to set the DHCP filename to power
the ipxe chainloading, but this was breaking Debian installs due to the
installer trying to interpret the ipxe chainloading file as a preseed file.
I was able to work around it by *not* setting the bootp element in the
libvirt network xml and instead setting the following dnsmasq:options:

<dnsmasq:options>
  <dnsmasq:option value="dhcp-vendorclass=debianinstaller,d-i"/>
  <dnsmasq:option value="dhcp-boot=tag:!debianinstaller,
http://192.168.234.1/chain.ipxe"/>
</dnsmasq:options>

Note that the dnsmasq:option was added to libvirt in 5.6, so you need a
fairly new version at the time of writing.

This will set the DHCP filename for any client *not* identifying itself
with the "d-i" vendor class, as explained in the Debian B.2. Using
preseeding appendix.

Sorry, this is specific to a particular use case and somewhat tangential to
the original report but the problem is obscure and this might help someone.