[syslinux] PXELINUX based kickstart query (probably OT)
Coe, Colin C. (Unix Engineer)
Colin.Coe at woodside.com.au
Tue Oct 17 16:35:06 PDT 2006
Wow! You guys are the greatest!
I used a hex editor and changed the first two bytes and a network boot
was forced *and* the partition info was still there.
From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On
Behalf Of H. Peter Anvin
Sent: Wednesday, 18 October 2006 5:03 AM
To: Josh Lehan
Cc: Geert Stappers; syslinux at zytor.com
Subject: Re: [syslinux] PXELINUX based kickstart query (probably OT)
Josh Lehan wrote:
> H. Peter Anvin wrote:
>> Can't be done. Unfortunately the BIOS considers loading a boot
>> (from floppy or from hard disk) to be "terminal" in the sense that it
>> has now booted, and there is no going back.
>> This is one of the most unfortunate aspects of the BIOS.
> Hmm, would calling INT 18 work?
> INT 18 seems to have the meaning of "there's nothing to boot here,
> In the MBR, an INT 18 will return control to the BIOS.
> A good BIOS hopefully will advance to the next device in the boot
> sequence. A bad BIOS will probably just hang then, with the
> "Missing operating system" error message.
> It might be worth a try to overwrite some of the code in the MBR of
> hard drive, to force a call to INT 18, if you don't want to boot from
> that drive.
> This differs from INT 19, which should do a full reset of the
> entirely starting the boot sequence over from the beginning. If INT
> doesn't work, to advance to the next boot device, then maybe INT 19,
> go back to the beginning, might be another way to solve the problem.
When I've tried it, INT 18h generally results in printing a message and
stopping. The Compaq-Phoenix-Intel BIOS Boot Specification
does that that INT 18h is supposed to invoke the next boot device, and
it might be worth trying (it might help the OPs problem.)
That is, replace the first two bytes in the MBR with CD 18 hex. It will
either work, or it won't.
I hadn't looked at the BBS for a while, and I clearly should have,
because it actually provides a much richer API than I remember. In
particular, if the functions in Appendix B are widely implemented, then
there might be a lot of things that are possible that I didn't quite
realize. Silly me, but this is paydirt!
SYSLINUX mailing list
Submissions to SYSLINUX at zytor.com
Unsubscribe or set options at:
Please do not send private replies to mailing list traffic.
More information about the Syslinux