On Wed, Aug 7, 2013 at 7:26 PM, Gene Cumm <gene.cumm at gmail.com> wrote:> <snip> > > After my experiences with writing/testing pxechn.c32, I'm not > surprised that this happens. What version(s) have you used? > > One of the goals of lpxelinux.0 is to replace gpxelinux.0 for HTTP/FTP > fetch capability. This is available in versions 5.10+ and 6.00+ (BIOS > only in 6.00+) however it still needs more testing/debugging as there > are a few known issues (listed in bugzilla.syslinux.org ). > >I first tried this setup with version 4.02 (then with a pxehain.com from 4.04 [?] pulled in to get around known bug, which probably was a dumb idea) and then more recently with syslinux 4.06 on both systems. I'll happily try newer versions if they might work -- and give lpxelinux.0 a shot if that'll work w/ my (vmware) systems too. Hans
I've spent a lot more time with this today, trying to get this working with 4.07, 5.01, and 5.10 ... no luck, but I did have a few follow-up questions. (1) Should it be possible to use the newer (e.g. 5.10) version of syslinux and use http:// URLs for both the initial vmlinuz image and also the initrd? -- As I was doing before with gpxelinux.0? A naive attempt to use lpxelinux.0 on our cobbler box w/o any chainloading is failing like this: Loading http://<cobbler-ip>/cobbler/images/CentOS-5.9-i386/vmlinuz ... netconn_write error -5 L Boot failed: press a key to retry, or wait for reset... ....... Earlier attempts to chain load from lpxelinux.0 -> tftp://server2/lpxelinux.0 also failed, I suspect for a similar error. (2) The new gpxelinux.0 in 5.10 seems to not work at all (with our VMWare VMs, anyway). That may be on the known-bugs list. (3) I assume I should be using pxechn.c32 instead of pxechain.com now always? I updated the pxelinux.cfg/default on my first-stop server to look like this: label cobbler COM32 pxechn.c32 append tftp://172.20.30.10/lpxelinux.0 This specific example (using lpxelinux.0) refuses to load the http-url kernel from my cobbler box, but if I use non-URL paths (i.e. TFTP) for kernel and initrd it works just fine. Any further help appreciated! :) All I need to do here is have support for multiple pxe servers (chain) and support loading kernel and initrd over http since tftp is unusably slow for these larger files in certain networks. I'm happy to try whatever versions or combinations of pxelinux.0/lpxelinux.0/gpxelinux.0/etc. get me there :) Thanks, Hans On Thu, Aug 8, 2013 at 9:46 AM, Hans Lellelid <hans at velum.net> wrote:> On Wed, Aug 7, 2013 at 7:26 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > >> <snip> >> >> After my experiences with writing/testing pxechn.c32, I'm not >> surprised that this happens. What version(s) have you used? >> >> One of the goals of lpxelinux.0 is to replace gpxelinux.0 for HTTP/FTP >> fetch capability. This is available in versions 5.10+ and 6.00+ (BIOS >> only in 6.00+) however it still needs more testing/debugging as there >> are a few known issues (listed in bugzilla.syslinux.org ). >> >> > I first tried this setup with version 4.02 (then with a pxehain.com from > 4.04 [?] pulled in to get around known bug, which probably was a dumb idea) > and then more recently with syslinux 4.06 on both systems. I'll happily > try newer versions if they might work -- and give lpxelinux.0 a shot if > that'll work w/ my (vmware) systems too. > > Hans >
On Aug 8, 2013 1:08 PM, "Hans Lellelid" <hans at velum.net> wrote:> > I've spent a lot more time with this today, trying to get this working with > 4.07, 5.01, and 5.10 ... no luck, but I did have a few follow-up questions.Thanks for testing.> (1) Should it be possible to use the newer (e.g. 5.10) version of syslinux > and use http:// URLs for both the initial vmlinuz image and also the > initrd? -- As I was doing before with gpxelinux.0? A naive attempt to use > lpxelinux.0 on our cobbler box w/o any chainloading is failing like this: > > Loading http://<cobbler-ip>/cobbler/images/CentOS-5.9-i386/vmlinuz ... > netconn_write error -5 > L > Boot failed: press a key to retry, or wait for reset... > .......This is what I was talking about. Some systems see errors like this but you weren't naive. Any chance you could try 5.11-pre9? I'd guess it's probably not different but it may be worth testing. I've been working on bug #19 ( http://bugzilla.syslinux.org/show_bug.cgi?id=19 ).> Earlier attempts to chain load from lpxelinux.0 -> > tftp://server2/lpxelinux.0 also failed, I suspect for a similar error. > > (2) The new gpxelinux.0 in 5.10 seems to not work at all (with our VMWare > VMs, anyway). That may be on the known-bugs list.VMware platforms are my main test bed. I don't recall gpxelinux.0 issues but can test.> (3) I assume I should be using pxechn.c32 instead of pxechain.com now > always?In 5.00+, yes.> I updated the pxelinux.cfg/default on my first-stop server to look like > this: > > label cobbler > COM32 pxechn.c32 > append tftp://172.20.30.10/lpxelinux.0 > > This specific example (using lpxelinux.0) refuses to load the http-url > kernel from my cobbler box, but if I use non-URL paths (i.e. TFTP) for > kernel and initrd it works just fine.That's perfect minus the bug.> Any further help appreciated! :) > > All I need to do here is have support for multiple pxe servers (chain) and > support loading kernel and initrd over http since tftp is unusably slow for > these larger files in certain networks. I'm happy to try whatever versions > or combinations of pxelinux.0/lpxelinux.0/gpxelinux.0/etc. get me there :) > > Thanks, > Hans-- -Gene A: Because it messes up the order in which people normally read text, especially the archives of mailing lists. Q: Why is Top-posting such a bad thing?
On 08/08/2013 10:05 AM, Hans Lellelid wrote:> > label cobbler > COM32 pxechn.c32 > append tftp://172.20.30.10/lpxelinux.0 > > This specific example (using lpxelinux.0) refuses to load the http-url > kernel from my cobbler box, but if I use non-URL paths (i.e. TFTP) for > kernel and initrd it works just fine. >Does that include a URL-path for TFTP? Any useful messages on the screen? What do you mean with "refuses"? Any chance you could make a packet trace (e.g. using wireshark)? -hpa