Syslinux - Jan 2014 - After USB boot problems on Gigabyte GA-M55Plus-S3G

On 01/21/2014 12:22 AM, Thomas Schmitt wrote:
> 
>> If we take the ENDing CHS values as valid:
>>  982 / 254 / 63 
>> and we calculate the corresponding LBA:
>>   ( ( 982 + 1 )
>>  x ( 254 + 1 )
>>  x ( 63 ) )
>>  - 1
>>    ___________
>>    15'791'894 
> 
> Is this calculation generally valid ? It seems to assume that
> the end is aligned to a full cylinder. (The start is not.)
It isn't.  To calculate the LBA from an arbitrary CHS address when the
geometry is C':H':S':

LBA = (C * H' * S') + (H * S') + (S - 1)

or equivalently

LBA = ((C * H') + H) * S' + S - 1
> It is clear that S/H must be 63 and H/C must be 255, because we
> see the maximum possible values here. (H/C could be 256. But
> that is outruled by Wikipedia about MBR.)
> 
> Nevertheless, this does not match the end LBA calculated
> from start LBA and number of blocks.
> 
> Do i miss an essential point here ?
I think the essential point is that the CHS geometry offered on the
preformatted stick seems to be "impossible".  Most likely the
manufacturer simply did not care.

Consider this:

8 GB Corsair:
Partition type  0x0b  (Wikipedia: FAT32, CHS or LBA)
Start LBA       63 = CHS    0   1   1
End   LBA 15794175 = CHS  982 254  63

If LBA 63 = CHS 0/1/1 then we know S'=62, but that is completely
inconsistent with the ending sector being 63.  In other words, the CHS
information in this partition table is complete garbage.
>> If there is nothing to loose (some special feature in the USB drive, 
>> data, etc.), probably it would be best to create a new partition 
>> table, a new partition and then format them again.
> 
> Seems advisable, given the numerical madness.
> 
> This is were i see a gap in SYSLINUX wiki. The world could need
> prescriptions for a non-weird partitioning and a LBA driven
> filesystem.
Fortunately geometry is becoming a fading problem.  We're dealing with
an old board and BIOS here.
> Biggest riddle for me, though, is how to achieve this with Linux
> tools and MS-Windows tools. (I know /sbin/fdisk -lu. Everything
> else i do by byte manipulations in images. Plumber style.)
	-hpa

I am most interested in seeing: 1) hard-disk-images, 2) hdd and 3) ssd that
are boot-able by syslinux. Syslinux has become extremely important in
making live images, and installation disks (think debian installer). So we
have a use case with hundreds of developers avoiding grub over and over.
But, bringing tons of issues to the table, as all of these installations
are written to cheap USB by the end users, and sometimes proceeded to be
booted off of worst case scenario hardware (think apple).
I vote: "More documentation, less new modules and patches." ie; use
case
documentation:
1) PXE booting a [core2duo-toshiba-laptop-satellite ] from another
[core2duo-toshiba-laptop-satellite ]. (anything cheap, easily affordable)
2) Partition , format and create a syslinux based USB , using [syslinux
4.x] on a [sancruz shiester USB], testing on a
[toshiba-core2duo-laptop-satellite ]
3) The same with freebsd and xen
4) New other stuff we don't know about yet.

Moreover the above example illustrates that documentation can also present
results from a scientific control study.

Sincerely, -chris graff  (dean)

Hi,

hpa wrote:
> LBA = (C * H' * S') + (H * S') + (S - 1)
> [...]
> Start LBA       63 = CHS    0   1   1
> End   LBA 15794175 = CHS  982 254  63
> If LBA 63 = CHS 0/1/1 then we know S'=62, but that is completely
> inconsistent with the ending sector being 63.
Wouldn't that be S'=63 ?
63 = (0 * H' * 63) + (1 * 63) + (1 - 1)

Whatever, the stick producers seem to take the same freedom
as needed when the disk size exceeds 1023*255*63 :
Start LBA plus blocksize does not need to match end CHS.

Ady's understanding seems not uncommon, that the end CHS address
shall indicate H' and S' by (H + 1) and S.
I wonder if this is specified anywhere.
(It is equivalent to cylinder alignment of the partition end.)

 
> Fortunately geometry is becoming a fading problem.  We're dealing with
> an old board and BIOS here.
My own hardware is of similar age.

I am getting more and more pessimistic with the idea to
propose at least one "normal" MS-DOS filesystem setup.
If not Ady comes to the rescue, that is.

It seems so unfair to leave the users alone with mad partitioning
and naive boards. :o)


Have a nice day :)

