similar to: Is this off topic?

The prescription for Boot Info Table says that checksumming begins at byte 64 of isolinux.bin. When prepcore writes isolinux.bin it begins copying bytes from the input file at the offset given by variable "start". But it begins checksumming at offset 64 of the input file. The problem exists since introduction of prepcore by release 4.00. ISO 9660 programs usually fix it when they write

> 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). Thank you Thomas for your replies and for looking into this issue. My part on the initial investigation that triggered this email thread is relatively small. Others deserve much more credit. I was/am providing not just my own report,

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) +

Hi, Ady wrote: > Apparently, one of the consequences seems to be that the default > checksum included in isolinux.bin doesn't seem to help those > users/programs that, for whichever reason (e.g. user lacking > knowledge), do not patch the boot info table. I agree and still riddle about the reason. > So, my question is whether there is some intentional reason for these

H, Ady wrote: > A_ The default checksum included in the tested isolinux.bin (offset 20, > 4-bytes-long) is the "correct" one (as oppose to the current situation, > since version 4.00). That's good news. > F_ In the tested isolinux.bin file, there are two additional bytes that > I found to be changed/affected by some ISO-building tools (e.g. > mkisofs), at

> Hi, > > Ady wrote: > > During May 2009, a commit by Peter deleted the checksumiso.pl file. The > > commit is: > > core: LZO compress the PM part of the core > > repo.or.cz/syslinux.git/commit/0d82b71304d596d80f3c4520f9dcf90048ca50b7 > > And so, since version 4.00, the 'code/checksumiso.pl' file is no longer > > included. > > How is

Hi Fi $ rpm --query --file /usr/bin/objcopy binutils-2.25.1-9.fc24.x86_64 $ cd syslinux-7cd1ed6/ $ make bios ... make[3]: Leaving directory '/tmp/syslinux-7cd1ed6/bios/gpxe' make[2]: Leaving directory '/tmp/syslinux-7cd1ed6/bios' make[1]: Leaving directory '/tmp/syslinux-7cd1ed6' $ file bios/core/*.bin bios/core/isolinux.bin: data bios/core/isolinux-debug.bin:

All, Thanks for all your help. Now, I can compile the latest source code base on RedHat 5.5 after update nasm(to 2.09) and binutil(2.17). And *make spotless* before *make* under core/ directory. But with the new pxelinux.0, the PXEClient can not bootup. The error info, No valid file system found! And stuck in there. I think maybe the gcc cause the problem. My gcc version is 4.1.2. Thanks aaron

When i build syslinux.4.02 i get an error like this. I haven't been able to figure out what could be wrong. My gcc version is 4.1.2 and nasm is 2.10.07. Binutils is 2.17.50 I am compiling on xenserver 6.0 Thanks Alakesh 31186 bytes (31 kB) copied, 0.000315067 seconds, 99.0 MB/s nasm -f elf -Ox -g -F dwarf -DDATE_STR="'0x5110300a'" \

Sorry Gene, I got the version of binutils is 2.17. I download the latest Binutils to make the *objdump* and *objcopy*. with both of these utilities to create new pxelinux.raw. then, the error message shows me that, objcopy -O binary pxelinux.elf pxelinux.raw ../lzo/prepcore pxelinux.raw pxelinux.bin ../lzo/prepcore: pxelinux.raw: output too big (30165, max 0) make[1]: *** [pxelinux.bin] Error 1

Hi, Is anyone compiled a new pxelinux.0 with syslinux code 4.03? right now, I got a error in compiling this version code, objdump -h pxelinux.elf > pxelinux.sec perl lstadjust.pl pxelinux.lsr pxelinux.sec pxelinux.lst objcopy -O binary pxelinux.elf pxelinux.raw ../lzo/prepcore pxelinux.raw pxelinux.bin ../lzo/prepcore: pxelinux.raw: output too big (30197, max 0) make[1]: *** [pxelinux.bin]

Hello, I try to recompile syslinux-4.00 pre31 on RHEL5 with gcc-4.1.2 and nasm 2.07. Because I'm looking for information about that gpxelinux->chain.c32 hd0 boot problem I added -DDEBUG=2 to com32/lib/Makefile I get: objdump -h pxelinux.elf > pxelinux.sec perl lstadjust.pl pxelinux.lsr pxelinux.sec pxelinux.lst objcopy -O binary pxelinux.elf pxelinux.raw ../lzo/prepcore

Hi, Ady wrote: > During May 2009, a commit by Peter deleted the checksumiso.pl file. The > commit is: > core: LZO compress the PM part of the core > repo.or.cz/syslinux.git/commit/0d82b71304d596d80f3c4520f9dcf90048ca50b7 > And so, since version 4.00, the 'code/checksumiso.pl' file is no longer > included. > How is the checksum of isolinux.bin calculated since

Hi together, this is the second version of my cross-compilation patch serie. I'm sending it in the hope to get an honest review, and possibly see the patches integrated upstream. Those patches allow to build syslinux using a toolchain different from the host one by explicitely using the host toolchain for the utilities that are required at build-time / on the build machine. I am using the

Originated/took from Steffen Winterfeldt and Michael Matz in opensuse's Syslinux package: https://bugzilla.opensuse.org/show_bug.cgi?id=1125616 "fix lzo memory aliasing issue" --- lzo/Makefile +++ lzo/Makefile @@ -19,6 +19,8 @@ LIB = lzo.a BINS = prepcore +OPTFLAGS += -fno-strict-aliasing + all : makeoutputdirs $(BINS) makeoutputdirs: -- -Ady

The first two patches basically fix two warnings, and the last one avoid compiling the whole core in Syslinux with debug enabled by default that was accidently added in commit 72842b6 I presume. Hi Matt, Please consider pulling too. Paulo The following changes since commit 1f822f83b3d757c9a72f1eb99ebd723ee61e625b: Fix Makefile install targets (2012-07-04 11:21:19 +0100) are available in

On Mon, Dec 29, 2014 at 8:36 PM, Gene Cumm <gene.cumm at gmail.com> wrote: > On Mon, Dec 29, 2014 at 3:39 PM, Michael Sumulong <msumulong at gmail.com> > wrote: > > Hi, > > > > In efi/build-gnu-efi.sh, there's a "git submodule update --init" command > > which is causing a compilation issue on my build. I currently build in an > >

It has been observed that binaries contents are depending on the order of linked objects. This order is caused by GNU make's wildcard function and the position of sources on filesystem. This change tries to prevent this kind of randomness. Also consider building using -j1 flag to make it even more reproductible. Change-Id: Ie8eee7f336e6f1fa2863c4150d967afd15519f1d Bug:

2015-11-30 14:14 UTC+01:00, Patrick Masotta <masottaus at yahoo.com>: >>>> >> The addition of the EFI_BUILD variable inside Makefiles could potentially >> affect scripts such as package builders, perhaps even the way the >> official (pre)release archives are built(?). > <<< > > I think the -mno-red-zone thing is a good catch, the rest of EFI

2015-11-20 8:15 UTC+01:00, Ady via Syslinux <syslinux at zytor.com>: >> > >> > I don't like the idea of changing "UI" (e.g. command line options that >> > might be used by some users) without very well-thought reasoning. >> >> This is not an UI. AFAIK, this script is not shipped to the user. I >> don't even see what a user could