similar to: [Patch] Fix lzo memory aliasing issue

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 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:

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

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

I was thinking... Perhaps I should just change any "isolinux" term with some f*ing off-topic crap while maintaining the same proposed patch; then maybe we would get some relevant (re)action about this issue from The Syslinux Project? diff --git a/lzo/prepcore.c b/lzo/prepcore.c index 9147b2e4..b5ebe88b 100644 --- a/lzo/prepcore.c +++ b/lzo/prepcore.c @@ -331,7 +331,7 @@ int main(int

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'" \

> 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,

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

From: Matt Fleming <matt.fleming at linux.intel.com> Move the MCONFIG files into a mk/ directory and give them more descriptive names. This is purely a cosmetic change to make the 'include' directives a bit more coherent by making it obvious exactly which MCONFIG file we're including. For example, in com32/lua/src/Makefile we exchange the line, include ../../MCONFIG for the

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

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: > 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, > > 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

CentOS Errata and Security Advisory 2014:0861 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0861.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 5573a762c075a0d03f070c6bd0b47c41311fff66e21e034863d514ee65d8c081 lzo-2.03-3.1.el6_5.1.i686.rpm

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've added lzo compression support for tinc 1.0pre8. Lzo is a very fast compressor (see http://www.oberhumer.com/opensource/lzo/). I've implemented it by using two new compression levels. Compression level 10 is for fast compression using lzo1x-1 algorithm. Compression level 11 is for slow compression using lzo1x-999 algorithm.

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:

CentOS Errata and Security Advisory 2014:0861 Moderate Upstream details at : https://access.redhat.com/errata/RHSA-2014:0861 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 898c40521dfa677aa2217a083a9f382618b359d7a1a0361167427123f3397632 lzo-2.06-6.el7_0.2.i686.rpm

[adding libguestfs list, for nbdkit reference below] On 10/4/18 8:39 AM, Stefan Fröberg wrote: > Hello. > Is it possible to improve NBD throughtput with LZO compression ? As in, have a way for the client and server to negotiate that both understand an LZO extension, at which point the client can request a read or write with a flag set to mark that the data is LZO-compressed, for less