On 24.04.2018 13:23, Thomas Huth wrote: > On 24.04.2018 13:07, Viktor VM Mihajlovski wrote: >> On 23.04.2018 09:58, Thomas Huth wrote: >>> Since it is quite cumbersome to manually create a combined kernel with >>> initrd image for network booting, we now support loading via pxelinux >>> configuration files, too. In these files, the kernel, initrd and command >>> line parameters can be specified seperately, and the firmware then takes >>> care of glueing everything together in memory after the files have been >>> downloaded. >>> >>> The user can either specify a config file directly as bootfile via DHCP >>> (but in this case, the file has to start either with "default" or a "#" >>> comment so we can distinguish it from binary kernels), or a folder (i.e. >>> the bootfile name must end with "/") where the firmware should look for >>> the typical pxelinux.cfg file names based on MAC or IP address. If no >>> direct file or folder has been specified, we still look for certain >>> files in the default "pxelinux.cfg/" folder, but omit some of the file >>> names to avoid to download x86 config files here by mistake. >> I don't think this is necessary, since the DHCP server configuration >> SHOULD take into consideration the processor architecture. In fact it is >> even annoying and hard to understand that an attempt is made to load the >> uuid, mac and "full ip" based config files but not the "abbreviated ip" >> or default file. > > If the DHCP server has been been properly configured to take the > processor architecture into account, there should be a usable entry in > the bootfile (i.e. either a binary, a config file or a folder where > config files should be probed). So in this case the skipping does not > take place. > > And if you want the full probing in the pxelinux.cfg/ directory, you can > also specify "pxelinux.xfg/" in the bootfile entry. > > The skipping only happens if there is no valid entry in the bootfile, > i.e. the server configuration was likely wrong anyway, and we just do > some desperate final guesses with the default "pxelinux.cfg/" directory > before giving up. > My major concern is consistency. The emergency probing is different from the normal one and this can be hell to debug (it took me a while to understand what went wrong[1]). I like the idea to improve the usability by doing a wild guess, but only if it is consistent with the regular behavior. >> After all, even if the config file for x86 was loaded, >> the effect will be that the network boot fails (as it does now). > > Ok, that's true, too. > > Actually, I don't mind too much whether we probe the files based on the > partial IP address or the "default" name, or whether we skip them. I > thought it might be a good idea to avoid a potential clash with x86 > files, but if you think that this is rather confusing, I also see your > point. So I'd say let's wait for some more opinions from others before > we decide about the final behavior... > > Thomas >
[1] What I did was to keep my previous pxelinux configuration but delete the pxelinux.0 file on the server to force the built-in processing. -- Regards, Viktor Mihajlovski
