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 <4B8EB228.3000006 at
YRDSB.Edu.On.Ca>, Shao
Miller <Shao.Miller at yrdsb.edu.on.ca> wrote:> Randy McAnally wrote:
>>
>> Thank you so much, this is the kind of news I needed!
>>
>> ---------- Original Message -----------
>> From: "Arends, R.R." <r.r.arends at hro.nl>
>> To: "Randy McAnally" <rsm at fast-serv.com>
>> Cc: <gpxe at etherboot.org>
>> 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