Syslinux - Mar 2002 - ISOLINUX 1.67 failure with no HDD; OK with HDD

Award BIOS 6.00PG, CD-ROM configured as first boot device
CD-ROM on IDE-1, master
variable: hard disk drive on IDE-0, master
no other IDE devs, no SCSI

if i boot with the HDD installed, ISOLINUX boots the CD OK with DL=9F.
if i remove the HDD, ISOLINUX fails to load the spec packet and can't
``wing it'' with DL=9F. (no maybe_msg's appear, either)

otherwise, this (and the venerable SYSLINUX) is (are) great stuff.
thanks, H. Peter. A.

buckh at pobox.com wrote:
> Award BIOS 6.00PG, CD-ROM configured as first boot device
> CD-ROM on IDE-1, master
> variable: hard disk drive on IDE-0, master
> no other IDE devs, no SCSI
> 
> if i boot with the HDD installed, ISOLINUX boots the CD OK with DL=9F.
> if i remove the HDD, ISOLINUX fails to load the spec packet and can't
> ``wing it'' with DL=9F. (no maybe_msg's appear, either)
> 
> otherwise, this (and the venerable SYSLINUX) is (are) great stuff.
> thanks, H. Peter. A.
> 

BIOS bug.  Report to your hardware vendor.  In general, I have heard *so*
many Award BIOS problems that I'd stay away from it at any cost.

	-hpa

[Cc: the list since I'm sick of answering these questions privately...]

Henrik Brix Andersen wrote:
> 
> Just a comment, no harm intended...
> ...but the most common answer to bug reports on this list seems to be
> "BIOS bug - Complain to your hardware vendor"?
> Is it not possible to avoid these "bugs" in software?
> 

Sometimes.  Freqently not.  Especially when it comes to the ISO stuff.  I
spend a *huge* amount of time working around as many bugs as I can, and
believe me, there are *lots* of workarounds in there.

In the particular case of SYSLINUX, the floppy program, there physically
isn't space enough in the boot sector for all the workarounds I know are
needed on some machines.

The big problem with booting ISOs -- both floppy emulation (SYSLINUX) and
native mode (ISOLINUX) -- the biggest problem is that BIOS vendor
genuinely seems to not give a shit.  I have actually reported bugs
directly to BIOS vendors, through formal channels in an official capacity,
with explicit test cases and gotten back answers that are functionally "we
don't think that's important enough to spend time on."

The biggest problem with working around bugs is that it's virtually
impossible to do without actually having a system physically in front of
me.  I have, occationally, worked with users remotely, but it is (a)
extemely time-consuming, both for me and for the user, (b) frequently
frustrating since too many users consider it to be a "reply at their
leisure" type of deal which means I keep having to switch in and out of
the projects.

> Personally I've tried syslinux on several PCs, which normally
wouldn't
> have any problems, which failed with a "BIOS Bug".

"Normally wouldn't have any problems?"  For what definition of
"normal"?

	-hpa