ipcop-devel Mailing List for IPCop Firewall

 Good job on the extra erase code. I was able to re-use two virtual disks to 
raid install without errors via VMWare. Previously, I had to delete and 
create new virtual disk images to get raid to install. This time it went 
straight through. Unfortunately this is currently the most practical way for 
me to install to a Cobalt.
-- 
Dave
http://www.raqcop.com

On 2011-02-20 12:11, Gilles Espinasse wrote:

> Would you be ok to change gcc default setting to use -fstack-protector only
> by default?

It's worth a try. Would be interesting to know how that interacts with 
grsecurity though, as I would like to add parts of that (not now, but 
later).


Olaf

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: "IPCOP devel" <ipc...@li...>
Sent: Saturday, February 05, 2011 5:00 PM
Subject: Re: kernel compiled with STACKPROTECTOR_ALL


I find some more explanation on stackprotector-all overhead at
http://osdir.com/ml/linux-kernel/2009-10/msg07064.html
Reading the entire post is interesting.

Just checking our compiled files, I found that the vmlinuz file (lzma
compressed) is 10% larger with -fstack-protector-all than
with -fstack-protector-all. Comparing compressed/vmlinux.bin size (the file
before before lzma compression), the difference is 390 kB.

It may be not easy to compile the kernel with only -fstack-protector
when -fstack-protector-all is hardcoded to gcc default.
I haven't tested but I suppose that may not work to add
'-fno-stack-protector -fstack-protector' to CFLAGS_KERNEL.
Unsure that may broke parts requiring -fno-stack-protector usage if this not
appended last.
So the question is do we really need a hardcoded default
with -fstack-protector-all?

Would you be ok to change gcc default setting to use -fstack-protector only
by default?

Gilles

Selon John Edwards <jo...@co...>:

> On Fri, Feb 11, 2011 at 09:04:25AM +0100, karesmakro wrote:
> > Hello there,
> > I know, the copfilter project is not appreciated very well! But this
> > problem do not belong only to copfilter, it's a common problem. I
> > noticed on applications, which uses much of memory (e.g. clamav), that
> > the memory is growing from day to day. I also noticed, if the
> > applications are restarted, the memory is not freeing (only a small part)
> > So my Cop was running 3 weeks and I had 56MB swapped space (with 1GB
> > RAM) and was growing.
>
>
> 56MB swap is not unusual. Things are not being used (eg spare login
> consoles) are swapped out to make way for more cache:
> 	http://en.wikipedia.org/wiki/Memory_leak#Other_memory_consumers
>
That's true.
You may have a small swap usage without leak when the system prefer to have more
disk cache and free a bit of memory to swap.

Anyway, to track kernel memory leak, the appropriate way should be to change
kernel config to add CONFIG_DEBUG_KMEMLEAK and CONFIG_DEBUGFS, recompile the
kernel and follow kmemleak usage.

Gilles

On Fri, Feb 11, 2011 at 09:04:25AM +0100, karesmakro wrote:
> Hello there,
> I know, the copfilter project is not appreciated very well! But this 
> problem do not belong only to copfilter, it's a common problem. I 
> noticed on applications, which uses much of memory (e.g. clamav), that 
> the memory is growing from day to day. I also noticed, if the 
> applications are restarted, the memory is not freeing (only a small part)
> So my Cop was running 3 weeks and I had 56MB swapped space (with 1GB 
> RAM) and was growing.


56MB swap is not unusual. Things are not being used (eg spare login
consoles) are swapped out to make way for more cache:
	http://en.wikipedia.org/wiki/Memory_leak#Other_memory_consumers

Look at the output of 'free -t', 'top', 'less /proc/cpuinfo' and
'less /proc/vmallocinfo to get more information about memory use.

Emails about a "memory leak" in IPCop have occured in the past and it
usually turns out to be kernel cache or a service using more memory.
Have a search of "memory leak" in the IPCop mailing lists archives:
	http://marc.info/?l=ipcop-user
	http://marc.info/?l=ipcop-devel


