On Mon, Dec 29, 2014 at 04:15:56AM -0800, Patrick Masotta wrote:> On Mon, Dec 29, 2014 at 08:47:54AM +0100, Luke Ledgerd wrote: > > I think I'd like to ask for a feature request to allow pxechn.c32 > > to work with EFI too and to have the ability for PXELinux to have a > > ROOT path variable (kind of like gpxelinux.0) that can either have > > HTTP or TFTP urls. That would be a very useful addition to PXELinux. > > I do not think pxechn.c32 can ever be EFI capable > but I agree with you something like pxechn.e32/e64 would be > very handy. Is it too hard to code?I guess it is only a matter of porting. Groeten Geert Stappers -- Leven en laten leven ------------- volgend deel ------------ Een niet-tekst bijlage is gescrubt... Naam: signature.asc Type: application/pgp-signature Grootte: 836 bytes Omschrijving: Digital signature URL : <http://www.zytor.com/pipermail/syslinux/attachments/20141229/abd3fbf3/attachment.sig>
I'm looking for either a way of setting the root path - a Linux style "pivot_root" functionality, that would be perfect. Also a way of overriding prefixing the root path with a URL or some other acceptable syntax to designate to use a different TFTP server. That would really make PXELinux really versatile. Some people concerned about security may want a way of blocking that just like the escape key, but hey if the people can edit the files on your TFTP server you are boned already ;) If this was to be implemented, then the PATH command should be unaffected, because that's where people configure their COMBOOT modules to load from, and it would break all that or you'd have to put two copies of PXELinux on both servers. Does the EFI version of PXELinux support http like gpxe, that would be awesome loading down those 400 meg wim Windows PE File and loading them using wimboot from ipxe (that works still with PXELinux) - only I only got it working so far with tftp that makes no difference ;) Also why was I calling it PXE 3? Well the cards say they are version 3 when you look at the network analyzer and this is from the EFI SPEC. "Type (1), Ma jorVer (1), MinorVer (1) Type is a one byte field that i dentifies the network interface that will be used by the downloaded program. Type is followed by two one byte version number fields, MajorVer and MinorVer. Type UNDI (1) = 0x01 Versions WfM-1.1a 16-bit UNDI: MajorVer = 0x02. MinorVer = 0x00 PXE-2.0 16-bit UNDI: MajorVer = 0x02, MinorVer = 0x01 32/64-bit UNDI & H/W UNDI: MajorVer = 0x03, MinorVer = 0x00" ^^^^ See the line directly above ;) ^^^^ I'm not saying I'm right - but it's unofficially version 3. -----Original Message----- From: Syslinux [mailto:syslinux-bounces at zytor.com] On Behalf Of Geert Stappers Sent: Monday, December 29, 2014 8:16 PM To: syslinux at zytor.com Subject: Re: [syslinux] pxechn.c32 for EFI On Mon, Dec 29, 2014 at 04:15:56AM -0800, Patrick Masotta wrote:> On Mon, Dec 29, 2014 at 08:47:54AM +0100, Luke Ledgerd wrote: > > I think I'd like to ask for a feature request to allow pxechn.c32 to > > work with EFI too and to have the ability for PXELinux to have a > > ROOT path variable (kind of like gpxelinux.0) that can either have > > HTTP or TFTP urls. That would be a very useful addition to PXELinux. > > I do not think pxechn.c32 can ever be EFI capable but I agree with you > something like pxechn.e32/e64 would be very handy. Is it too hard to > code?I guess it is only a matter of porting. Groeten Geert Stappers -- Leven en laten leven
On Mon, Dec 29, 2014 at 8:16 AM, Geert Stappers <stappers at stappers.nl> wrote:> On Mon, Dec 29, 2014 at 04:15:56AM -0800, Patrick Masotta wrote: >> On Mon, Dec 29, 2014 at 08:47:54AM +0100, Luke Ledgerd wrote: >> > I think I'd like to ask for a feature request to allow pxechn.c32 >> > to work with EFI too and to have the ability for PXELinux to have a >> > ROOT path variable (kind of like gpxelinux.0) that can either have >> > HTTP or TFTP urls. That would be a very useful addition to PXELinux. >> >> I do not think pxechn.c32 can ever be EFI capable >> but I agree with you something like pxechn.e32/e64 would be >> very handy. Is it too hard to code? > > I guess it is only a matter of porting.Yes/no. I do agree that a pxechn.c32-like module for both EFI architectures would be useful. However, it should be approached in stages: 1) SYSLINUX on EFI must be extended to load arbitrary EFI binaries (perhaps through a module first like how linux.c32's code became the Linux loader). 2) If EFI allows for extra parameters, such functionality should be utilized for passing the prefix and CONFIG. If not, functionality akin to pxechn.c32 would be needed to alter the environment. As I recall, when I wrote pxechn.c32 (which is basically some PXE RAM data manipulation code atop parts of an older chain.c32 codebase), I tried to take reasonable precautions to prevent it from touching RAM outside what might be available for the altered packet. -- -Gene
> 1) SYSLINUX on EFI must be extended to load arbitrary > EFI binaries > (perhaps through a module first > like how linux.c32's code became the > Linux loader).Do you know 6.03 status on this topic? i.e. can something like bootmgfw.efi be booted today or not? Pat
On Mon, Dec 29, 2014 at 11:45 AM, Luke Ledgerd <luke.ledgerd at niteco.se> wrote:> Does the EFI version of PXELinux support http like gpxe, that would be awesome loading down those 400 meg wim Windows PE File and loading them using wimboot from ipxe (that works still with PXELinux) - only I only got it working so far with tftp that makes no difference ;)Technically, there's only one core binary for each EFI architecture (syslinux.efi) while there's four for BIOS (ldlinux.sys, isolinux.sys, pxelinux.0 and lpxelinux.0; gpxelinux.0/ipxelinux.0 are encapsulations of pxelinux.0; pxelinux.0 and lpxelinux.0 are loaded the same way but interface hardware differently). But, to answer the question, my understanding is that it depends on the underlying EFI system. In VMware Workstation 10 with an EFI64 VM, I've had luck with pointing SYSLINUX to an HTTP URL for the prefix. Additionally, it's my understanding that EFI only provides file access and to provide the raw network access needed (or even TCP sockets) in order to use our own HTTP stack would require far more access (and likely something closer to a full kernel). -- -Gene