similar to: pxelinux 6.03 lua module not loading syslinux.c32 dmi.c32 etc

Gene, As it happened I started working on this again just as you mailed me. It appears that PXE-E99 may also be related to MTFTP part of the PXE spec. IBM also says it has something to do with jumbo frames. I tried setting PXE.mtcp-ip to 0.0.0.0 to disable it but still no joy. The bootfile size shows up as zero because that relates to "option boot-size" in dhcp and doesn't seem to

http://www.niallbrady.com/2014/06/11/when-uefi-network-booting-on-a-hyperv-gen-2-vm-you-might-get-pxe-e99-unexpected-network-error/ P.S. It's not this and I'm getting a PXE-E99 tftp failure "Unexepected Network Error", so I'll guess I'll need to investigate what kind of TFTP server makes hyper-v happy. Virtualbox, VmWare seem to have the same EFI boot code & output

On Thu, Nov 27, 2014 at 8:59 AM, Luke Ledgerd <luke.ledgerd at niteco.se> wrote: > Gene, > > As it happened I started working on this again just as you mailed me. I saw it in IRC. > It appears that PXE-E99 may also be related to MTFTP part of the PXE spec. IBM also says it has something to do with jumbo frames. I tried setting PXE.mtcp-ip to 0.0.0.0 to disable it but still no

I have an interest in booting Windows PE from PXELinux, and it seems that wimboot from ipxe project is the solution. http://ipxe.org/wimboot MENU LABEL Windows 8.1 Enterprise PE Rescue (wimboot) com32 linux.c32 /wimboot APPEND initrdfile=/windows/win81/bootmgr,/windows/win81/boot/bcd,/windows/win81/boot/boot.sdi,/windows/win81/sources/boot.wim The initrdfile= is supported in Syslinux from

On Mon, Nov 24, 2014 at 3:24 AM, Luke Ledgerd <luke.ledgerd at niteco.se> wrote: > http://www.niallbrady.com/2014/06/11/when-uefi-network-booting-on-a-hyperv-gen-2-vm-you-might-get-pxe-e99-unexpected-network-error/ > > P.S. It's not this and I'm getting a PXE-E99 tftp failure "Unexepected Network Error", so I'll guess I'll need to investigate what kind of

Hi, we use PXELINUX in our product to show a boot menu on client computers, with options like "Boot from local hard disk", "Install Windows", etc. Unfortunately, a lot of computers seem to have broken BIOSes and won't boot with the LOCALBOOT command, and need to be booted with chain.c32 instead. We also have encountered some computers where it works only the other way -

Adding an option for initrdfile= boot argument to be ignored by wimboot worked just fine. They can add this patch, which is probably most sane, or syslinux could add the INITRDFILE configuration option instead of having to append the option for linux.c32 wimboot-2.4.0/src/cmdline.c @ Line ~107 } else if ( key == cmdline ) { /* Ignore unknown initial

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

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.

From: Hung-chi Lihn <hlihn at google.com> In the current Lua.c32 DMI implementation, it is a flat table with dotted names in table entries. It also misses a number DMI sub-tables. This patch, cleans up the DMI table structure using Lua's nested table structure and adds all missing DMI sub-tables. If a DMI sub-table is not supported by the hardware (not filled), then the corresponding

Hi again, this is the second part of the patch extending lua. This time it adds the dmi functions (com32/modules/dmi*) to lua: dmi.supported(): returns true if DMI is supported dmi.gettable(): returns array of key, value pairs containing system info Sorry, but this patch does not apply cleanly if [PATCH 1/2] was applied before. There's just one line to fix in com32/lua/src/linit.c

Hey guys, We are going with WDS to fire up first to get the benefits of targeted M$ deployments. If you have the "handle unknown computers" off on your M$ Distribution point, then you can still use regular WDS which runs next as a PXE filter (DLL linked into WDS) to fire off anything you want to including PXELinux. The stuff I was talking about before with PXELinux not working in

On Dec 25, 2014 2:11 AM, "Luke Ledgerd" <luke.ledgerd at niteco.se> wrote: > > Hey guys, > > We are going with WDS to fire up first to get the benefits of targeted M$ deployments. If you have the "handle unknown computers" off on your M$ Distribution point, then you can still use regular WDS which runs next as a PXE filter (DLL linked into WDS) to fire off

Hi, I have been experimenting a bit with lua.c32 and I have created a small lua.c32 wiki page at: http://syslinux.zytor.com/wiki/index.php/Lua.c32 With my minimal knowledge about Lua (and the inconvenience of not being able to copy&paste or edit scripts) I discovered that the dmi module has 2 functions (supported, gettable) and a syslinux module with 1 function (run_command). Do we

Hi, the first attached patch extends the argument parsing code to allow (shell like) spaces. A config like LABEL BIOSupdate KERNEL dmiselect.c32 APPEND "ESPRIMO P5925" "memdisk initrd=/dos/FSC-E5925.img raw" will result in args[]: ESPRIMO P5925 memdisk initrd=/dos/FSC-E5925.img raw instead of (current code): "ESPRIMO P5925" "memdisk

The following are new Lua c32 modules in 6.03-pre*: cmenu.c32: cpu.c32: dhcp.c32: dmi.c32: lfs.c32: pci.c32: syslinux.c32: vesa.c32: I am wondering whether the following modules, which are _not_ new and are also included in 6.03-pre*, have _any_ relation either to the above list or to Lua: cpuid.c32: cpuidtest.c32: dmitest.c32: pcitest.c32: vesainfo.c32: TIA, Ady.

Greetings All. We wanted to be able to parse the DHCP values and options and write a lua script based on the information found. We are also using the CPU flags, but thankfully in at least version 4.04 there is already some CPU value parsing even if it isn't documented. Using the information from the CPU table we wanted to be able to choose the kernel to boot. Using the DHCP table

On Jun 4, 2014 7:45 PM, "Ady" <ady-sf at hotmail.com> wrote: > > The following are new Lua c32 modules in 6.03-pre*: > > cmenu.c32: > cpu.c32: > dhcp.c32: > dmi.c32: > lfs.c32: > pci.c32: > syslinux.c32: > vesa.c32: > > I am wondering whether the following modules, which are _not_ new and > are also included in 6.03-pre*, have _any_

Gene, I found a document from IBM that explains why it didn't like Vendor-Class-Identifier option I was using "PXEClient" was causing EFI boot rooms to dummy spit, that's very useful, that combined with RTFMing the PXE specs 3.0-3.2 might solve my problem if I keep at it. http://www-01.ibm.com/support/docview.wss?uid=swg21247032 Even the PXELinux docs suggest encapsulating

> Date: Thu, 25 Dec 2014 07:07:52 +0000 > From: Luke Ledgerd <luke.ledgerd at niteco.se> > To: "syslinux at zytor.com" <syslinux at zytor.com> > Subject: [syslinux] Chain-loading from WDS to PXELinux on a different > tftp server > Message-ID: <17ba7ad419d54b6cab685c2cedc3de95 at NI-MAILEX.niteco.se> > Content-Type: text/plain;