ipcop-devel Mailing List for IPCop Firewall

Guenter wrote:

> David,
> Am 30.08.2010 01:52, schrieb David W Studeman:
>> Since your Alix is more of a normal machine (probably has a bios, can use
>> a bootlaoder etc) Did you pass the slower serial via extlinux.conf? Or
>> did you do this via inittab? I do believe there is an auto setting as
>> well but I'm not sure if it can be used everywhere.
> yup, it is a micro-board with an AMD Geode 500MHz, 256MB RAM, a special
> 'TinyBIOS', serial line, USB, and IDE / CF interface. The standard
> serial installation via PXE works. The serial line speed is set in
> extlinux.conf, and 38400 is the default what is set in distro; however I
> did always change that to 115200 because then the screens were rendered
> much quicker; around version 1.9.11 or so the higher speed did no longer
> work. I could also reproduce this with a Futro D100 machine - thats a
> remote client machine with P3-1300MHz, VGA, etc. (just a normal x86
> board). Since the higher serial speed did work all the time before I had a
> hard time to find out that is is why my installations now broke - many
> others reported that it works for them on same hardware - even when they
> used my own builds; I would never have thought that things like that:
> http://www.gknw.net/test/ipcop/ipcop_bootlloader_installation_error.png
> could be related to the baudrate ...
> 
> Gün.
> 
The Cobalt machines are pretty much hard set at 115200. I was able to 
compile with the kernel command line embedded in the kernel itself and set 
the baud lower but then the serial console sees garbage. For me, the problem 
started showing up after build 4646 and before 4696. Of course this is all 
on the 3000 series Cobalts. 

Works fine on the Raq550 which is one of the two 5000 series and is a 
different system altogether, chipset, socket 370 instead of socket 7, ECC 
ram different rom layout. It really was the best Cobalt machine made except 
it takes a bit of work to quiet it down, and was built by Sun themselves 
just before they discontinued the line they acquired from Cobalt Networks. 

Of course getting the thing installed on a drive is not an issue here since 
I can't PXE a Cobalt anyway. 
-- 
Dave
http://www.raqcop.com

David,
Am 30.08.2010 01:52, schrieb David W Studeman:
> Since your Alix is more of a normal machine (probably has a bios, can use a
> bootlaoder etc) Did you pass the slower serial via extlinux.conf? Or did you
> do this via inittab? I do believe there is an auto setting as well but I'm
> not sure if it can be used everywhere.
yup, it is a micro-board with an AMD Geode 500MHz, 256MB RAM, a special 
'TinyBIOS', serial line, USB, and IDE / CF interface. The standard 
serial installation via PXE works. The serial line speed is set in 
extlinux.conf, and 38400 is the default what is set in distro; however I 
did always change that to 115200 because then the screens were rendered 
much quicker; around version 1.9.11 or so the higher speed did no longer 
work. I could also reproduce this with a Futro D100 machine - thats a 
remote client machine with P3-1300MHz, VGA, etc. (just a normal x86 board).
Since the higher serial speed did work all the time before I had a hard 
time to find out that is is why my installations now broke - many others 
reported that it works for them on same hardware - even when they used 
my own builds; I would never have thought that things like that:
http://www.gknw.net/test/ipcop/ipcop_bootlloader_installation_error.png
could be related to the baudrate ...

Gün.

Guenter wrote:

> Hi David;
> Am 29.08.2010 12:09, schrieb David W Studeman:
>> OK, I experimented with embedded commands and it does indeed override the
>> arguments that the rom passes but it did no good so I reverted back to no
>> embedded command line and built in dev tmpfs and mounting, same thing
>> except I could see dev being mounted before init. This is on a 3000
>> series with the K6-2 or 3 processors. Since /dev being mounted in sysinit
>> and the command line passed by the rom are not the issue, I reverted back
>> to what I had before experimentation.
>>
>> Ok, on to the Raq 550. The Raq 550 came in two versions, one with a 1ghz
>> Pentium III and the other with a 1.26ghz Pentium III, I have the latter
>> here. A fresh install of 1.9.15 final revision boots on this hardware
>> just fine. Now to figure out why the 3000 series does not init and the
>> Raq550 of the 5000 series does.
>>
>> What in the last two months could be killing the slower architecture?
> I had some strange problems too with my slower embedded Alix, and it
> turned out that at some point changes caused that 115200 serial speed
> does no longer work - if I switch to 38400 all is fine ...
> I have also K6-2 400 and 500 MHz, and works fine there, so processor
> speed seems not relevant - I think more it has to do with serial line
> ...; so if possible change to 38400 and check how that behaves ...
> 
> Gün.

