Hello syslinux mailing list, I've been working on a kind of system administration tool ( http://twyna.sourceforge.net/) with a colleague of mine for our Computer Science Bachelor degree internship. I hope I'm saying that right :) We use gPXELinux to boot over a web service and it's all working marvellously, except for the localboot bug. Until now we've used chain.c32 to solve this problem, however we're running into some problems with some hardware, especially in situations where Windows is (also) installed on a machine. Running chain.c32 with hd0 as parameter just crashes the machine for some reason. My question is the following: will the localboot bug get fixed at some point in the near future, or isn't anyone interested in it? And if the latter, what could be causing our problems and how could we fix or circumvent them? I've been thinking that we could PXE boot into gPXE and use that to boot PXELinux, but that just seems silly. Your feedback is very much appreciated, With kind regards, Tim
Good day Tim, As a matter of fact, gPXE -> PXELINUX -> chain.c32 -> HDD "0" isn't silly at all. I think I've given a sample setup in this mailing list before; maybe you could search for them by author or something. I can't speak towards fixing this bug, sorry. - Shao Miller -----Original Message----- From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On Behalf Of Tim Franssen Sent: Tuesday, May 12, 2009 08:38 To: syslinux at zytor.com Subject: [syslinux] Chain loading hard disk with gPXELinux Hello syslinux mailing list, I've been working on a kind of system administration tool ( http://twyna.sourceforge.net/) with a colleague of mine for our Computer Science Bachelor degree internship. I hope I'm saying that right :) We use gPXELinux to boot over a web service and it's all working marvellously, except for the localboot bug. Until now we've used chain.c32 to solve this problem, however we're running into some problems with some hardware, especially in situations where Windows is (also) installed on a machine. Running chain.c32 with hd0 as parameter just crashes the machine for some reason. My question is the following: will the localboot bug get fixed at some point in the near future, or isn't anyone interested in it? And if the latter, what could be causing our problems and how could we fix or circumvent them? I've been thinking that we could PXE boot into gPXE and use that to boot PXELinux, but that just seems silly. Your feedback is very much appreciated, With kind regards, Tim _______________________________________________ Syslinux mailing list Submissions to Syslinux at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux Please do not send private replies to mailing list traffic.
Tim Franssen wrote:> > We use gPXELinux to boot over a web service and it's all working > marvellously, except for the localboot bug. Until now we've used chain.c32 > to solve this problem, however we're running into some problems with some > hardware, especially in situations where Windows is (also) installed on a > machine. Running chain.c32 with hd0 as parameter just crashes the machine > for some reason. > > My question is the following: will the localboot bug get fixed at some point > in the near future, or isn't anyone interested in it? And if the latter, > what could be causing our problems and how could we fix or circumvent them? >I don't know of "the" localboot bug. There is "the" chainloading bug (gPXELINUX can't load another NBP), but that doesn't affect localboot. There were problems with localboot a long time ago, but they should have long since been resolved. What version are you running? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
On Wed, May 13, 2009 at 2:25 AM, H. Peter Anvin <hpa at zytor.com> wrote:> If you're using raw gPXE, things are a bit different. >I'm not, but gPXELINUX doesn't seem to have its own version number..? gPXELINUX reports the following version numbers in the two versions I've tested (see below): - gPXE version numbers 0.9.5 and 0.9.7 - PXELINUX versions 3.73 and 3.80 Here are the boot procedures that I get with both versions of the software: *gPXELINUX 0.9.5/3.73* [...]> gPXE 0.9.5 -- Open Source Boot Firmware -- http://etherboot.org > Features: FTP HTTP HTTPS DNS TFTP iSCSI AoE bzImage COMBOOT ELF Multiboot > PXE PXEXT > > net0: 08:00:27:e3:03:c3 on UNDI (open) > [Link:up, TX:0 TXE:0 RX:0 RXE:0] > Waiting for link-up on net0... ok > DHCP (net0 08:00:27:e3:03:c3).. ok > net0: 192.168.1.19/255.255.255.0 gw 192.168.1.1 > > PXELINUX 3.73 2009-01-25 Copyright (C) 1994-2008 H. Peter Anvin > UNDI data segment at: 0009B1A0 > UNDI data segment size: 2E58 > UNDI code segment at: 0009AA30 > UNDI code segment size: 0764 > PXE entry point found (we hope) at 9AA3:036C > Getting cached packet 01 > Getting cached packet 02 > Getting cached packet 03 > My IP address seems to be C0A80113 192.168.1.19 > ip=192.168.1.19:192.168.1.2:192.168.1.1:255.255.255.0 > TFTP prefix: / > Trying to load: config > Booting from local disk... > No more network devices > > Press Ctrl-B for the gPXE command line... >*gPXELINUX 0.9.7/3.80* [...]> gPXE 0.9.7 -- Open Source Boot Firmware -- http://etherboot.org > Features: FTP HTTP HTTPS DNS TFTP AoE iSCSI bzImage COMBOOT ELF Multiboot > PXE PXEXT > > DHCP (net0 08:00:27:30:a3:de).... ok > > PXELINUX 3.80 2009-05-04 Copyright (C) 1994-2009 H. Peter Anvin et al > !PXE entry point found (we hope) at 9A9C:03B6 via plan A > UNDI code segment at 9A9C len 0804 > UNDI data segment at 9B1D len 2E30 > Setting cached packet 01 02 03 > My IP address seems to be 0A000032 10.0.0.50 > ip=10.0.0.50:10.0.0.1:10.0.0.1:255.255.255.0 > TFTP prefix: / > Trying to load: config > Booting from local disk... > > Press Ctrl-B for the gPXE command line... >In both cases the last line disappears after about a second and after that nothing else happens. I know the subnets and the MAC addresses differ but both runs are done on the same VirtualBox "hardware". The first boots over our test server, the second over a VM with the same software. TFTP /config file: default local> label local > localboot 0 >