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

Hi,

Ady wrote:
> If a specific BIOS' CHS/LBA translations cannot cope with the above, it
> is no surprise that we get some mess, somewhere.
Currently my suspicion is that the isohdpfx.S code simply mishandles
the two conversion factors which it correctly got from BIOS call
INT 13H AH 8.

>  Boot  System ID   :   First    :    Last    : Relative : Number of:
>  Flag              :Cyl Head Sec:Cyl Head Sec:  Sector  :  Sectors :
>  80h 00h           :   0   0  1 : 646  63 32 :         0:   1325056:
>  00h EFh ??        :1023 254 63 :1023 254 63 :      8524:       608:
The last sector 1325055 and its C/H/S (646, 63, 32) address tell that the
partition table was made under the assumption H/C= 64 and S/H= 32.
That's what hpa prescribed to me for smaller sized isohybrids.

The EFI partition bears the CHS value which says that it is not valid.
See:
  https://en.wikipedia.org/wiki/Master_boot_record#Partition_table_entries
which says:
  "When a CHS address is too large to fit into these fields, the tuple
   (1023, 254, 63) is typically used today,"

Since the only intended audience of the partition is UEFI firmware,
i'd say it is safe to assume that it can address by LBA.


I will have to examine whether the invalidated CHS value is an old bug in
libisofs-1.3.6 (and maybe fixed meanwhile) or if there is a reason why
the EFI partition got no valid CHS addresses.


Have a nice day :)

Thomas

> Hi,
> 
> Ady wrote:
> > If a specific BIOS' CHS/LBA translations cannot cope with the
above, it
> > is no surprise that we get some mess, somewhere.
> 
> Currently my suspicion is that the isohdpfx.S code simply mishandles
> the two conversion factors which it correctly got from BIOS call
> INT 13H AH 8.
> 
> 
> >  Boot  System ID   :   First    :    Last    : Relative : Number of:
> >  Flag              :Cyl Head Sec:Cyl Head Sec:  Sector  :  Sectors :
> >  80h 00h           :   0   0  1 : 646  63 32 :         0:   1325056:
> >  00h EFh ??        :1023 254 63 :1023 254 63 :      8524:       608:
> 
> The last sector 1325055 and its C/H/S (646, 63, 32) address tell that the
> partition table was made under the assumption H/C= 64 and S/H= 32.
> That's what hpa prescribed to me for smaller sized isohybrids.
> 
 
But that's my point. In theory, the geometry assumed in the MBR should 
match the one assumed by the BIOS. The isohybrid tool (or the 
equivalent code in xorriso) is using one CHS geometry, and it ends in 
its MBR (h:64;s:32).

While the image is less than 1GB, the physical device is close to 4GB, 
so the BIOS is probably assuming a different geometry. We could/should 
had had the result from the "diag/*.img" images already, as it should 
had been the first test to report.

Nowadays, most BIOS would use LBA in most cases, but that's not always 
the case, and we end up with this type of problems. Most distro 
maintainers ignore these issues, and David's case is just one 
additional example.

For an isohybrid image of ~700MB, a USB device of less than 1GB should 
be preferred.

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.

I am not discarding a bug in isohybrid either. I guess a word from hpa 
or mjg could help, but I wouldn't count on that.

Regards,
Ady

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

Hi,

Ady wrote:
> >  Boot  System ID   :   First    :    Last    : Relative : Number of:
> >  Flag              :Cyl Head Sec:Cyl Head Sec:  Sector  :  Sectors :
> >  80h 00h           :   0   0  1 : 646  63 32 :         0:   1325056:
> >  00h EFh ??        :1023 254 63 :1023 254 63 :      8524:       608:
i wrote:
> I will have to examine whether the invalidated CHS value is an old bug in
> libisofs-1.3.6 (and maybe fixed meanwhile) or if there is a reason why
> the EFI partition got no valid CHS addresses.
It's not a bug but a feature of the mjg layout.

In the part of utils/isohybrid.c which writes MBR partition slot 2:
  http://git.zytor.com/syslinux/syslinux.git/tree/utils/isohybrid.c#n693
one can see the values hardcoded by
            mbr[1] = 0xfe;
            mbr[2] = 0xff;
            mbr[3] = 0xff;
and
            mbr[5] = 0xfe;
            mbr[6] = 0xff;
            mbr[7] = 0xff;

UEFI 2.4 prescribes for the Protective MBR of GPT that it should bear
C/H/S start address (0,0,2). So one cannot deduce from EFI specs that
C/H/S should be marked invalid in any case.

On the other hand UEFI 2.4 states that C/H/S shall be ignored and LBA
be used instead.
(Further it states that the byte pattern for oversized partitions in
 the Protective MBR of GPT shall be 0xff, 0xff, 0xff. Now i riddle
 whether mjg found a UEFI that wants to see 0xfe, 0xff, 0xff.)

For now libisofs will stay with the hardcoded C/H/S values of isohybrid.c.
If they get changed, then best in both softwares simultaneously.


Have a nice day :)

Thomas