[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.

Many thanks

CC

-----Original Message-----
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
sector 
>> (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,
move 
> along".
> 
> 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
unfortunate 
> "Missing operating system" error message.
> 
> It might be worth a try to overwrite some of the code in the MBR of
your 
> 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
computer, 
> entirely starting the boot sequence over from the beginning.  If INT
18 
> doesn't work, to advance to the next boot device, then maybe INT 19,
to 
> 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 
http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED
/0/specsbbs101.pdf
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!

	-hpa

_______________________________________________
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.





More information about the Syslinux mailing list