> I made some tests and also compiled clamav only with needed functions, 
> but this seems not to solve the problem. After some researches, I found 
> a well known kernel bug in mm page-allocator
> https://answers.launchpad.net/ubuntu/+source/linux/+question/130117

That question is for the kernel using the oom-killer (Out-Of-Memory
Killer) to stop processes when it is out of memory. Have you seen
that behaviour (eg services or programs stopping suddenly)? Search
/var/log/messages for "oom".

Also that question is for 2.6.32.25, and IPCop uses 2.6.32.28:
	http://sourceforge.net/apps/trac/ipcop/browser/ipcop/trunk/lfs/linux

The bug report referenced is for an even older version of the kernel
(2.6.32.23) and fixed in 2.6.32.26:
	https://bugs.launchpad.net/ubuntu/+source/linux/+bug/649483

And the original poster found the problem was vftpd (an FTP server)
and not the kernel.

I have many Ubuntu and Debian servers running 2.6.32 and have not had
any problems with memory usage on them. And some of run vsftpd. So I
am not sure how "well known" this really is.


> I'm currently using SVN Build 5349 and as I remember right, this was no 
> problem in SVN Builds at around Sep. - Nov. 2010
> 
> 
> So I hope, someone can say anything about!
> 
> regards, karesmakro



-- 
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
#---------------------------------------------------------#

Selon karesmakro <ip...@it...>:

> Hello there,
> I know, the copfilter project is not appreciated very well! But this
> problem do not belong only to copfilter, it's a common problem. I
> noticed on applications, which uses much of memory (e.g. clamav), that
> the memory is growing from day to day. I also noticed, if the
> applications are restarted, the memory is not freeing (only a small part)
> So my Cop was running 3 weeks and I had 56MB swapped space (with 1GB
> RAM) and was growing.
>
> I made some tests and also compiled clamav only with needed functions,
> but this seems not to solve the problem. After some researches, I found
> a well known kernel bug in mm page-allocator
> https://answers.launchpad.net/ubuntu/+source/linux/+question/130117
>
> I'm currently using SVN Build 5349 and as I remember right, this was no
> problem in SVN Builds at around Sep. - Nov. 2010
>
>
> So I hope, someone can say anything about!
>
> regards, karesmakro
>
Not easy to track an issue when there is no simple way to reproduce.

The launchpap link suggest that the leak does not appear in 2.6.33, only in
2.6.32.
That may mean a fix may miss in 2.6.32 longterm branch or that some different
interaction in 2.6.33 make that issue disappear.
I may try to look at git log changes from 2.6.32 to 2.6.33.
Unsure I could find a pin in this byte forrest.


Gilles

Hello there,
I know, the copfilter project is not appreciated very well! But this 
problem do not belong only to copfilter, it's a common problem. I 
noticed on applications, which uses much of memory (e.g. clamav), that 
the memory is growing from day to day. I also noticed, if the 
applications are restarted, the memory is not freeing (only a small part)
So my Cop was running 3 weeks and I had 56MB swapped space (with 1GB 
RAM) and was growing.

I made some tests and also compiled clamav only with needed functions, 
but this seems not to solve the problem. After some researches, I found 
a well known kernel bug in mm page-allocator
https://answers.launchpad.net/ubuntu/+source/linux/+question/130117

I'm currently using SVN Build 5349 and as I remember right, this was no 
problem in SVN Builds at around Sep. - Nov. 2010


So I hope, someone can say anything about!

regards, karesmakro

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: <ipc...@li...>
Sent: Wednesday, February 09, 2011 6:40 AM
Subject: Re: [IPCop-devel] ccache-3 upgrade


