search for: bi_length

...the dependency on mkisofs there for another reason? Thanks, David 245c245 < bi_pvd: dd 0x00000010 ; LBA of primary volume descriptor ;DEB --- >bi_pvd: dd 0xdeadbeef ; LBA of primary >volume descriptor 247c247 < bi_length: dd size_of_code ; Length of boot file ;DEB --- >bi_length: dd 0xdeadbeef ; Length of boot file 282a283,290 > ; Set up boot file sizes > mov eax,[bi_length] > sub eax,SECTORSIZE-3 >...

...or it: > Ok, not that I understand the code, but what *somehow* happens is that > the "embedded" checksum in Isolinux.bin (starting from 4.00) is the > checksum of the WHOLE file (i.e. starting from offset 0 instead of 64) > at a time when: > 1) the dword at offset 0x10 (bi_length) is still 0xDEAFBEEF > 2) the dword at offset 0x14 (bi_csum) is still 0xDEADBEEF > [...] Credits also go to Erwan.L. Slapping hand against forehead: I should have come to the idea to restore the initial byte pattern before testing with offset 0 instead of 64. The observations match my theor...

...of this table is as follows; all integers are in section 7.3.1 ("little endian") format. Offset Name Size Meaning 8 bi_pvd 4 bytes LBA of primary volume descriptor 12 bi_file 4 bytes LBA of boot file 16 bi_length 4 bytes Boot file length in bytes 20 bi_csum 4 bytes 32-bit checksum 24 bi_reserved 40 bytes Reserved The 32-bit checksum is the sum of all the 32-bit words in the boot file starting at byte offset 64. All linear block...

Hi, i think i found a suspect in lzo/prepcore.c and it would indeed be a wrong range of checksumming (speculative congratulations to Ady). Looking at http://repo.or.cz/syslinux.git/blob/0d82b71304d596d80f3c4520f9dcf90048ca50b7:/lzo/prepcore.c it seems that this change in line 374 could yield correct checksums: unsigned int ptr; - for (ptr = 64; ptr < offset; ptr += 4) +

...that I understand the code, but what *somehow* happens is that > > the "embedded" checksum in Isolinux.bin (starting from 4.00) is the > > checksum of the WHOLE file (i.e. starting from offset 0 instead of 64) > > at a time when: > > 1) the dword at offset 0x10 (bi_length) is still 0xDEAFBEEF > > 2) the dword at offset 0x14 (bi_csum) is still 0xDEADBEEF > > [...] Credits also go to Erwan.L. > > Slapping hand against forehead: I should have come to the idea to restore > the initial byte pattern before testing with offset 0 instead of 64. > &...

...erves credit for it: [quote] Ok, not that I understand the code, but what *somehow* happens is that the "embedded" checksum in Isolinux.bin (starting from 4.00) is the checksum of the WHOLE file (i.e. starting from offset 0 instead of 64) at a time when: 1) the dword at offset 0x10 (bi_length) is still 0xDEAFBEEF 2) the dword at offset 0x14 (bi_csum) is still 0xDEADBEEF Whether the file length is already changed or not at the time the checksum is calculated doesn't matter (since the file is being padded with 00's, and this doesn't change the checksum), I tried resetti...

This patch introduces extra functionality to chain.c, mainly with reference to BPB adjustments, but not only that. It expects 3 small patches I sent earlier (they are included for easy reference, patches 1-3/4). The changes introduced are: 1) file and boot sector use separate options to control load address and jump address (if applicable). Options are as described below: *