Since your Alix is more of a normal machine (probably has a bios, can use a 
bootlaoder etc) Did you pass the slower serial via extlinux.conf? Or did you 
do this via inittab? I do believe there is an auto setting as well but I'm 
not sure if it can be used everywhere. 

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

Hi David;
Am 29.08.2010 12:09, schrieb David W Studeman:
> OK, I experimented with embedded commands and it does indeed override the
> arguments that the rom passes but it did no good so I reverted back to no
> embedded command line and built in dev tmpfs and mounting, same thing except
> I could see dev being mounted before init. This is on a 3000 series with the
> K6-2 or 3 processors. Since /dev being mounted in sysinit and the command
> line passed by the rom are not the issue, I reverted back to what I had
> before experimentation.
>
> Ok, on to the Raq 550. The Raq 550 came in two versions, one with a 1ghz
> Pentium III and the other with a 1.26ghz Pentium III, I have the latter
> here. A fresh install of 1.9.15 final revision boots on this hardware just
> fine. Now to figure out why the 3000 series does not init and the Raq550 of
> the 5000 series does.
>
> What in the last two months could be killing the slower architecture?
I had some strange problems too with my slower embedded Alix, and it 
turned out that at some point changes caused that 115200 serial speed 
does no longer work - if I switch to 38400 all is fine ...
I have also K6-2 400 and 500 MHz, and works fine there, so processor 
speed seems not relevant - I think more it has to do with serial line 
...; so if possible change to 38400 and check how that behaves ...

Gün.

David W Studeman wrote:


> This is baffling me and I do not have a working 1.9.15... yet. Would
> there be any reason to start using a new feature in the kernel that
> allows you to embed the command line and also override anything given to
> it by a bootloader or cobalt rom?
> 
> I notice that in extlinux you pass panic=10 as well as where root is.
> The current init arguments passed by the rom are command line:
> 'console=ttyS0,115200 debug ip=off '. With the newer kernels I can
> override that with anything I want and have it ignore what is passed by
> the rom as I touched on above.
> 
> As it is now root is mounting in read only mode just before init so at
> least the rom knows where the kernel is but does it need more?
> 

OK, I experimented with embedded commands and it does indeed override the 
arguments that the rom passes but it did no good so I reverted back to no 
embedded command line and built in dev tmpfs and mounting, same thing except 
I could see dev being mounted before init. This is on a 3000 series with the 
K6-2 or 3 processors. Since /dev being mounted in sysinit and the command 
line passed by the rom are not the issue, I reverted back to what I had 
before experimentation.

Ok, on to the Raq 550. The Raq 550 came in two versions, one with a 1ghz 
Pentium III and the other with a 1.26ghz Pentium III, I have the latter 
here. A fresh install of 1.9.15 final revision boots on this hardware just 
fine. Now to figure out why the 3000 series does not init and the Raq550 of 
the 5000 series does. 

What in the last two months could be killing the slower architecture?
-- 
Dave
http://www.raqcop.com