> On 2011-01-24 08:54, Gilles Espinasse wrote:
>
> > Probably much easier to use a separate log file for ccache stats
> > Attached the changed Config (and simplified a bit as we don't need to
check
> > if ccache is present after toolchain)
>
>
> Using 1 log for toolchain and normal build, can produce result like this:
>
> ...
>
> /home/svn/ipcop/test/trunk/files_i486/01_toolchain/strip
> cache directory                     /home/svn/ipcop/test/trunk/ccache
> cache hit (direct)                     0
> cache hit (preprocessed)               0
> cache miss                             0
> files in cache                     39467
> cache size                         420.0 Mbytes
> max cache size                       1.5 Gbytes
> /usr/src/files_i486/02_base/stage2
> cache directory                     /usr/src/ccache
> cache hit (direct)                     0
> cache hit (preprocessed)               0
> cache miss                             0
> files in cache                     74775
> cache size                         565.6 Mbytes
> max cache size                       1.0 Gbytes
>
> ...
>
> As the ccache from toolchain build could be some time ago or even on
> another machine, normally has no relation to the 'actual' ccache
> contents, I think it better to separate the logs.
>
I think that log should not be include in toolchain package.
I know I have some fixes to do for that.
I would to always be able to repackage the toolchain but I have to care not
include some files.

>
> Other (minor) point is the ccache size. When using prepackaged toolchain
> the size is left as default. Should be OK though as without toolchain
> build the ccache size requirement is not so high.
>
>
> Olaf

Yes that true that default size should be enought if you don't build the
toolchain.
We could notice in stage2 to add a ccache call if we compile much more
package (I hope not).

Gilles

On 2011-01-24 08:54, Gilles Espinasse wrote:

> Probably much easier to use a separate log file for ccache stats
> Attached the changed Config (and simplified a bit as we don't need to check
> if ccache is present after toolchain)


Using 1 log for toolchain and normal build, can produce result like this:

...

/home/svn/ipcop/test/trunk/files_i486/01_toolchain/strip
cache directory                     /home/svn/ipcop/test/trunk/ccache
cache hit (direct)                     0
cache hit (preprocessed)               0
cache miss                             0
files in cache                     39467
cache size                         420.0 Mbytes
max cache size                       1.5 Gbytes
/usr/src/files_i486/02_base/stage2
cache directory                     /usr/src/ccache
cache hit (direct)                     0
cache hit (preprocessed)               0
cache miss                             0
files in cache                     74775
cache size                         565.6 Mbytes
max cache size                       1.0 Gbytes

...

As the ccache from toolchain build could be some time ago or even on 
another machine, normally has no relation to the 'actual' ccache 
contents, I think it better to separate the logs.


Other (minor) point is the ccache size. When using prepackaged toolchain 
the size is left as default. Should be OK though as without toolchain 
build the ccache size requirement is not so high.


Olaf

On 2011-02-04 09:21, Gilles Espinasse wrote:

> Concerning perl, a 5.10.2 may happen. But no news in january.
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-12/msg00600.html

Reading that I am not sure whether 5.10.2 will appear, even then 
difficult to tell what would be included?


> We may still follow ubuntu-10.04 perl-5.10.1 package or RH6
> http://packages.ubuntu.com/maverick/perl

Or Debian Squeeze?  That's just been released and will see all important 
fixes for some time.


Olaf

On 2011-02-04 08:51, Olaf Westrik wrote:

> I have listed:
>    - update util-linux to 2.19 as soon as it becomes available
>    - update dnsmasq to 2.56
>    - Achim is working on some basics for email reporting
>    - Marco is working on proxy etc. That'll probably take more time, so
> not relevant for next release.

Almost forgot, binutils 2.21.


Olaf

On 2011-02-04 09:21, Gilles Espinasse wrote:

> - fix floppy build
> * vmlinuz compiled with -fno-stack-protector in CFLAGS produce random
> characters on screen when initramfs start and hang
> * vmlinuz compile without STACKPROTECTOR set in config work. But that fail
> to insmod modules compiled with STACKPROTECTOR
> * so the simple solution is revert using standard vmlinuz and remove again
> cd support from floppy

There are some savings in vmlinuz left: remove math emulation, making 
486DX the minimum required CPU and dropping support for EISA/VLB.
That saves approx. 40 KiB.

