On Thu, 4 Dec 2014, Gene Cumm wrote:> Ady has an excellent point. Try the following instead: > > LABEL test > MENU LABEL test > COM32 pxechn.c32 > APPEND pxebsd.0Thanks, that works! How do I use that in the generic case? The ?pxebsd.0? file can be called as? ? PXE loader ? COMBOOT (16-bit) ? DOS .COM ? Multiboot (although it switches back to 16-bit mode immediately) ? from its own bootsector, if installed on disc (blocklist) Normally I?d chain into it as COMBOOT, but that no longer works (this used to work for both ISOLINUX and PXELINUX, and the other two, although I rarely tested them). Now I?ve got a working method for PXELINUX, but that leaves the others still? Thanks, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228 54881-235 HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
On Thu, Dec 4, 2014 at 11:27 AM, Thorsten Glaser <t.glaser at tarent.de> wrote:> On Thu, 4 Dec 2014, Gene Cumm wrote: > >> Ady has an excellent point. Try the following instead: >> >> LABEL test >> MENU LABEL test >> COM32 pxechn.c32 >> APPEND pxebsd.0 > > Thanks, that works! How do I use that in the generic case? > The ?pxebsd.0? file can be called as? > > ? PXE loader > ? COMBOOT (16-bit) > ? DOS .COM > ? Multiboot (although it switches back to 16-bit mode immediately) > ? from its own bootsector, if installed on disc (blocklist) > > Normally I?d chain into it as COMBOOT, but that no longer > works (this used to work for both ISOLINUX and PXELINUX, > and the other two, although I rarely tested them). > Now I?ve got a working method for PXELINUX, but that leaves > the others still?Without rewriting the MirOS boot loader as a COM32 module, reimplementing the COMBOOT system (which would likely have to be mostly in C and be BIOS-only) or making the MirOS kernel act like either an MBOOT kernel or a Linux kernel (for their boot protocols), your closest generic alternative is chain.c32. chain.c32 is capable of loading things like ntldr.sys and msdos.sys. See also doc/chain.c32. Written as a PXE NBP, there's nothing else that can load it. Thinking from a sustainability standpoint, writing your own COM32 (or perhaps extending chain.c32) or making the kernel act like an MBOOT or Linux kernel seem the better approaches. -- -Gene
On Thu, 2014-12-04 at 21:26 -0500, Gene Cumm wrote:> > Thanks, that works! How do I use that in the generic case? > > The ?pxebsd.0? file can be called as? > > > > ? PXE loader > > ? COMBOOT (16-bit) > > ? DOS .COM > > ? Multiboot (although it switches back to 16-bit mode immediately) > > ? from its own bootsector, if installed on disc (blocklist) > > > > Normally I?d chain into it as COMBOOT, but that no longer > > works (this used to work for both ISOLINUX and PXELINUX, > > and the other two, although I rarely tested them). > > Now I?ve got a working method for PXELINUX, but that leaves > > the others still? > > Without rewriting the MirOS boot loader as a COM32 module, > reimplementing the COMBOOT system (which would likely have to be > mostly in C and be BIOS-only) or making the MirOS kernel act like > either an MBOOT kernel or a Linux kernel (for their boot protocols), > your closest generic alternative is chain.c32. chain.c32 is capable > of loading things like ntldr.sys and msdos.sys. See also > doc/chain.c32. Written as a PXE NBP, there's nothing else that can > load it.Except that apparently, multiboot is one of the things it speaks. So why not got that route?