On 8/23/2010 1:37 PM, David W Studeman wrote:
> Olaf Westrik wrote:
>
>> On 2010-08-22 21:01, David W Studeman wrote:
>>
>>> Ok, 4750 does the same thing as I mentioned in another part of this
>>> thread. I went back and made a complete 4646 build including toolchain
>>> and that worked fine while using openSuSE 11.3 except the edit for
>>> make.sh to look for "patch". I started working my way up from there and
>>> at 4696 is when I began to see init problems. UDEV was updated at this
>>> point. Serial console output from 4696:
>>>
>>> ---------------------------- SNIP
>>> ---------------------------------------- VFS: Mounted root (ext3
>>> filesystem) readonly on device 3:1. Freeing unused kernel memory: 152k
>>> freed INIT: version 2.86 booting
>>> INIT: Entering runlevel: 3
>>> INIT: Id "s0" respawning too fast: disabled for 5 minutes
>>> INIT: no more processes left in this runlevel
>>>
> --------------------------------------------------------------------------
>>>
>>> It then periodically repeats the last two lines.
>>
>> Hmmm, I'll try and remember where cobalts are different ;-)
>>
>>
>> Olaf
>>

This is baffling me and I do not have a working 1.9.15... yet. Would 
there be any reason to start using a new feature in the kernel that 
allows you to embed the command line and also override anything given to 
it by a bootloader or cobalt rom?

I notice that in extlinux you pass panic=10 as well as where root is. 
The current init arguments passed by the rom are command line: 
'console=ttyS0,115200 debug ip=off '. With the newer kernels I can 
override that with anything I want and have it ignore what is passed by 
the rom as I touched on above.

As it is now root is mounting in read only mode just before init so at 
least the rom knows where the kernel is but does it need more?

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

Dear all,


the v1.9.15 installation files for testing IPCop on x86 machines are 
available for download on SourceForge: 
http://sourceforge.net/projects/ipcop/files/IPCop%20Test%20Versions/IPCop%201.9.15
Since 1.9.14 many minor and some larger things were changed, fixed, etc ...
There is *NO* update available, 1.9.15 requires a new installation.


With this beta version you will find many things working and some not
working.
Currently known to not work is usb-modeswitch and the display of traffic 
accouting data in 'Low' detail mode (see admin manual for info).


Depending on how things work out, 1.9.15 might just be the latest beta 
of the v2.0 series.


Happy testing ...

Olaf


===================================


IPCop 1.9.15 is released

v1.9.15 is a BETA version, *DO NOT* use in a productive environment.

Some things will work, for example cleaning your harddisk on installation.
Some things may work.
Some things will not work.

There may be updates to later versions, but it is possible that a full
installation is required to use newer versions.


If you want to help, you can do so by testing and reporting any issues
you should find. Reports should go to the ipcop-devel mailing list.
Make sure that reports are verbose! also specify the exact version you
have been testing, either 1.9.15 or SVN version number if you are building
IPCop by yourself.
A simple "xyz does not work" will get you nowhere! and is more than likely
to be ignored.


For those familiar with earlier IPCop versions, IPCop v2 is different.

Noteworthy:
- the GUI uses 8443 instead of 445.
- SSH uses 8022 instead of 222.
- access to IPCop and to the internet from internal networks (aka
Green, Blue, Orange) is very much different. Spend some time with the
various options you will find under "Firewall Settings" and the online
admin manual.
- Dutch, English and German translations are complete, other languages
are work in progress.
- (online) manual is not yet complete but large sections are available
and worth reading.


v1.9.15 is a BETA version, *DO NOT* use in a productive environment.


Online English admin manual: http://www.ipcop.org/2.0.0/en/admin/html
Online German admin manual: http://www.ipcop.org/2.0.0/de/admin/html


Installation
190397220d526c25b70ccea3d4cceb3e  ipcop-1.9.15-install-cd.i486.iso
4f4662b1dfd97c69fd977cf5798b54e4  ipcop-1.9.15-install-netboot.i486.tgz
6b7d4e3f5de438f47d24f279713cd145  ipcop-1.9.15-install-usb-fdd.i486.img.gz
310282de2d0833c53ac048148b83550a  ipcop-1.9.15-install-usb-hdd.i486.img.gz
3ad4dcb07b25b880ffcf8dc39c7fdf54  ipcop-1.9.15-install-usb-zip.i486.img.gz

Gilles Espinasse wrote:

