Syslinux - Aug 2005 - Can't boot Syslinux from HD directly. Can indirectly?

I've installed Syslinux on a somewhat old system.  The motherboard is
based on an Intel 440GX chipset (specifically it's the Supermicro
P6DGE if that means anything.)  The harddrive has been split up into
partitions of one hidden FAT16 (marked as active) to which syslinux is
installed (hda1), one normal FAT32 which has windows and dos (hda2.) 
It also has an extended partition containing an EXT2 and linux swap
partition, however, it didn't originally have these when I first saw
the problem so I know they aren't the issue.

The issue is that for some reason it won't boot the harddrive
directly.  It just freezes every time.  It shows the word SYSLINUX,
the version (3.09) and date (2005-06-17) but stops there.  Never
clears the screen or any of that either.  I have installed it in safe
"slow" mode, but, what's more importantly, this same setup worked
perfectly fine for several weeks on the previous board I had in that
system, an Asus KN-97-X (Intel 440FX.)  This leads me to believe it's
something weird to do with the bios.

Currently I'm having to boot my rescue disc using isolinux and load
chain.c32 to manually boot that partition for it to work.  When I do
this, it boots without a problem.  I'd say definitely bios, however,
before this latest time I've installed syslinux on there, it was set
to boot partition "0" (aka the MBR!)  As far as I can tell, it
doesn't
cross the 1024 boundary (I haven't the vaguest idea how to verify
this, but, the FAT16 partition is the first 510 or so MB of a 60GB
drive, so it's hard to imagine it would do that.)

Any idea what's going on?  Is it somehow still past the 1024 boundary?
 Any way to verify short of knowing how to add up those numbers on the
drive (which is such a pain to get to right now I'm not sure it's
worth the trouble.)

Nazo wrote:
> I've installed Syslinux on a somewhat old system.  The motherboard is
> based on an Intel 440GX chipset (specifically it's the Supermicro
> P6DGE if that means anything.)  The harddrive has been split up into
> partitions of one hidden FAT16 (marked as active) to which syslinux is
> installed (hda1), one normal FAT32 which has windows and dos (hda2.) 
> It also has an extended partition containing an EXT2 and linux swap
> partition, however, it didn't originally have these when I first saw
> the problem so I know they aren't the issue.
> 
> The issue is that for some reason it won't boot the harddrive
> directly.  It just freezes every time.  It shows the word SYSLINUX,
> the version (3.09) and date (2005-06-17) but stops there.  Never
> clears the screen or any of that either.  I have installed it in safe
> "slow" mode, but, what's more importantly, this same setup
worked
> perfectly fine for several weeks on the previous board I had in that
> system, an Asus KN-97-X (Intel 440FX.)  This leads me to believe it's
> something weird to do with the bios.
> 
> Currently I'm having to boot my rescue disc using isolinux and load
> chain.c32 to manually boot that partition for it to work.  When I do
> this, it boots without a problem.  I'd say definitely bios, however,
> before this latest time I've installed syslinux on there, it was set
> to boot partition "0" (aka the MBR!)  As far as I can tell, it
doesn't
> cross the 1024 boundary (I haven't the vaguest idea how to verify
> this, but, the FAT16 partition is the first 510 or so MB of a 60GB
> drive, so it's hard to imagine it would do that.)
> 
> Any idea what's going on?  Is it somehow still past the 1024 boundary?
>  Any way to verify short of knowing how to add up those numbers on the
> drive (which is such a pain to get to right now I'm not sure it's
> worth the trouble.)
> 
Do you know if this problem goes away with an older version of syslinux? 
  There seems to be some issues with newer syslinuxes on some old 
hardware, which is still unresolved.

	-hpa

>One possibility, which I don''t exactly cherish the thought of, is
that
>whenever EBIOS read fails we always need to try a CBIOS read.  Part of
>why I don''t cherish the thought of that is that it would require 
>checking the cylinder number in the latter code, and all of this adds 
>up very quickly to a lot of code which has to go into the boot sector.
Isn''t it too soon to worry about that?  It doesn''t seem the
problem is absolutely identified yet.
>I''ll have to think about another way to get more visibility into 
>whatever is going wrong.
Exactly!  Throw code at it with abandon for now.  Special versions that
won''t even proceed to boot, but take their path with a gun and camera
would be fine!  Once you illuminate it clearly, THEN you can beging to worry
about the boot sector.  Just my 2 cents worth, earned by MUCH wasted time and
effort over the years.


Paul Rogers  (paul.rogers@juno.com)
http://www.xprt.net/~pgrogers/
Rogers'' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)