On 29.06.2017 09:58, Thomas Huth wrote: > 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. That sounds more than fair. Thanks! > > Thomas >
-- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294