> 
> ----- Original Message -----
> From: "Olaf Westrik" <wei...@ip...>
> To: "Gilles Espinasse" <g....@fr...>
> Cc: "IPCOP devel"
> <ipc...@li...> Sent:
> Friday, August 27, 2010 5:54 PM Subject: Re: [IPCop-devel] 'freeze' for
> 1.9.15
> 
> 
>> On 2010-08-27 17:45, Gilles Espinasse wrote:
>>
>> > I have a few minor fixes in make.sh :
>> > - mount --bind /dev/shm like LFS do (haven't noticed a difference)
>> > - fix patch version detection when GNU is prepended (just do like with
> grep)
>> > - fix static libc detection on x86_64 host
>> >
>> > Should I commit that?
>>
>> Sure, go ahead.
>>
> done
> 
> The good new is that I was able to build the x86_64 toolchain without a
> glitch. Starting from stage2, the process should be the same for the final
> x86_32 build, I am confident for the final steps.
> Still processing compilation+tests.  I am at the final gcc stage actually.
> 
> So on x86_64, it should not more be required to download a i486 toolchain
> (and start ./make.sh from a linux32 shell ). It is possible now to build
> your own toolchain package (or download the x86_64 package once we have
> uploaded that on SF.
> 
> Gilles
> 
Builds both toolchain and distro fine on openSuSE 11.3 x86_64. This is build 
4886. Still, trying to figure out why it panics when init starts though on 
Cobalt builds.

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

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Friday, August 27, 2010 5:54 PM
Subject: Re: [IPCop-devel] 'freeze' for 1.9.15


> On 2010-08-27 17:45, Gilles Espinasse wrote:
>
> > I have a few minor fixes in make.sh :
> > - mount --bind /dev/shm like LFS do (haven't noticed a difference)
> > - fix patch version detection when GNU is prepended (just do like with
grep)
> > - fix static libc detection on x86_64 host
> >
> > Should I commit that?
>
> Sure, go ahead.
>
done

The good new is that I was able to build the x86_64 toolchain without a
glitch. Starting from stage2, the process should be the same for the final
x86_32 build, I am confident for the final steps.
Still processing compilation+tests.  I am at the final gcc stage actually.

So on x86_64, it should not more be required to download a i486 toolchain
(and start ./make.sh from a linux32 shell ). It is possible now to build
your own toolchain package (or download the x86_64 package once we have
uploaded that on SF.

Gilles

On 2010-08-27 17:45, Gilles Espinasse wrote:

> I have a few minor fixes in make.sh :
> - mount --bind /dev/shm like LFS do (haven't noticed a difference)
> - fix patch version detection when GNU is prepended (just do like with grep)
> - fix static libc detection on x86_64 host
>
> Should I commit that?

Sure, go ahead.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>
Sent: Tuesday, August 24, 2010 10:36 PM
Subject: Re: [IPCop-devel] 'freeze' for 1.9.15


> On 2010-08-23 22:12, Olaf Westrik wrote:
>
> > commit to SVN till Friday, 20th August 23:59 UTC.
>
> That should of course be 27 not 20.
>
>
> Olaf
>
Just comming home
I have a few minor fixes in make.sh :
- mount --bind /dev/shm like LFS do (haven't noticed a difference)
- fix patch version detection when GNU is prepended (just do like with grep)
- fix static libc detection on x86_64 host

Should I commit that?

Still recompiling on x86_32 bits host with kernel 2.6.32.21.

My experience on x86_64 host compilation is somewhat limited to glib PASS1
actually.
I had some issues during distrib install hard to resolve without ethernet
network.

Gilles

On 2010-08-23 22:12, Olaf Westrik wrote:

> commit to SVN till Friday, 20th August 23:59 UTC.

That should of course be 27 not 20.


Olaf

Feature Requests item #3052181, was opened at 2010-08-24 10:45
Message generated for change (Tracker Item Submitted) made by mromadi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3052181&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: Mourad Romadi (mromadi)
Assigned to: Nobody/Anonymous (nobody)
Summary: UPS and Load Balancing on RED interfaces support

Initial Comment:
UPS support to protect hard drives from power suply shortage.
Load Balancing on RED interfaces support to route to another interface when the prefered one is down.

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

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

Olaf Westrik wrote:

> On 2010-08-22 21:01, David W Studeman wrote:
> 
>> Ok, 4750 does the same thing as I mentioned in another part of this
>> thread. I went back and made a complete 4646 build including toolchain
>> and that worked fine while using openSuSE 11.3 except the edit for
>> make.sh to look for "patch". I started working my way up from there and
>> at 4696 is when I began to see init problems. UDEV was updated at this
>> point. Serial console output from 4696:
>>
>> ---------------------------- SNIP
>> ---------------------------------------- VFS: Mounted root (ext3
>> filesystem) readonly on device 3:1. Freeing unused kernel memory: 152k
>> freed INIT: version 2.86 booting
>> INIT: Entering runlevel: 3
>> INIT: Id "s0" respawning too fast: disabled for 5 minutes
>> INIT: no more processes left in this runlevel
>> 
--------------------------------------------------------------------------
>>
>> It then periodically repeats the last two lines.
> 
> Hmmm, I'll try and remember where cobalts are different ;-)
> 
> 
> Olaf
> 
Just out of curiousity I did supplant the lfs and rootfiles for udev from 
the 4646 and try that in a new build, no change. Also I did compile a debug 
kernel and that merely gives slightly more verbose output from the kernel 
itself which clearly is not having any trouble starting, the debug kernel 
gives us no more useful information. When the system goes into init it 
panics and stops. There are no logs available to study when mounting the 
system drive in another machine.

So far it's not udev and it's not the kernel and it's not the newer version 
of init. 

To refresh where Cobalts are different, the rom which is a tiny OS in itself 
that occupies all but the last sectors (the rom manager takes this space) of 
the rom, passes an argument to the vmlinux kernel in the system and then it 
starts to boot. Nothing in initramfs nor any bootloader will have any effect 
on how the system starts and is not even seen by a Cobalt. I exclude all of 
that from the installation because it is just clutter in a Cobalt. Same with 
the standard modules and kernel. The install process I changed quite a while 
ago where setup is done minus networking on install so that one can do it 
after the system boots with the Cobalt kernel and modules. You fixed setup 
for me so this can be done. 

Recent changes in the kernel will allow us to embed an argument in the 
kernel itself if we ever needed to. If done, the kernel will ignore the 
argument sent by the rom. The rom passes what's needed to have serial 
console output as it is. Haven't thought of anything I'd replace it with in 
the kernel but we can without going into the rom and passing an argument 
that will never be permanent in the rom.

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

On 2010-08-01 22:33, Olaf Westrik wrote:

> Now that 'life' is slowly but steadily coming back to normal, I also
> intend to push out 1.9.15 somewhere next week if everything is OK from
> the toolchain side.

A bit late and still not 100%, anyways if there are no really, really 
urgent things, commit to SVN till Friday, 20th August 23:59 UTC.
After that I'll start building, testing bits and pieces and release 
1.9.15 Saterday/Sunday.


Olaf

PS yes I mean August 20th this year 2010 ;-)
PPS my current estimate is to have 1 or 2 more beta releases after 
1.9.15, with a much shorter cycle and again available as updates.

On 2010-08-22 21:01, David W Studeman wrote:

> Ok, 4750 does the same thing as I mentioned in another part of this thread.
> I went back and made a complete 4646 build including toolchain and that
> worked fine while using openSuSE 11.3 except the edit for make.sh to look
> for "patch". I started working my way up from there and at 4696 is when I
> began to see init problems. UDEV was updated at this point. Serial console
> output from 4696:
>
> ---------------------------- SNIP ----------------------------------------
> VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
> Freeing unused kernel memory: 152k freed
> INIT: version 2.86 booting
> INIT: Entering runlevel: 3
> INIT: Id "s0" respawning too fast: disabled for 5 minutes
> INIT: no more processes left in this runlevel
> --------------------------------------------------------------------------
>
> It then periodically repeats the last two lines.

Hmmm, I'll try and remember where cobalts are different ;-)


Olaf

Olaf Westrik wrote:

> On 2010-08-16 08:25, David W Studeman wrote:
> 
>> 4646 is the last build I ran and I just tested it by imaging it to the
>> flash drive and booting. I wish I would have tested more builds
>> recently. I build them regularly, almost daily to make sure they build
>> but hadn't tested as often as I'd like. I do test any that get uploaded
>> to my site though. I left a two month gap though. Not sure how helpful
>> this will be.
> 
> Difficult to tell.
> If possible try somewhere in the middle (4750 for example) and do a full
> rebuild of toolchain and image.
> 
> 
> Olaf
> 
Ok, 4750 does the same thing as I mentioned in another part of this thread. 
I went back and made a complete 4646 build including toolchain and that 
worked fine while using openSuSE 11.3 except the edit for make.sh to look 
for "patch". I started working my way up from there and at 4696 is when I 
began to see init problems. UDEV was updated at this point. Serial console 
output from 4696: 

---------------------------- SNIP ----------------------------------------
VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
Freeing unused kernel memory: 152k freed
INIT: version 2.86 booting
INIT: Entering runlevel: 3
INIT: Id "s0" respawning too fast: disabled for 5 minutes
INIT: no more processes left in this runlevel
--------------------------------------------------------------------------

It then periodically repeats the last two lines. 


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

Hello Twanny

> -----Ursprüngliche Nachricht-----
> Von: Twanny Azzopardi [mailto:twa...@gm...]
> Gesendet: Donnerstag, 19. August 2010 12:51
> An: ipc...@li...
> Betreff: Re: [IPCop-devel] trying to build ipcop with kernel 2.4.37
> 
> On Tuesday 17 August 2010 20:38:14 David W Studeman wrote:
> > On 8/17/2010 1:16 AM, Twanny Azzopardi wrote:
> > > Trying to build ipcop 1.4.21 with the latest 2.4 kernel --
> 2.4.37.9, any
> > > ideas?
> >
> > That kernel is already in cvs for the 1.4.22/23 update cycle.
> >
> > If you're going to experiment, I would urge that you look in CVS to
> see
> > if the developers already have an lfs script for what you are trying
> to
> > build or better yet, build the latest cvs pull.
> >
> > What in kernel 2.4.37 are looking for?
> >
> I'm trying to run asterisk  with skypeforasterisk
> 

http://www.ipfire.org/en/index

For this Firewall exist multiple addons, one is asterisk 1.4.28-5.
This is easier i think, and it uses a Linux with Kernel 2.6.

Bye
Michael

On Tuesday 17 August 2010 20:38:14 David W Studeman wrote:
> On 8/17/2010 1:16 AM, Twanny Azzopardi wrote:
> > Trying to build ipcop 1.4.21 with the latest 2.4 kernel -- 2.4.37.9, any
> > ideas?
> 
> That kernel is already in cvs for the 1.4.22/23 update cycle.
> 
> If you're going to experiment, I would urge that you look in CVS to see
> if the developers already have an lfs script for what you are trying to
> build or better yet, build the latest cvs pull.
> 
> What in kernel 2.4.37 are looking for?
> 
I'm trying to run asterisk  with skypeforasterisk

On 8/17/2010 11:46 AM, Olaf Westrik wrote:
> On 2010-08-16 22:04, David W Studeman wrote:
>
>> Before I do that, I'll build a current build with a current toolchain. My 32
>> bit machine is also running openSuSE 11.3 and for some reason when the
>> make.sh looks for prerequisites for patch it finds patch. I had to trick the
>> make.sh to look for "patch".
>>
>> Checking for GNU patch              [  2.5.4 ] [  patch ] [ FAIL ]
>>
>> The actual version is greater than 2.5.4.
>
> What is the output of patch --version
>
> I get this:
> patch 2.5.9
> Copyright (C) 1988 Larry Wall
> Copyright (C) 2003 Free Software Foundation, Inc.
>
> This program comes with NO WARRANTY, to the extent permitted by law.
> You may redistribute copies of this program
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
>
> written by Larry Wall and Paul Eggert
>
>
> Olaf

vaio:~ # patch --version
GNU patch 2.6.1.81-5b68
Copyright (C) 2003, 2009, 2010 Free Software Foundation, Inc.
Copyright (C) 1988 Larry Wall

License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Larry Wall and Paul Eggert


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

On 2010-08-16 22:04, David W Studeman wrote:

> Before I do that, I'll build a current build with a current toolchain. My 32
> bit machine is also running openSuSE 11.3 and for some reason when the
> make.sh looks for prerequisites for patch it finds patch. I had to trick the
> make.sh to look for "patch".
>
> Checking for GNU patch              [  2.5.4 ] [  patch ] [ FAIL ]
>
> The actual version is greater than 2.5.4.

What is the output of patch --version

I get this:
patch 2.5.9
Copyright (C) 1988 Larry Wall
Copyright (C) 2003 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert


Olaf

On 8/16/2010 1:04 PM, David W Studeman wrote:
> Olaf Westrik wrote:
>
>> On 2010-08-16 08:25, David W Studeman wrote:
>>
>>> 4646 is the last build I ran and I just tested it by imaging it to the
>>> flash drive and booting. I wish I would have tested more builds
>>> recently. I build them regularly, almost daily to make sure they build
>>> but hadn't tested as often as I'd like. I do test any that get uploaded
>>> to my site though. I left a two month gap though. Not sure how helpful
>>> this will be.
>>
>> Difficult to tell.
>> If possible try somewhere in the middle (4750 for example) and do a full
>> rebuild of toolchain and image.
>>
>>
>> Olaf
>>
> Before I do that, I'll build a current build with a current toolchain. My 32
> bit machine is also running openSuSE 11.3 and for some reason when the
> make.sh looks for prerequisites for patch it finds patch. I had to trick the
> make.sh to look for "patch".
>
> Checking for GNU patch              [  2.5.4 ] [  patch ] [ FAIL ]
>
> The actual version is greater than 2.5.4.
>
> I'll report my progress, if this doesn't work I'll rebuild all at 4750 and
> try that.
>
>

Well, that fails too. I just upgraded both build machines to openSuSE 
11.3 and this being caused by the build host is also one of my suspicions.

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

On 8/17/2010 1:16 AM, Twanny Azzopardi wrote:
> Trying to build ipcop 1.4.21 with the latest 2.4 kernel -- 2.4.37.9, any
> ideas?
>
That kernel is already in cvs for the 1.4.22/23 update cycle.

If you're going to experiment, I would urge that you look in CVS to see 
if the developers already have an lfs script for what you are trying to 
build or better yet, build the latest cvs pull.

What in kernel 2.4.37 are looking for?

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

Trying to build ipcop 1.4.21 with the latest 2.4 kernel -- 2.4.37.9, any 
ideas?

Olaf Westrik wrote:

> On 2010-08-16 08:25, David W Studeman wrote:
> 
>> 4646 is the last build I ran and I just tested it by imaging it to the
>> flash drive and booting. I wish I would have tested more builds
>> recently. I build them regularly, almost daily to make sure they build
>> but hadn't tested as often as I'd like. I do test any that get uploaded
>> to my site though. I left a two month gap though. Not sure how helpful
>> this will be.
> 
> Difficult to tell.
> If possible try somewhere in the middle (4750 for example) and do a full
> rebuild of toolchain and image.
> 
> 
> Olaf
> 
Before I do that, I'll build a current build with a current toolchain. My 32 
bit machine is also running openSuSE 11.3 and for some reason when the 
make.sh looks for prerequisites for patch it finds patch. I had to trick the 
make.sh to look for "patch". 

Checking for GNU patch              [  2.5.4 ] [  patch ] [ FAIL ]

The actual version is greater than 2.5.4. 

I'll report my progress, if this doesn't work I'll rebuild all at 4750 and 
try that.


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