On 20.04.2018 09:54, Viktor VM Mihajlovski wrote:
> On 20.04.2018 09:36, Thomas Huth wrote:
>> On 20.04.2018 08:53, Viktor VM Mihajlovski wrote:
>>> On 19.04.2018 18:55, Thomas Huth wrote:
> [...]
>>> Well, if we don't add another identifier, and I feel reluctant about it
>>> as well for the reasons you wrote, we may stick with 0x1f and consider
>>> the additional capabilities as being optional (for special needs only).
>>
>> I tend to stay with 0x1f, since booting binaries is still the "primary"
>> interface (the first check for the "default" or "# " magic keywords is
>> not 100% reliable, since the config file could also start with another
>> command, and the probing of pxelinux.cfg/* files is only tried afterwards).
>>
> Good. It would be important though to define and document the best way
> to configure a pxelinux setup: empty bootfile name, bootfile empty (or
> not existent) or a special file format for the bootfile content (like
> 'PXE0' in EBCDIC). The former two carry the danger of accidentally
> enabling the pxe-style boot process.
I don't like the idea of providing a bootfile with a magic content ...
if you have to provide a bootfile, you could also go with specifying
pxelinux.cfg/default (or whatever) directly, you just have to make sure
that the file starts with the right magic ("default" or "# ").
But I agree that starting to guess the non-MAC-based filenames in case
the boot file name is empty carries some danger, indeed. If we load
pxelinux.cfg/default on s390x, who guarantees that this was not the
default file for x86 instead? Maybe we should rather use "pzelinux.cfg"
as directory ;-) ?
Or maybe it would rather make sense to force the users to specify the
path to the pxelinux config files instead, ending with a slash, so they
have to put "pxelinux.cfg/" or whatever location into the bootfile
parameter?
Thomas