Probably good to remove both anyway, I don't think 486SX would work 
because of memory shortage and non-graphics EISA/VLB cards should be 
pretty rare by now.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>
Sent: Friday, February 04, 2011 8:51 AM
Subject: Re: [IPCop-devel] [2.0] Plans for next beta version (1.9.18/1.9.19)


>
> ... some time has past ...
>
>
> Anyways, many things have happened (not all related to IPCop though ;-))
> recently.
>
>
> I have listed:
>   - update util-linux to 2.19 as soon as it becomes available
>   - update dnsmasq to 2.56
>   - Achim is working on some basics for email reporting
>   - Marco is working on proxy etc. That'll probably take more time, so
> not relevant for next release.
>
>
> I am currently uncertain about Perl. There have been several changes in
> the 5.12 branch that need a closer look. At first look 5.10 appears
> unmainted, so we would probably need to consider changing to 5.12
>
>
> Olaf
>
Concerning perl, a 5.10.2 may happen. But no news in january.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-12/msg00600.html

We may still follow ubuntu-10.04 perl-5.10.1 package or RH6
http://packages.ubuntu.com/maverick/perl

I agree we could consider perl-5.12. This is not so deep in my todo list.

I would hope soon to:
- conclude my env build cleanup this week-end,
- fix floppy build
* vmlinuz compiled with -fno-stack-protector in CFLAGS produce random
characters on screen when initramfs start and hang
* vmlinuz compile without STACKPROTECTOR set in config work. But that fail
to insmod modules compiled with STACKPROTECTOR
* so the simple solution is revert using standard vmlinuz and remove again
cd support from floppy

- try to fix gcc for other arch since it is hardened.
I need to check what debian patch match the patches we include.

Gilles

... some time has past ...


Anyways, many things have happened (not all related to IPCop though ;-)) 
recently.


I have listed:
  - update util-linux to 2.19 as soon as it becomes available
  - update dnsmasq to 2.56
  - Achim is working on some basics for email reporting
  - Marco is working on proxy etc. That'll probably take more time, so 
not relevant for next release.


I am currently uncertain about Perl. There have been several changes in 
the 5.12 branch that need a closer look. At first look 5.10 appears 
unmainted, so we would probably need to consider changing to 5.12


Olaf

On 2011-02-04 08:22, Gilles Espinasse wrote:

>>> That could only be done in two steps.
>>> First, add xz in installed files, then compress next update with xz
>>
>> OK for that.
>>
> Due to how lfs/updates work, that mean 1.9.18 and 1.9.19 build as
> patch.tar.gz and later build as tar.xz.

Yeah, we'd need to change installpackage in 1.9.19 though. Probably 
easiest (for testing etc.) to make it possible to use both .gz and .xz.
Later we can fully remove support for .gz updates.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Friday, February 04, 2011 8:16 AM
Subject: Re: [IPCop-devel] enable XZ to compress updates?


> Hello Gilles,
>
>
> > That could only be done in two steps.
> > First, add xz in installed files, then compress next update with xz
>
> OK for that.
>
Due to how lfs/updates work, that mean 1.9.18 and 1.9.19 build as
patch.tar.gz and later build as tar.xz.
>
> > Uncompressing kernel modules before tar.xz creation allow a better
> > compression.
> > I add before tar.xz creation
> >   -find /tmp/lib/modules -name *.ko.gz -exec gzip -d {} \;
> >
> > and this result to
> > ls -s1 ipcop-1.9.19-update.i486.tgz
> > 8548 ipcop-1.9.19-update.i486.tgz
> >
> > Of course, we would need the reverse after installation to not require
more
> > space on disk, and that will cost another bit of time.
> > find /lib/modules/ -name '*.ko' -a -type f -exec gzip -nf9 {} \;
>
> I don't like that.
> I would very much prefer to leave files 'as-is' after building, so one
> day we can post file hashes (md5, sha1) of all IPCop files and people
> could then (automatically) compare their installation.
> That would be an easy system to detect tampering (unlikely) or disk
> trouble (more likely).
>
> Surely recompression should give the same result, but I think it too
> much trouble with small advantage.
>
>
> Olaf

