Randy and Shao, In case you missed it there was a recent commit to syslinux, which should make localboot -1 do a int 18h. So with a newly compiled gpxelinux from the current git you should be able to boot the local disk with "localboot -1" since an int 18h always worked for me.
Shao: not sure what the version exactly was (i think 3.83) but never had it working on all our 6000 workstations. Always were some machines that didn't like "localboot", so i switched to chain.c32 which worked on all. But i will try that localboot -1 with a recent version asap. -------------------------- Commit-ID: e19346b4cadd51fa16975564d0b459a4cd7e0571 pxelinux: allow "localboot -1" to do INT 18h, just like !pxelinux Allow "localboot -1" to invoke INT 18h, as it does on other derivatives. Perhaps that can help track down systems on which the normal return path just isn't working. Regards, Rene >>> On 3-3-2010 at 20:02, in message <[email protected]>, Shao Miller <[email protected]> wrote: > Randy McAnally wrote: >> >> Thank you so much, this is the kind of news I needed! >> >> ---------- Original Message ----------- >> From: "Arends, R.R." <[email protected]> >> To: "Randy McAnally" <[email protected]> >> Cc: <[email protected]> >> Sent: Wed, 03 Mar 2010 10:10:56 +0100 >> Subject: Re: [gPXE] localboot 0 hang on some machines >> >> > I had troubles with localboot 0 from a gpxelinux.0 menu on some >> > machines aswel. Chain.c32 does work for me to boot from harddisk tho... >> > > The news does not include version information, though. > > gpxelinux.0 is: > gPXE's undionly.kkpxe build with: > embedded script to boot embedded PXELINUX > embedded PXELINUX (pxelinux.0) > > The Syslinux Project delivers gpxelinux.0 and thus includes a stable > gPXE state that H. Peter Anvin deems acceptable for this use case. > Historically, he's noted some issues and features required for best > results. Some of these were incorporated into gPXE 1.0.0 and Syslinux 3.85. > > Unfortunately, some news of LOCALBOOT versus CHAIN.C32 results came a > little late for the Syslinux 3.85 release, so it would be good to figure > out the solution(s), if possible, for the computer types involved, I > think. To be absolutely sure that there is actually a challenge to be > overcome, the version(s) involved could benefit. > > I am not sure that failing on, let's say, gpxelinux.0 from Syslinux > 3.83, then failing on the gpxelinux.0 from Syslinux 4.00-preX can give > confidence that Syslinux 3.85 is broken. My impression is that 3.85 and > 4.XX are separate development branches, though they can and do share > some code. This impression could be mistaken. > > - Shao Miller _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
