On 28.06.2017 17:02, Viktor Mihajlovski wrote: > On 28.06.2017 12:56, Thomas Huth wrote: >> On 28.06.2017 10:02, Thomas Huth wrote: >>> On 28.06.2017 09:28, Viktor Mihajlovski wrote: >>>> On 27.06.2017 23:40, Thomas Huth wrote: >>>> [...] >>>>>>> - Is it OK to require loading an .INS file first? Or does anybody >>>>>>> have a better idea how to load multiple files (kernel, initrd, >>>>>>> etc. ...)? >>>>>> It would be nice to support PXE-style boot, because the majority of boot >>>>>> servers is set up that way. A straightforward way would be to do a PXE >>>>>> emulation by attempting to download a pxelinux.cfg from the well-known >>>>>> locations, parsing the content (menu) and finally load the kernel, >>>>>> initrd and set the kernel command line as specified there. (I know, but >>>>>> you're already parsing the INS-File). >>>>> >>>>> Please, don't mix up PXE and pxelinux (since you've used both terms in >>>>> above paragraph). Assuming that you're only talking about pxlinux config >>>>> files... are they that common on s390x already? Using the pxelinux >>>>> config file syntax sounds like we would be completely bound to only >>>>> loading Linux guests to me, since the boot loader has to know where to >>>>> load the initrd and how to patch the kernel so that it can find the >>>>> initrd. >>>>> Using .INS files sounds more flexible to me instead, since you can also >>>>> specify the addresses here - so you can theoretically also load other >>>>> guest kernels, and that's IMHO the better approach since a firmware >>>>> should stay as generic as possible. >>>>> >>>> In order to be consumable, the network boot should support the most >>>> common configurations. I would think that most network boot servers are >>>> setup as PXE boot servers using pxelinux configs. >>> >>> Are you really sure about the popularity of pxelinux? It's just one >>> flavor of secondary stage network boot loaders - which also only exist >>> on x86 so far, as far as I know. >> >> And it seems like it also only works with legacy BIOSes, i.e. you can >> not use it on EFI-only systems, if I've got that right: >> >> https://github.com/openSUSE/kiwi/wiki/Setup-PXE-boot-with-EFI-Using-GRUB2 >> >> So I guess the significance of pxelinux will very likely decrease in >> the next years... >> > Maybe, but supposed goners tend to linger more often than not. I.e., the > syslinux project offers a EFI bootloader called syslinux.efi equivalent > to the pexelinux.0 BIOS loader. > Further, the OPAL firmware of newer POWER systems embeds petitboot and > thus offers PXELINUX-compatible network boot as well.
OK, true, ... you're slowly get me convinced that this pxelinux.cfg stuff is maybe not such a bad idea after all ... So I guess supporting at least the basic commands from the pxelinux config file would be appropriate... (the full set of commands is huge, see http://www.syslinux.org/wiki/index.php?title=Config ) > I appreciate the idea of a proper BOOTP implementation though, so maybe > a compromise could be to start off with your proposal with the slight > modification that the final boot action is controlled by the bootfile > content (file magic), similar to what you suggested in order to support > both insfile and binary kernel. PXELINUX emulation could be triggered by > a specially crafted bootfile then. What do you think? Yes, something like this could work: 1) Do DHCP to get TFTP server address and boot file name 2) Load the boot file from the TFTP server to address 0 3) If the boot file name ended with ".ins" or ".INS" (and the content starts with the "* " magic), treat it as an .INS file and load the files that are listed in there accordingly 4) If the boot file looks like a kernel, start it directly 5) If not successful in 3 or 4, start looking for a pxelinux config file by trying to download the config files as specified in http://www.syslinux.org/wiki/index.php?title=PXELINUX#Configuration and then parse the file and load the kernel + initrd accordingly. Quite a bit of work, so I'll continue to ignore 5 for the first versions, but I agree now that it can certainly be added later. Thomas