I agree with you. I am fully ok when the simple way is choosen.
I was just curious and try to understand and explore the possibilities.

Gilles

Hello Gilles,


> That could only be done in two steps.
> First, add xz in installed files, then compress next update with xz

OK for that.


> Uncompressing kernel modules before tar.xz creation allow a better
> compression.
> I add before tar.xz creation
>   -find /tmp/lib/modules -name *.ko.gz -exec gzip -d {} \;
>
> and this result to
> ls -s1 ipcop-1.9.19-update.i486.tgz
> 8548 ipcop-1.9.19-update.i486.tgz
>
> Of course, we would need the reverse after installation to not require more
> space on disk, and that will cost another bit of time.
> find /lib/modules/ -name '*.ko' -a -type f -exec gzip -nf9 {} \;

I don't like that.
I would very much prefer to leave files 'as-is' after building, so one 
day we can post file hashes (md5, sha1) of all IPCop files and people 
could then (automatically) compare their installation.
That would be an easy system to detect tampering (unlikely) or disk 
trouble (more likely).

Surely recompression should give the same result, but I think it too 
much trouble with small advantage.


Olaf

That could only be done in two steps.
First, add xz in installed files, then compress next update with xz

I just tested 1.9.18 and 1.9.19 xz compressed with change in lfs/update like
this
 -cd /tmp && tar -c --xz --exclude=/tmp/patch.tar.xz -f /tmp/patch.tar.xz *
 # now remove everything except the package as other files are inside
 find /tmp/* -not -name patch.tar.xz -delete

This result in
ls -s1 ipcop-1.9.1?-update.i486.tgz
 8564 ipcop-1.9.18-update.i486.tgz
11320 ipcop-1.9.19-update.i486.tgz

vs using tar -cz
ls -s1 ipcop-1.9.1?-update.i486.tgz
12560 ipcop-1.9.18-update.i486.tgz
11988 ipcop-1.9.19-update.i486.tgz

The different behavior with 1.9.18 and 1.9.19 is interesting and show that
when data is already compressed like our kernel modules, that compress not
well with xz.

Uncompressing kernel modules before tar.xz creation allow a better
compression.
I add before tar.xz creation
 -find /tmp/lib/modules -name *.ko.gz -exec gzip -d {} \;

and this result to
ls -s1 ipcop-1.9.19-update.i486.tgz
8548 ipcop-1.9.19-update.i486.tgz

Of course, we would need the reverse after installation to not require more
space on disk, and that will cost another bit of time.
find /lib/modules/ -name '*.ko' -a -type f -exec gzip -nf9 {} \;

Time to compress one update is bigger, but less than initramfs creation
time.

Gilles

Feature Requests item #3171090, was opened at 2011-02-03 02:14
Message generated for change (Tracker Item Submitted) made by sebastiann
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3171090&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Next release
Status: Open
Priority: 5
Private: No
Submitted By: sebastian nielsen (sebastiann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add a !red interface to the interface selection

Initial Comment:
Add a !red (not red/red inverted) interface to the source interface selection when creating Outgoing access, IPCop Access or Internal Traffic rules.
Also add a !red interface to the destination interface selection for Internal Traffic rules.
So a user can select "everything not red" and avoid have to create rules like in the attached file.

Of course, this could be available only in advanced mode when creating IPCop access and Internal traffic rules because of security considerations. In outgoing traffic rules, the !red interface could be always available.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3171090&group_id=40604

----- Original Message ----- 
From: "David W Studeman" <avi...@ai...>
To: <g....@fr...>
Sent: Wednesday, February 02, 2011 10:50 PM
Subject: XZ logs


> Ok here they are Gilles. Thanks!
>
> Dave
>
I think you modified make.sh when it was not compiling xz correctly on
64-bits host and forgot something once that was fixed.
Your make.sh should look like this

 PASS="1"
 toolchain_make xz   # Early, to be sure, even in old host we could open
.lzma or .xz package like glibc
 toolchain_make binutils
 toolchain_make gcc
 # gcc pass1 is removed on lfs/strip. If absent that mean we don't need this
signature
 [ -f /${TOOLS_DIR}/bin/${LFS_TGT}-gcc ] && update-gcc-hash
"/${TOOLS_DIR}/bin/${LFS_TGT}-gcc"
 PASS=""
 toolchain_make linux-headers
 toolchain_make glibc
 toolchain_make adjust-toolchain
 PASS="2"
 toolchain_make binutils
 toolchain_make gcc
 update-gcc-hash "/${TOOLS_DIR}/bin/${TARGET_2}-gcc"
 PASS=""
 toolchain_make ncurses
 toolchain_make bash
 toolchain_make bzip2
 PASS="2"
 toolchain_make xz   # rebuild with our compiled libc
 PASS=""

I don't see another reason why xz-5.0.0_2 would only contain
+ cd /home/ipcop/cobaltsvn/lfs
+ linux32 make -f xz install CONFIG_ROOT=/var/ipcop
LFS_TGT=i486-lfs-linux-gnu TARGET_2=i486-linux-gnu LINKER=/lib/ld-linux.so.2
TOOLS_DIR=tools_i486 REQUIRED_KERNEL=2.6.5 MACHINE=i486
BUILDDATE=20110131-134021 LFS_BASEDIR=/home/ipcop/cobaltsvn
LFS=/home/ipcop/cobaltsvn/build_i486/ipcop PARALLELISM=3 PASS=2
RUNNING_TEST=no STAGE=toolchain STAGE_ORDER=01 SHELL=/bin/bash
TMPDIR=/home/ipcop/cobaltsvn/build_i486/ipcop/tmp
make: Nothing to be done for `install'.

and no compilation.

Gilles

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "Olaf Westrik" <wei...@ip...>
> Cc: "Gilles Espinasse" <g....@fr...>; "IPCOP devel"
> <ipc...@li...>; "David W
> Studeman" <avi...@ai...> Sent: Tuesday,
> February 01, 2011 9:50 PM Subject: Re: [IPCop-devel] GLIBC Error when
> building trun on 64 bit only.
> 
> 
>> On 2011-02-01 08:57, Olaf Westrik wrote:
>>
>> > IIRC my toolchain was last build with SVN 5376. I'll rebuild for the
>> > change to lfs/xz in commit 5382.
>>
>> After toolchain rebuild I have:
>> [chroot-x86_64] root:/$ ldd /tools_i486/bin/xz
>>          linux-gate.so.1 =>  (0xf770e000)
>>          libpthread.so.0 => /tools_i486/lib/libpthread.so.0 (0xf76f5000)
>>          libc.so.6 => /tools_i486/lib/libc.so.6 (0xf7592000)
>>          /tools_i486/lib/ld-linux.so.2 (0xf770f000)
> 
> The reason liblzma.so.5 is not listed there should that there is no
> liblzma under chroot /lib and /usr/lib (until we add xz compilation on
> base build). That then give
> [chroot-i486] root:/$ ldd /usr/bin/xz
>         linux-gate.so.1 =>  (0x00a55000)
>         liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00ec2000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00930000)
>         libc.so.6 => /lib/libc.so.6 (0x00a62000)
>         /lib/ld-linux.so.2 (0x00175000)
> ...
>>
>> On 2011-02-01 08:43, David W Studeman wrote:
>>
>>  > [chroot-x86_64] root:/$ ls /tools_i486/bin
>>  >
>>  > definitely shows the file xz. What's more is that browsing to it via
> file
>>  > manager shows it, it's executable by everyone and it's 178.9KB in
>>  > size.
>>
> Could David send me directly (because of mailing list size limit) his xz
> log (pass 1 & 2)
> Which distrib is the 64-bits host?
> 
It's openSuSE 11.3 and yes I will mail the xz logs directly to you.
> Mine is the same from 32-bits host and this is logical as x86_64 open a
> linux32 shell.
> 
> Gilles
> 
 


-- 
Dave
http://www.raqcop.com

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
Cc: "Gilles Espinasse" <g....@fr...>; "IPCOP devel"
<ipc...@li...>; "David W Studeman" <avi...@ai...>
Sent: Tuesday, February 01, 2011 9:50 PM
Subject: Re: [IPCop-devel] GLIBC Error when building trun on 64 bit only.


> On 2011-02-01 08:57, Olaf Westrik wrote:
>
> > IIRC my toolchain was last build with SVN 5376. I'll rebuild for the
> > change to lfs/xz in commit 5382.
>
> After toolchain rebuild I have:
> [chroot-x86_64] root:/$ ldd /tools_i486/bin/xz
>          linux-gate.so.1 =>  (0xf770e000)
>          libpthread.so.0 => /tools_i486/lib/libpthread.so.0 (0xf76f5000)
>          libc.so.6 => /tools_i486/lib/libc.so.6 (0xf7592000)
>          /tools_i486/lib/ld-linux.so.2 (0xf770f000)

The reason liblzma.so.5 is not listed there should that there is no liblzma
under chroot /lib and /usr/lib (until we add xz compilation on base build).
That then give
[chroot-i486] root:/$ ldd /usr/bin/xz
        linux-gate.so.1 =>  (0x00a55000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00ec2000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00930000)
        libc.so.6 => /lib/libc.so.6 (0x00a62000)
        /lib/ld-linux.so.2 (0x00175000)
...
>
> On 2011-02-01 08:43, David W Studeman wrote:
>
>  > [chroot-x86_64] root:/$ ls /tools_i486/bin
>  >
>  > definitely shows the file xz. What's more is that browsing to it via
file
>  > manager shows it, it's executable by everyone and it's 178.9KB in size.
>
Could David send me directly (because of mailing list size limit) his xz log
(pass 1 & 2)
Which distrib is the 64-bits host?

> That seems large, mine is:
>
> [chroot-x86_64] root:/$ ls -l /tools_i486/bin/xz
> -rwxr-xr-x 1 1001 1001 161672 Feb  1 09:35 /tools_i486/bin/xz
>
>
> Olaf

Mine is the same from 32-bits host and this is logical as x86_64 open a
linux32 shell.

Gilles

On 2011-02-01 08:57, Olaf Westrik wrote:

> IIRC my toolchain was last build with SVN 5376. I'll rebuild for the
> change to lfs/xz in commit 5382.

After toolchain rebuild I have:
[chroot-x86_64] root:/$ ldd /tools_i486/bin/xz
         linux-gate.so.1 =>  (0xf770e000)
         libpthread.so.0 => /tools_i486/lib/libpthread.so.0 (0xf76f5000)
         libc.so.6 => /tools_i486/lib/libc.so.6 (0xf7592000)
         /tools_i486/lib/ld-linux.so.2 (0xf770f000)
[chroot-x86_64] root:/$ /tools_i486/bin/xz --version
xz (XZ Utils) 5.0.0
liblzma 5.0.0



On 2011-02-01 08:43, David W Studeman wrote:

 > [chroot-x86_64] root:/$ ls /tools_i486/bin
 >
 > definitely shows the file xz. What's more is that browsing to it via file
 > manager shows it, it's executable by everyone and it's 178.9KB in size.

That seems large, mine is:

[chroot-x86_64] root:/$ ls -l /tools_i486/bin/xz
-rwxr-xr-x 1 1001 1001 161672 Feb  1 09:35 /tools_i486/bin/xz


Olaf

> ./make.sh shell
> [chroot-i486] root:/$ ldd /tools_i486/bin/xz
>          linux-gate.so.1 =>   (0x00c55000)
>          libpthread.so.0 =>  /tools_i486/lib/libpthread.so.0 (0x00cce000)
>          libc.so.6 =>  /tools_i486/lib/libc.so.6 (0x00488000)
>          /tools_i486/lib/ld-linux.so.2 (0x002e9000)
>
> Then try to check if xz work with
> [chroot-i486] root:/$ /tools_i486/bin/xz --version
> xz (XZ Utils) 5.0.0
> liblzma 5.0.0

I have:

[chroot-x86_64] root:/$ ldd /tools_i486/bin/xz
         linux-gate.so.1 =>  (0xf7772000)
         liblzma.so.5 => /tools_i486/lib/liblzma.so.5 (0xf7750000)
         libpthread.so.0 => /tools_i486/lib/libpthread.so.0 (0xf7738000)
         libc.so.6 => /tools_i486/lib/libc.so.6 (0xf75d5000)
         /tools_i486/lib/ld-linux.so.2 (0xf7773000)
[chroot-x86_64] root:/$ /tools_i486/bin/xz --version
xz (XZ Utils) 5.0.0
liblzma 5.0.0



IIRC my toolchain was last build with SVN 5376. I'll rebuild for the 
change to lfs/xz in commit 5382.



Olaf

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "David W Studeman" <avi...@ai...>
> To: <ipc...@li...>
> Sent: Tuesday, February 01, 2011 1:24 AM
> Subject: [IPCop-devel] GLIBC Error when building trun on 64 bit only.
> 
> 
>> Hello all! Lately I have been getting this error while trying to build on
> 64
>> bit. This is in the base build. This also does not happen when building
>> on my 32 bit Debian box. Here is the interrupt log:
>>
>> + cd /usr/src/lfs
>> + linux32 make -f glibc LFS_BASEDIR=/usr/src install
>> ====================================== Installing glibc-2.11.3 ...
>> Install started; saving file list to /usr/src/lsalr ...
>> /bin/sh: /tools_i486/bin/xz: No such file or directory
>> tar: This does not look like a tar archive
>> tar: Exiting with failure status due to previous errors
>> make: *** [/usr/src/files_i486/02_base/glibc-2.11.3] Error 2
>>
>> --
>> Dave
>> http://www.raqcop.com
>>
>>
> The xz build error on toolchain 64-bits build has been fixed a few days
> ago. I have build yesterday from a 32-bits and a 64-bits distrib.
> But I first rebuild the toolchain (./make.sh clean && ./make.sh toolchain)
> 
> I haven't yet incremented the toolchain package name and will do once I
> finished cleaning the env creation on toolchain.
> 
> That a long time we have xz compiled on toolchain, so I don't know what
> exactly happen.
> Could you try to look with ldd at xz inside the shell
> 
> ./make.sh shell
> [chroot-i486] root:/$ ldd /tools_i486/bin/xz
>         linux-gate.so.1 =>  (0x00c55000)
>         libpthread.so.0 => /tools_i486/lib/libpthread.so.0 (0x00cce000)
>         libc.so.6 => /tools_i486/lib/libc.so.6 (0x00488000)
>         /tools_i486/lib/ld-linux.so.2 (0x002e9000)
> 
> Then try to check if xz work with
> [chroot-i486] root:/$ /tools_i486/bin/xz --version
> xz (XZ Utils) 5.0.0
> liblzma 5.0.0
> 
> That's curious I didn't see liblzma as a dependency of xz.
> but I see the same with
> [chroot-i486] root:/$ readelf -d /tools_i486/bin/xz | grep NEEDED
>  0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
> 
> Gilles
> 
> 
[chroot-x86_64] root:/$ ldd /tools_i486/bin/xz
        not a dynamic executable

[chroot-x86_64] root:/$ /tools_i486/bin/xz --version
bash: /tools_i486/bin/xz: No such file or directory

And then running

[chroot-x86_64] root:/$ ls /tools_i486/bin

definitely shows the file xz. What's more is that browsing to it via file 
manager shows it, it's executable by everyone and it's 178.9KB in size. 


-- 
Dave
http://www.raqcop.com