Syslinux - Mar 2017 - "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

Hi,
> In theory, the geometry assumed in the MBR should 
> match the one assumed by the BIOS.
To be exacting: The geometry assuming part of the MBR is the partition
table, not the executable MBR code.

Of course it would be nice if C/H/S was not such a brain damaged concept
which has two semi-secret parameters. The geometry parameters are not
recorded anywhere in the MBR. One can sometimes deduce them from comparing
the LBA number with the CHS triple of a partition table address. But at
latest if this guessing yields more than one valid result, a software has
to choose or just make up two parameters of its own.
Therefore everybody tries to use LBA adressing whenever possible.

The partition table is not interpreted by isohdpfx.bin.
This MBR code rather tries to do the right thing and asks the BIOS how
it would translate LBA to C/H/S.
But then - to my current theory - it confuses both and thus computes
wrong numbers for head and sector in the correct cylinder.

> The isohybrid tool (or the 
> equivalent code in xorriso) is using one CHS geometry, and it ends in 
> its MBR (h:64;s:32)
It uses 64 heads/cyl and 32 sectors/head by default.
It allows the user to choose other values by options -h and -s.
If the effective cylinder size turns out to be less than 1/1024 of the
image size, the cylinder count gets set to 1024.

xorriso first tries to find larger cylinder sizes with 32 or 63
sectors/head. I.e. at most 255 heads/cylinder and 63 sectors/head.
Only if this does not suffice, it sets the cylinder count to 1023.

But whatever the generating software does, the interpreting software
is free to choose other parameters. That's why C/H/S is stupid.

> While the image is less than 1GB, the physical device is close to 4GB, 
> so the BIOS is probably assuming a different geometry.
It seems to assume a cylinder size of 63 * 32 * 512 = 1032192 bytes.
1024 of those cylinders are 1008 MiB. I have no idea from where it
might get this info. Possibly it just makes it up.

> BTW, many distros are still not setting the Head and Sector parameters 
> correctly for isohybrid, so they still use "64/32" while
distributing
> images of several GBs each.
That's what utils/isohybrid.c does.

After 8,422,686,720 bytes, even the range of 255/63 is exhausted.

> I guess a word from hpa or mjg could help
Yeah. I wonder what hpa thinks about my suspicion.

But Martin should be qualified too, to judge my findings and to produce
a corrected isohdpfx.bin for testing, if he thinks that i am right.

---------------------------------------------------------------------

We still have to find out why David on the real old BIOS sees all zeros
in the read block. Nevertheless there is hope for success on that BIOS
only if the C/H/S addressing code of the MBR is free of bugs.


Have a nice day :)

Thomas

On Wed, Mar 22, 2017 at 03:18:44PM +0100, Thomas Schmitt via Syslinux
wrote:
> Hi,
> 
> > In theory, the geometry assumed in the MBR should 
> > match the one assumed by the BIOS.
> 
> To be exacting: The geometry assuming part of the MBR is the partition
> table, not the executable MBR code.
> 
> Of course it would be nice if C/H/S was not such a brain damaged concept
> which has two semi-secret parameters. The geometry parameters are not
> recorded anywhere in the MBR. One can sometimes deduce them from comparing
> the LBA number with the CHS triple of a partition table address. But at
> latest if this guessing yields more than one valid result, a software has
> to choose or just make up two parameters of its own.
> Therefore everybody tries to use LBA adressing whenever possible.
> 
> The partition table is not interpreted by isohdpfx.bin.
> This MBR code rather tries to do the right thing and asks the BIOS how
> it would translate LBA to C/H/S.
> But then - to my current theory - it confuses both and thus computes
> wrong numbers for head and sector in the correct cylinder.
> 
> 
> > The isohybrid tool (or the 
> > equivalent code in xorriso) is using one CHS geometry, and it ends in 
> > its MBR (h:64;s:32)
> 
> It uses 64 heads/cyl and 32 sectors/head by default.
> It allows the user to choose other values by options -h and -s.
> If the effective cylinder size turns out to be less than 1/1024 of the
> image size, the cylinder count gets set to 1024.
> 
> xorriso first tries to find larger cylinder sizes with 32 or 63
> sectors/head. I.e. at most 255 heads/cylinder and 63 sectors/head.
> Only if this does not suffice, it sets the cylinder count to 1023.
> 
> But whatever the generating software does, the interpreting software
> is free to choose other parameters. That's why C/H/S is stupid.
> 
> 
> > While the image is less than 1GB, the physical device is close to 4GB,
> > so the BIOS is probably assuming a different geometry.
> 
> It seems to assume a cylinder size of 63 * 32 * 512 = 1032192 bytes.
> 1024 of those cylinders are 1008 MiB. I have no idea from where it
> might get this info. Possibly it just makes it up.
> 
> 
> > BTW, many distros are still not setting the Head and Sector parameters
> > correctly for isohybrid, so they still use "64/32" while
distributing
> > images of several GBs each.
> 
> That's what utils/isohybrid.c does.
> 
> After 8,422,686,720 bytes, even the range of 255/63 is exhausted.
> 
> 
> > I guess a word from hpa or mjg could help
> 
> Yeah. I wonder what hpa thinks about my suspicion.
He has an explicit carbon copy, cc, of this mailinglist post.

> But Martin should be qualified too, to judge my findings and to produce
> a corrected isohdpfx.bin for testing, if he thinks that i am right.
Martin posted elsewhere in this thread "Thomas, you found the bug"
and provided a patch.

> ---------------------------------------------------------------------
> 
> We still have to find out why David on the real old BIOS sees all zeros
> in the read block. Nevertheless there is hope for success on that BIOS
> only if the C/H/S addressing code of the MBR is free of bugs.
Contact David off-list, he did unsubscribe.

> 
> Have a nice day :)
> 
> Thomas
> 
Groeten
Geert Stappers
-- 
Leven en laten leven

Hi,

Geert Stappers wrote:
> Contact David off-list, he did unsubscribe.
Can you tell when he unsubscribed (i.e. which of the messages he got
as last one) ?

> Martin posted elsewhere in this thread "Thomas, you found the
bug"
> and provided a patch.
Open question is whether the fix helps with David's BIOS.
The newest answer from Martin indicates that a failure to read should
have caused a different error message than reported by David.
But successfully reading a wrong block address should not have yielded
all zeros.

@Martin:
Can you provide a binary MBR with the bug fix and diagnostic prints ?
If we cannot get testing from David then i would be interested to keep
such an MBR for the next occasion.


Have a nice day :)

Thomas