Thomas

the closest i have gotten to a consistent way to test a MS-DOS filesystem
setup is:

dd if=/dev/zero of=binary.img bs=1M count=500
i="$(losetup -f --show binary.img )"
parted binary.img mklabel msdos -s -m
dd if=/usr/lib/syslinux/mbr.bin of="${i}"
parted binary.img mkpart primary -a optimal -s -m 0% 100%
parted binary.img set 1 boot on
mkfs.ext4 $(kpartx -savu "${i}" | awk 'NR==1{print
"/dev/mapper/"$3 }' )
mount $(kpartx -savu "${i}" | awk 'NR==1{print
"/dev/mapper/"$3 }' ) /mnt
extlinux --install /mnt/boot
cp /usr/lib/syslinux/vesamenu.c32 /mnt/boot
cat > /mnt/boot/extlinux.conf <<EOF
UI vesamenu.c32
DEFAULT linux
LABEL linux
LINUX /boot/bzImage
APPEND root=/dev/sda1 init=/bin/ash
EOF
umount /mnt
kpartx -d "${i}"
losetup -d "${i}"
kvm binary.img

works
but not with gpt
-chris graff (dean)


On Tue, Jan 21, 2014 at 11:07 AM, Thomas Schmitt <scdbackup at gmx.net>
wrote:
> Hi,
>
> hpa wrote:
> > LBA = (C * H' * S') + (H * S') + (S - 1)
> > [...]
> > Start LBA       63 = CHS    0   1   1
> > End   LBA 15794175 = CHS  982 254  63
> > If LBA 63 = CHS 0/1/1 then we know S'=62, but that is completely
> > inconsistent with the ending sector being 63.
>
> Wouldn't that be S'=63 ?
> 63 = (0 * H' * 63) + (1 * 63) + (1 - 1)
>
> Whatever, the stick producers seem to take the same freedom
> as needed when the disk size exceeds 1023*255*63 :
> Start LBA plus blocksize does not need to match end CHS.
>
> Ady's understanding seems not uncommon, that the end CHS address
> shall indicate H' and S' by (H + 1) and S.
> I wonder if this is specified anywhere.
> (It is equivalent to cylinder alignment of the partition end.)
>
>
> > Fortunately geometry is becoming a fading problem.  We're dealing
with
> > an old board and BIOS here.
>
> My own hardware is of similar age.
>
> I am getting more and more pessimistic with the idea to
> propose at least one "normal" MS-DOS filesystem setup.
> If not Ady comes to the rescue, that is.
>
> It seems so unfair to leave the users alone with mad partitioning
> and naive boards. :o)
>
>
> Have a nice day :)
>
> Thomas
>
> _______________________________________________
> 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.
>
>

On 01/21/2014 09:07 AM, Thomas Schmitt wrote:
> Hi,
> 
> hpa wrote:
>> LBA = (C * H' * S') + (H * S') + (S - 1)
>> [...]
>> Start LBA       63 = CHS    0   1   1
>> End   LBA 15794175 = CHS  982 254  63
>> If LBA 63 = CHS 0/1/1 then we know S'=62, but that is completely
>> inconsistent with the ending sector being 63.
> 
> Wouldn't that be S'=63 ?
> 63 = (0 * H' * 63) + (1 * 63) + (1 - 1)
> 
Oh, right.  Mental fault on my part.
> Whatever, the stick producers seem to take the same freedom
> as needed when the disk size exceeds 1023*255*63 :
> Start LBA plus blocksize does not need to match end CHS.
Well, at that point it really *can't*.  The best practice seems to be to
make the end CHS equal to 1023/H'/S' at that point.
> Ady's understanding seems not uncommon, that the end CHS address
> shall indicate H' and S' by (H + 1) and S.
Right.
> I wonder if this is specified anywhere.
> (It is equivalent to cylinder alignment of the partition end.)
> 
>  
>> Fortunately geometry is becoming a fading problem.  We're dealing
with
>> an old board and BIOS here.
> 
> My own hardware is of similar age.
> 
> I am getting more and more pessimistic with the idea to
> propose at least one "normal" MS-DOS filesystem setup.
> If not Ady comes to the rescue, that is.
There is one... the closest thing we have found to work mostly
everywhere is a 64/32 CHS, with 255/63 as reasonably close second.  The
mkdiskimage tool in the Syslinux distribution exists for this reason.

	-hpa