ipcop-devel Mailing List for IPCop Firewall

On Wed, Apr 30, 2008 at 03:35:27PM -0400, Haute SubZero wrote:
<snip>
> If you can provide a bootable floppy image I'll be happy to try it 
> here.  I've still got a couple of Pentium machines, I'm currently 
> running on a PentiumPro, and I think I've still got a laptop around 
> that's a 486.

Thanks very much for the offer of help with the testing.

With the help of some C experts I think we have found the source of
the problem and Gilles is working on a long time fix for all CPU
types. When that is ready then I would like to do a wide test of as
many machines as possible and the 486 and PentiumPro would be
especially welcome as they are now quite rare.


The problem with floppy disk install is that when the development tree
is it changing quickly the size of the of disk images sometimes exceeds
1.44MB and so can not be used. The last test build I did produced:
$ du -sck ipcop*img
204     ipcop-1.9.1-mini-initramfs.img
1464    ipcop-1.9.1-network-drivers.img
1304    ipcop-1.9.1-root-1.img
1252    ipcop-1.9.1-root-2.img
1260    ipcop-1.9.1-scsi-drivers.img

Which I think means that the network drivers floppy disk is 20K
too big. I think we can tweak things a little by moving the
/lib/modules/2.6.24/kernel/lib/ directory to another disk, but
that can wait for a few day because other things may change.


I seem to remember there might be a way of putting syslinux onto a
floppy so that it will boot the CDROM, but I've not done it myself.

I am using PXE network booting to test things at the moment, because
my Pentium machines do not CDROM boot and it also saves on CDs. PXE is
very useful for techies because for networked machines you can get rid
of most of those old boot floppy and CDs and put them on the server
instead. But does requires people to modify DHCP and setup a TFTP
server so not everyone has the time or energy to do that.


When we rebuild the next set of test images then I will put up a PXE
build (8MB) and some floppy images (12MB) for the HTTP/FTP install
(32MB) as an alternative to the CDROM image (52MB).

I think that will be a week away, as I'm going to be working long
hours. Which will give the main developers time to be happy with the
changes.


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

John Edwards wrote:
> On Tue, Apr 29, 2008 at 06:32:53PM -0400, Ivan Kabaivanov wrote:
>   
>> On Tuesday 29 April 2008, John Edwards wrote:
>>     
>>> On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
>>>       
>>>> Hi
>>>>
>>>> Has anyone every successfully booted IPCop 1.5 or 2.0 on a Pentium or
>>>> lower CPU?  That is an Intel 486, 586 (Pentium I), AMD K5, AMD K6,
>>>> Cyrix 6x86.
>>>>
>>>> If anyone has then please email me the CVS/SVN revision number if you
>>>> can remember it, or rough date if you can't, and details of the CPU,
>>>> RAM and motherboard.
>>>>         
>>> <snip>
>>>
>>> Just to let everyone know that I have received no emails. I can
>>> only assume that IPCop 1.5 or 2.0 has never been tested on i586
>>> or i486, and so we have no known good build to work from.
>>>       
>> John,
>>
>> sorry for not responding, I'm quite busy these days, more on that in a later 
>> email. 
>>     
>
> Same here - very busy for the next month. Which is why I am trying to
> wrap this up quickly and possibly with less than perfect politeness.
>
>
>   
>> Speaking strictly for myself, I have an old original pentium (586) 
>> board, but can't remember what happened the last time I tried 2.0.
>> I won't  be able to test that for at least two more months :-(
>>     
>
> I was looking for a know good.
>
> One possible test point could be the last revision that used
> glibc 2.5 or 2.5.1 and built cleanly. 
>
>
>   
If you can provide a bootable floppy image I'll be happy to try it 
here.  I've still got a couple of Pentium machines, I'm currently 
running on a PentiumPro, and I think I've still got a laptop around 
that's a 486.

Melvin


-- 
  Do not meddle in the affairs of wizards,
  for they are subtle and quick to anger.
                      -- Gildor Inglorion

----- Original Message ----- 
From: "Ivan Kabaivanov" <ch...@ya...>
To: <ipc...@li...>
Sent: Wednesday, April 30, 2008 7:47 PM
Subject: Re: [IPCop-devel] [Ipcop-svn] SF.net SVN: ipcop:
[1345]ipcop/trunk/lfs/binary-firmware-all


> On Wednesday 30 April 2008, ges...@us... wrote:
> > Revision: 1345
> >           http://ipcop.svn.sourceforge.net/ipcop/?rev=1345&view=rev
> > Author:   gespinasse
> > Date:     2008-04-30 10:33:52 -0700 (Wed, 30 Apr 2008)
> >
> > Log Message:
> > -----------
> > That's not supportable to break everyone build everytime the md5 change
> > I will change that soon if one does not that before.
> >
> > Actually, you have to erase manually cache/ql24*.bin cache/ql25*.bin to
be
> > able to build again
>
> Gilles,
>
> I agree.  Maybe we can disable md5sum checking for this one package?
>
Why don't we do like in 1.4?
We could silently upload a new if the new md5 has been commited by a
developper?

I understand it is not made the prettiest way but I don't know others.

I don't know how  we could disable md5 on 2.0, I have not look.
Probably we need a special case in prefetch and in chroot_make function.

Gilles

On Wednesday 30 April 2008, ges...@us... wrote:
> Revision: 1345
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=1345&view=rev
> Author:   gespinasse
> Date:     2008-04-30 10:33:52 -0700 (Wed, 30 Apr 2008)
>
> Log Message:
> -----------
> That's not supportable to break everyone build everytime the md5 change
> I will change that soon if one does not that before.
>
> Actually, you have to erase manually cache/ql24*.bin cache/ql25*.bin to be
> able to build again

Gilles,

I agree.  Maybe we can disable md5sum checking for this one package?

IvanK.

----- Original Message ----- 
From: "John Edwards" <jo...@co...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Wednesday, April 30, 2008 2:31 AM
Subject: Re: [IPCop-devel] C libraries broken on Pentiums (i586)


> On Wed, Apr 30, 2008 at 02:10:09AM +0200, Gilles Espinasse wrote:
> >> Hi
> >> Just finished building IPCop with both --host and --build set to
> >> "i486-pc-linux-gnu".
> >>
> >> This now boots to the installer on i586 Pentium CPUs using PXE.
> >
> > fine
>
> >> I will leave it to the C programmers on the development team to
> >> produce a good patch as mine was hardcoded in the LFS file and
> >> it too late at night for me to write a good one.
> >>
I am not ready to commit, this will be next week, once I figure a way to do
that properly for all arch.
One of the way could be to change ppc to powerpc in make.sh and lfs scripts.
This could help a lot, we could use simply $(MACHINE)-<foo>-linux-gnu in
glibc for
 --build and --host

Gilles

On Wed, Apr 30, 2008 at 02:10:09AM +0200, Gilles Espinasse wrote:
>> Hi
>> Just finished building IPCop with both --host and --build set to
>> "i486-pc-linux-gnu".
>> 
>> This now boots to the installer on i586 Pentium CPUs using PXE.
>
> fine

>> I will leave it to the C programmers on the development team to
>> produce a good patch as mine was hardcoded in the LFS file and
>> it too late at night for me to write a good one.
>> 
>> Please read the INSTALL file in glibc source code for more details.
> 
> Anyway, could you send me your diff.
> That's always easier to check changes.

Attached, but do not apply.

The extra parameters need to be moved into the i486 only section.

I again repeat you should read the glibc INSTALL file to understand
what this does, because it is possible that you only need to use the
"--host" option. I will forward any results of the glibc discussion on
GLLUG about this.

You may also need to do something similar for SPARC and PowerPC,
depending on what the minumium spec and typical build machine is for
those systems. But beware the speed issues with compiling code for
early 32 bit SPARCs that lack higher maths functions.

Good night.


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

----- Original Message ----- 
From: "John Edwards" <jo...@co...>
To: "Gilles Espinasse" <g....@fr...>; <ipc...@li...>
Sent: Wednesday, April 30, 2008 2:05 AM
Subject: Re: [IPCop-devel] C libraries broken on Pentiums (i586)


...
> Hi
> Just finished building IPCop with both --host and --build set to
> "i486-pc-linux-gnu".
> 
> This now boots to the installer on i586 Pentium CPUs using PXE.
> 
fine

> I will leave it to the C programmers on the development team to
> produce a good patch as mine was hardcoded in the LFS file and
> it too late at night for me to write a good one.
> 
> Please read the INSTALL file in glibc source code for more details.
> 
Anyway, could you send me your diff.
That's always easier to check changes.

Gilles

On Tue, Apr 29, 2008 at 11:58:29PM +0100, John Edwards wrote:
<snip>
>>>> Of course the problem might be with my build machine, but there is the
>>>> possibility that the C libraries were are building have some i686
>>>> specific code somewhere. If so we need to find it and remove it,
>>>> otherwise we will never get a working release.
>>>>
>>>> This probably means dealing with the way we build glibc, and so I am
>>>> at the limit of knowledge and someone else needs to deal with this.
>>>>
>>>> If we can't fix this then I think we have to think about whether we
>>>> continue building and maintaining our own C libraries.
>>>
>>> I've tested rebuilding IPCop on i686 but adding
>>> "--host=i486-pc-linux-gnu" to the glibc configure options.
>>
>> We may need to use the way CLFS build.
> 
> If you are talking about using --host and --build like this:
>   http://cross-lfs.org/files/BOOK/1.0.0/CLFS-1.0.0-x86.html#ch-cross-tools-glibc
> then that it what I am trying to do.
> 
> 
>> Our way to build for a different machine than the building machine has work on
>> gcc-3.3/glibc-2.3 but may be broken on gcc-4.2.3/glib-2.7
> 
> That is a major version change in gcc and 4 minor version changes in
> glibc. Very big changes that are likely to break things. The move to
> glibc 2.7 was done in revision 1152:
>   http://ipcop.svn.sourceforge.net/viewvc/ipcop?view=rev&revision=1152
> 
> It does not give much detail on why this was changed or what it was
> tested on.
> 
> 
>>> This has not changed anything. On a Pentium the binaries can
>>> run with the Debian C libraries, but fail with the IPCop ones.
>>
>> Thank for your effort.
> 
> Following discussion on building glibc on the GLLUG mailing list I am
> also trying "--build=i486-pc-linux-gnu". There is some disagreement on
> whether this is prefered to --host so I am trying both.
> 
> It was also mentioned that we should not try to target glibc for CPUs
> by using CFLAGS. To quote "ni...@es...":
> 
> "You can't configure a glibc for specific targets (even specific CPU
> submodels like i586) by just setting CFLAGS."
> 
> Who then goes on to talk about the --build and --host options.

Hi
Just finished building IPCop with both --host and --build set to
"i486-pc-linux-gnu".

This now boots to the installer on i586 Pentium CPUs using PXE.

I will leave it to the C programmers on the development team to
produce a good patch as mine was hardcoded in the LFS file and
it too late at night for me to write a good one.

Please read the INSTALL file in glibc source code for more details.


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

On Mon, Apr 28, 2008 at 12:36:25PM +0200, Gilles Espinasse wrote:
> Selon John Edwards <jo...@co...>:
>> On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
>> <snip>
>>> Discussions on the GLLUG mailing list about IPCop not booting on
>>> Pentium (i586) CPUs has lead to me finding that many (possibly all)
>>> binaries built in recent SVN revision *DO NOT WORK* on Pentium CPUs.
>>> When you run them in a chroot you just get "Illegal instruction".
>>>
>>> This even effects dynamically compiled programs from other Linux
>>> distribution, but not statically compiled program (eg a statically
>>> compiled version of busybox).
>>>
>>> It looks like our C libraries are *BROKEN* on Pentium CPUs.
>
> First we may/should run the test suite under gcc glibc and check if it match the
> results reported by LFS.
> Under glibc (see
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html )
> 
> add something like
> make -k check 2>&1 >${TARGET}-check-log
> and grep for Error
> 
> Under binutils
> make check
> 
> Under gcc
> make -k check
> 
> To receive a summary of gcc test suite results, run:
> ../gcc-4.2.3/contrib/test_summary
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html

I am assuming that you are going to do this.

Also I do not see the link between running checks on the build system
(which is i686 and so probably work) and glibc failing when binaries
are run on i586.


>>> Of course the problem might be with my build machine, but there is the
>>> possibility that the C libraries were are building have some i686
>>> specific code somewhere. If so we need to find it and remove it,
>>> otherwise we will never get a working release.
>>>
>>> This probably means dealing with the way we build glibc, and so I am
>>> at the limit of knowledge and someone else needs to deal with this.
>>>
>>> If we can't fix this then I think we have to think about whether we
>>> continue building and maintaining our own C libraries.
>>
>> I've tested rebuilding IPCop on i686 but adding
>> "--host=i486-pc-linux-gnu" to the glibc configure options.
>
> We may need to use the way CLFS build.

If you are talking about using --host and --build like this:
  http://cross-lfs.org/files/BOOK/1.0.0/CLFS-1.0.0-x86.html#ch-cross-tools-glibc
then that it what I am trying to do.


> Our way to build for a different machine than the building machine has work on
> gcc-3.3/glibc-2.3 but may be broken on gcc-4.2.3/glib-2.7

That is a major version change in gcc and 4 minor version changes in
glibc. Very big changes that are likely to break things. The move to
glibc 2.7 was done in revision 1152:
  http://ipcop.svn.sourceforge.net/viewvc/ipcop?view=rev&revision=1152

It does not give much detail on why this was changed or what it was
tested on.


>> This has not changed anything. On a Pentium the binaries can
>> run with the Debian C libraries, but fail with the IPCop ones.
>
> Thank for your effort.

Following discussion on building glibc on the GLLUG mailing list I am
also trying "--build=i486-pc-linux-gnu". There is some disagreement on
whether this is prefered to --host so I am trying both.

It was also mentioned that we should not try to target glibc for CPUs
by using CFLAGS. To quote "ni...@es...":

"You can't configure a glibc for specific targets (even specific CPU
submodels like i586) by just setting CFLAGS."

Who then goes on to talk about the --build and --host options.


Also do you know that the toolchain is built for i686?
----------------------------------------------------------------------
Mar  5 22:25:52: Building glibc
glibc-2.7.tar.bz2 checksum OK
glibc-libidn-2.7.tar.gz checksum OK
====================================== Installing glibc-2.7 ...
#cd /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/glibc-2.7 && patch -Np1 -i /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/src/patches/glibc-2.7_hwcap_mask.patch
#cd /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/glibc-2.7 && patch -Np1 -i /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/src/patches/glibc-2.7_ioperm_fix-1_alpha.patch
#cd /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/glibc-2.7 && patch -Np1 -i /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/src/patches/glibc-2.7_sigsuspend_alpha.patch
cd /home/john/build/ipcop/ipcop-2.0-svn/trunk-r1169/build_i486/ipcop/usr/src/glibc-build && CFLAGS="-O2 -mno-tls-direct-seg-refs -march=i486" ../glibc-2.7/configure    --prefix=/tools_i486 \
                                                                                --disable-profile \
                                                                                --enable-add-ons \
                                                                                --enable-kernel=2.6.5 \
                                                                                --with-binutils=/tools_i486/bin \
                                                                                --without-gd \
                                                                                --with-headers=/tools_i486/include \
                                                                                --without-selinux
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
----------------------------------------------------------------------

I think this may mean that we can not build on i586, which would be a
good test but obviously very slow.


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

----- Original Message ----- 
From: "John Edwards" <jo...@co...>
To: <ipc...@li...>
Sent: Wednesday, April 30, 2008 12:26 AM
Subject: Re: [IPCop-devel] Anyone booted IPCop 2.0 on a Pentium I or 486?


> On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
> > Hi
> >
> > Has anyone every successfully booted IPCop 1.5 or 2.0 on a Pentium or
> > lower CPU?  That is an Intel 486, 586 (Pentium I), AMD K5, AMD K6,
> > Cyrix 6x86.
> >
> > If anyone has then please email me the CVS/SVN revision number if you
> > can remember it, or rough date if you can't, and details of the CPU,
> > RAM and motherboard.
> <snip>
>
> Just to let everyone know that I have received no emails. I can
> only assume that IPCop 1.5 or 2.0 has never been tested on i586
> or i486, and so we have no known good build to work from.
>
>
I am working on implementing the test for glibc, binutils and gcc.
For glibc, I had a few errors

gesp@amd64-64:~/ipcop/1.svn$ grep Error log*/glibc-2.7*
make[3]: *** [/usr/src/glibc-build/math/test-double.out] Error 1
make[2]: *** [math/tests] Error 2
make[3]: *** [/usr/src/glibc-build/dlfcn/bug-atexit3.out] Error 1
make[2]: *** [dlfcn/tests] Error 2
make[3]: *** [/usr/src/glibc-build/posix/tst-vfork3.out] Error 1
make[3]: [/usr/src/glibc-build/posix/annexc.out] Error 1 (ignored)
make[2]: *** [posix/tests] Error 2
make[3]: *** [/usr/src/glibc-build/nptl/tst-cancel24.out] Error 127
make[2]: *** [nptl/tests] Error 2
make[3]: *** [/usr/src/glibc-build/debug/tst-chk4.out] Error 127
make[3]: *** [/usr/src/glibc-build/debug/tst-chk5.out] Error 127
make[3]: *** [/usr/src/glibc-build/debug/tst-chk6.out] Error 127
make[3]: *** [/usr/src/glibc-build/debug/tst-lfschk4.out] Error 127
make[3]: *** [/usr/src/glibc-build/debug/tst-lfschk5.out] Error 127
make[3]: *** [/usr/src/glibc-build/debug/tst-lfschk6.out] Error 127
make[2]: *** [debug/tests] Error 2
make[1]: *** [check] Error 2

test-double.out is a know gcc bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088

I don't know for other errors.
Some could later related to the next lines

For binutils, there is no error but there is a repeted warning.
WARNING: could not find `runtest'

For gcc, I have failed to run the test_summary after make -k check

The reason of the warning and gcc tests not running is that we have not
installed
tcl
expect
dejagnu

Those packages are needed to be able to pass binutils and gcc tests.

I should commit the tests tomorrow.
Test line will stay commented by default.

I will too test installation tomorrow on some machines.

Gilles

On Tue, Apr 29, 2008 at 06:32:53PM -0400, Ivan Kabaivanov wrote:
> On Tuesday 29 April 2008, John Edwards wrote:
> > On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
> > > Hi
> > >
> > > Has anyone every successfully booted IPCop 1.5 or 2.0 on a Pentium or
> > > lower CPU?  That is an Intel 486, 586 (Pentium I), AMD K5, AMD K6,
> > > Cyrix 6x86.
> > >
> > > If anyone has then please email me the CVS/SVN revision number if you
> > > can remember it, or rough date if you can't, and details of the CPU,
> > > RAM and motherboard.
> >
> > <snip>
> >
> > Just to let everyone know that I have received no emails. I can
> > only assume that IPCop 1.5 or 2.0 has never been tested on i586
> > or i486, and so we have no known good build to work from.
> 
> 
> John,
> 
> sorry for not responding, I'm quite busy these days, more on that in a later 
> email. 

Same here - very busy for the next month. Which is why I am trying to
wrap this up quickly and possibly with less than perfect politeness.


> Speaking strictly for myself, I have an old original pentium (586) 
> board, but can't remember what happened the last time I tried 2.0.
> I won't  be able to test that for at least two more months :-(

I was looking for a know good.

One possible test point could be the last revision that used
glibc 2.5 or 2.5.1 and built cleanly. 


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

On Tuesday 29 April 2008, John Edwards wrote:
> On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
> > Hi
> >
> > Has anyone every successfully booted IPCop 1.5 or 2.0 on a Pentium or
> > lower CPU?  That is an Intel 486, 586 (Pentium I), AMD K5, AMD K6,
> > Cyrix 6x86.
> >
> > If anyone has then please email me the CVS/SVN revision number if you
> > can remember it, or rough date if you can't, and details of the CPU,
> > RAM and motherboard.
>
> <snip>
>
> Just to let everyone know that I have received no emails. I can
> only assume that IPCop 1.5 or 2.0 has never been tested on i586
> or i486, and so we have no known good build to work from.


John,

sorry for not responding, I'm quite busy these days, more on that in a later 
email.  Speaking strictly for myself, I have an old original pentium (586) 
board, but can't remember what happened the last time I tried 2.0.  I won't 
be able to test that for at least two more months :-(

IvanK.

On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
> Hi
> 
> Has anyone every successfully booted IPCop 1.5 or 2.0 on a Pentium or
> lower CPU?  That is an Intel 486, 586 (Pentium I), AMD K5, AMD K6,
> Cyrix 6x86.
> 
> If anyone has then please email me the CVS/SVN revision number if you
> can remember it, or rough date if you can't, and details of the CPU,
> RAM and motherboard.
<snip>

Just to let everyone know that I have received no emails. I can
only assume that IPCop 1.5 or 2.0 has never been tested on i586
or i486, and so we have no known good build to work from.


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

Feature Requests item #1954110, was opened at 2008-04-29 12:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1954110&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: None
Status: Open
Priority: 5
Private: No
Submitted By: David Hodgson (jetojedno)
Assigned to: Nobody/Anonymous (nobody)
Summary: DHCP for MACs with fixed leases

Initial Comment:
DHCPD will give out a requested address to a device although it has a fixed lease assigned.  This (in my view) is wrong.  IPCop should only give out the defined fixed lease and reject all other requests.

I have a 3com WLAN device which remembers the IP address it initially had and keeps asking for it.  IPCop is "agreeing" despite the device having a fixed lease defined.  This is making accessing the device a bit difficult as it's address is in an unexpected range.

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

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

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

> On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
> <snip>
> > Discussions on the GLLUG mailing list about IPCop not booting on
> > Pentium (i586) CPUs has lead to me finding that many (possibly all)
> > binaries built in recent SVN revision *DO NOT WORK* on Pentium CPUs.
> > When you run them in a chroot you just get "Illegal instruction".
> >
> > This even effects dynamically compiled programs from other Linux
> > distribution, but not statically compiled program (eg a statically
> > compiled version of busybox).
> >
> > It looks like our C libraries are *BROKEN* on Pentium CPUs.
> >
First we may/should run the test suite under gcc glibc and check if it match the
results reported by LFS.
Under glibc (see
http://www.linuxfromscratch.org/lfs/view/development/chapter06/glibc.html )

add something like
make -k check 2>&1 >${TARGET}-check-log
and grep for Error

Under binutils
make check

Under gcc
make -k check

To receive a summary of gcc test suite results, run:
../gcc-4.2.3/contrib/test_summary
http://www.linuxfromscratch.org/lfs/view/development/chapter06/gcc.html

> >
> > Of course the problem might be with my build machine, but there is the
> > possibility that the C libraries were are building have some i686
> > specific code somewhere. If so we need to find it and remove it,
> > otherwise we will never get a working release.
> >
> > This probably means dealing with the way we build glibc, and so I am
> > at the limit of knowledge and someone else needs to deal with this.
> >
> > If we can't fix this then I think we have to think about whether we
> > continue building and maintaining our own C libraries.
>
> I've tested rebuilding IPCop on i686 but adding
> "--host=i486-pc-linux-gnu" to the glibc configure options.
>
We may need to use the way CLFS build.
Our way to build for a different machine than the building machine has work on
gcc-3.3/glibc-2.3 but may be broken on gcc-4.2.3/glib-2.7

> This has not changed anything. On a Pentium the binaries can
> run with the Debian C libraries, but fail with the IPCop ones.
>
>
Thank for your effort.


Gilles

On Sun, Apr 27, 2008 at 04:01:48PM +0100, John Edwards wrote:
<snip> 
> Discussions on the GLLUG mailing list about IPCop not booting on
> Pentium (i586) CPUs has lead to me finding that many (possibly all)
> binaries built in recent SVN revision *DO NOT WORK* on Pentium CPUs.
> When you run them in a chroot you just get "Illegal instruction".
> 
> This even effects dynamically compiled programs from other Linux
> distribution, but not statically compiled program (eg a statically
> compiled version of busybox).
> 
> It looks like our C libraries are *BROKEN* on Pentium CPUs.
> 
> 
> Of course the problem might be with my build machine, but there is the
> possibility that the C libraries were are building have some i686
> specific code somewhere. If so we need to find it and remove it,
> otherwise we will never get a working release.
> 
> This probably means dealing with the way we build glibc, and so I am
> at the limit of knowledge and someone else needs to deal with this.
> 
> If we can't fix this then I think we have to think about whether we
> continue building and maintaining our own C libraries.

I've tested rebuilding IPCop on i686 but adding
"--host=i486-pc-linux-gnu" to the glibc configure options.

This has not changed anything. On a Pentium the binaries can
run with the Debian C libraries, but fail with the IPCop ones.

I can't run the normal debugging tools such as gdb and strace
in a chroot, because they also fail. Unless anyone knows if it
is possible to get statically built version of those tools.

Otherwise I am out of ideas and someone else will have to take over.


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

>  That's only the usual vdso trouble fixable by one of the three methods :
>  - recompile the kernel using COMPAT_VDSO=y (in Processor type and features,
>  Compat VDSO support)
>  - pass an option to the kernel on boot (add vdso=0 to the grub or lilo
>  kernel line)
>  - disable compat vdso directly with echo 0 > /proc/sys/vm/vdso_enabled
>
>  The last is easier, it may hang on 2.6.20 and maybe later kernel, that
>  should be fixed on more recent kernel.
>
>  Gilles

Merci Gilles

Vous êtes L'homme

Option 3 worked for me.

Eric

Gilles Espinasse wrote:
> Update of /cvsroot/ipcop/ipcop/lfs
> In directory sc8-pr-cvs2.sourceforge.net:/tmp/cvs-serv31832/lfs
> 
> Modified Files:
>       Tag: IPCOP_v1_4_0
> 	cdrom 
> Log Message:
> Prefer a Makefile condition than a bash test and every instruction in one line.
> 
> This is superior because Makefile stop on error on the last instruction executed
> So when everything is in one bash line, errors happening are not detected when
> the last command is a success.
> 
> Nothing is changed here but the test and indentation


For those cases when we have to use shell commands we should use '&&' 
instead of ';' .  This should catch all errors.

IvanK.


> 
> 
> Index: cdrom
> ===================================================================
> RCS file: /cvsroot/ipcop/ipcop/lfs/cdrom,v
> retrieving revision 1.1.2.50
> retrieving revision 1.1.2.51
> diff -C2 -d -r1.1.2.50 -r1.1.2.51
> *** cdrom	18 Apr 2008 21:21:41 -0000	1.1.2.50
> --- cdrom	27 Apr 2008 22:56:30 -0000	1.1.2.51
> ***************
> *** 134,161 ****
>   
>   	# make the CDROM iso
> ! 	if [ "$(MACHINE)" == "i386" ]; then \
> ! 		mkdir -p /install/cdrom/boot/isolinux; \
> ! 		dd if=/dev/zero  bs=1k count=2            > /install/cdrom/boot/isolinux/boot.catalog; \
> ! 		cp /install/images/cdinitrd.gz              /install/cdrom/boot/isolinux/instroot.gz; \
> ! 		cp /boot/vmlinuz-installer                    /install/cdrom/boot/isolinux/vmlinuz; \
> ! 		cp $(DIR_SRC)/config/kernel/syslinux.cfg    /install/cdrom/boot/isolinux/isolinux.cfg; \
> ! 		cp /usr/lib/syslinux/isolinux.bin           /install/cdrom/boot/isolinux/isolinux.bin; \
> ! 		gunzip -c $(DIR_DL)/memtest86+-1.65.bin.gz > /install/cdrom/boot/isolinux/memtest; \
> ! 		cp $(DIR_SRC)/config/kernel/f*\.txt /install/cdrom/boot/isolinux/; \
> ! 		sed -e 's/boot IPCop/boot IPCop $(VERSION)/' $(DIR_SRC)/config/kernel/f1.txt \
> ! 			> /install/cdrom/boot/isolinux/f1.txt; \
> ! 		cd /install/cdrom && mkisofs -J -r -V "$(NAME)-$(VERSION) $(MACHINE)" -publisher "The IPCop Team" \
>   			-b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table \
>   			-c boot/isolinux/boot.catalog \
> ! 			. > /install/images/$(SNAME)-$(VERSION)-install-cd.$(MACHINE).iso; \
> ! 	elif [ "$(MACHINE)" == "alpha" ]; then \
> ! 		mkdir -p /install/cdrom/etc; \
> ! 		cp /boot/vmlinuz-$(KVER) /install/cdrom/vmlinuz; \
> ! 		cp /install/images/cdinitrd.gz  /install/cdrom/instroot.gz; \
> ! 		cp /boot/bootlx /install/cdrom; \
> ! 		cp $(DIR_SRC)/config/kernel/aboot.conf /install/cdrom/etc/aboot.conf; \
> ! 		cd /install/cdrom && mkisofs -J -r -V "$(NAME)-$(VERSION) $(MACHINE)" -publisher "The IPCop Team" \
> ! 			. > /install/images/$(SNAME)-$(VERSION)-install-cd.$(MACHINE).iso; \
> ! 		isomarkboot /install/images/$(SNAME)-$(VERSION)-install-cd.$(MACHINE).iso bootlx; \
> ! 	fi
>   	rm -rf $$LFS/tmp/*
> --- 134,163 ----
>   
>   	# make the CDROM iso
> ! ifeq "$(MACHINE)" "i386"
> ! 	mkdir -p /install/cdrom/boot/isolinux
> ! 	dd if=/dev/zero  bs=1k count=2		>	/install/cdrom/boot/isolinux/boot.catalog
> ! 	cp /install/images/cdinitrd.gz			/install/cdrom/boot/isolinux/instroot.gz
> ! 	cp /boot/vmlinuz-installer			/install/cdrom/boot/isolinux/vmlinuz
> ! 	cp $(DIR_SRC)/config/kernel/syslinux.cfg	/install/cdrom/boot/isolinux/isolinux.cfg
> ! 	cp /usr/lib/syslinux/isolinux.bin		/install/cdrom/boot/isolinux/isolinux.bin
> ! 	gunzip -c $(DIR_DL)/memtest86+-1.65.bin.gz >	/install/cdrom/boot/isolinux/memtest
> ! 	cp $(DIR_SRC)/config/kernel/f*\.txt		/install/cdrom/boot/isolinux/
> ! 	sed -e 's/boot IPCop/boot IPCop $(VERSION)/' $(DIR_SRC)/config/kernel/f1.txt \
> ! 			> /install/cdrom/boot/isolinux/f1.txt
> ! 	cd /install/cdrom && mkisofs -J -r -V "$(NAME)-$(VERSION) $(MACHINE)" -publisher "The IPCop Team" \
>   			-b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table \
>   			-c boot/isolinux/boot.catalog \
> ! 			. > /install/images/$(SNAME)-$(VERSION)-install-cd.$(MACHINE).iso
> ! endif
> ! ifeq "$(MACHINE)" "alpha"
> ! 	mkdir -p /install/cdrom/etc
> ! 	cp /boot/vmlinuz-$(KVER)			/install/cdrom/vmlinuz
> ! 	cp /install/images/cdinitrd.gz			/install/cdrom/instroot.gz
> ! 	cp /boot/bootlx					/install/cdrom
> ! 	cp $(DIR_SRC)/config/kernel/aboot.conf		/install/cdrom/etc/aboot.conf
> ! 	cd /install/cdrom && mkisofs -J -r -V "$(NAME)-$(VERSION) $(MACHINE)" -publisher "The IPCop Team" \
> ! 			. > /install/images/$(SNAME)-$(VERSION)-install-cd.$(MACHINE).iso
> ! 	isomarkboot /install/images/$(SNAME)-$(VERSION)-install-cd.$(MACHINE).iso bootlx
> ! endif
> ! 
>   	rm -rf $$LFS/tmp/*
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> IPCop-cvs mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-cvs

On Sun, Apr 27, 2008 at 04:28:12PM +0200, Gilles Espinasse wrote:
<snip>
> > So this confirms that we have built a version of busybox that does
> > not work on Pentiums. Please can a C programmer have a look at this.
> >
> > If not then the only option I can see is to dump the current
> > initramfs system and move to something that works, such as
> > Debian's initramfs-tools.
> >
> 
> Could you test using debian version + debian patches so we could know if it
> is or not a compilation bug (compiler, glibc or anything else) on our side.

I have already done that and emailed the results to the list.
The static version of busybox from Debian works.


> If debian version compiled in our environment work, that may be a bug in
> busybox-1.10.1.
> You may try to downgrading busybox until it work again.
> 
> Then you could report your investigation on busybox mailing list.

Problem looks to be bigger, probably C libraries. See my last email.

The reason why it appears to be busybox is that is the first userspace
program that is run during the install. If it don't run we can't test
anything else.

I now suspect that no one has managed to install a recent SVN version
on a Pentium CPU because of this bug.


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

Hi

Has anyone every successfully booted IPCop 1.5 or 2.0 on a Pentium or
lower CPU?  That is an Intel 486, 586 (Pentium I), AMD K5, AMD K6,
Cyrix 6x86.

If anyone has then please email me the CVS/SVN revision number if you
can remember it, or rough date if you can't, and details of the CPU,
RAM and motherboard.


REASON:

Discussions on the GLLUG mailing list about IPCop not booting on
Pentium (i586) CPUs has lead to me finding that many (possibly all)
binaries built in recent SVN revision *DO NOT WORK* on Pentium CPUs.
When you run them in a chroot you just get "Illegal instruction".

This even effects dynamically compiled programs from other Linux
distribution, but not statically compiled program (eg a statically
compiled version of busybox).

It looks like our C libraries are *BROKEN* on Pentium CPUs.


Of course the problem might be with my build machine, but there is the
possibility that the C libraries were are building have some i686
specific code somewhere. If so we need to find it and remove it,
otherwise we will never get a working release.

This probably means dealing with the way we build glibc, and so I am
at the limit of knowledge and someone else needs to deal with this.

If we can't fix this then I think we have to think about whether we
continue building and maintaining our own C libraries.


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

----- Original Message ----- 
From: "John Edwards" <jo...@co...>
To: <ipc...@li...>
Sent: Sunday, April 27, 2008 3:25 PM
Subject: Re: [IPCop-devel] Pentium problem is caused by busybox


> Hi
> For reasons below I think this needs someone with a knowledge of
> debugging C to fix it. And that is not me.
>
..
>
> So this confirms that we have built a version of busybox that does
> not work on Pentiums. Please can a C programmer have a look at this.
>
> If not then the only option I can see is to dump the current
> initramfs system and move to something that works, such as
> Debian's initramfs-tools.
>

Could you test using debian version + debian patches so we could know if it
is or not a compilation bug (compiler, glibc or anything else) on our side.

If debian version compiled in our environment work, that may be a bug in
busybox-1.10.1.
You may try to downgrading busybox until it work again.

Then you could report your investigation on busybox mailing list.

Gilles

----- Original Message ----- 
From: "Eric Oberlander" <eri...@gm...>
To: "Gilles Espinasse" <g....@fr...>; "IPCop devel"
<ipc...@li...>
Sent: Sunday, April 27, 2008 3:49 PM
Subject: Building v1.4 on Ubuntu 8.04


> Hi Gilles
>
> I just upgraded my Ubuntu 6.06 box to 8.04, and I can no longer build v1.4
:(
>
> Using the prebuilt toolchain, it fails at the start of Stage 2 with
> this error message in the build log:
>
> Apr 27 13:42:53: Stage2 linux base build
> Apr 27 13:42:53: Building stage2
> Inconsistency detected by ld.so: rtld.c: 1221: dl_main: Assertion
> `pt_load_num || (void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso'
> failed!
>
> Hope this is of some help.
>
That's only the usual vdso trouble fixable by one of the three methods :
- recompile the kernel using COMPAT_VDSO=y (in Processor type and features,
Compat VDSO support)
- pass an option to the kernel on boot (add vdso=0 to the grub or lilo
kernel line)
- disable compat vdso directly with echo 0 > /proc/sys/vm/vdso_enabled

The last is easier, it may hang on 2.6.20 and maybe later kernel, that
should be fixed on more recent kernel.

Gilles
Gilles

Hi Gilles

I just upgraded my Ubuntu 6.06 box to 8.04, and I can no longer build v1.4 :(

Using the prebuilt toolchain, it fails at the start of Stage 2 with
this error message in the build log:

Apr 27 13:42:53: Stage2 linux base build
Apr 27 13:42:53: Building stage2
Inconsistency detected by ld.so: rtld.c: 1221: dl_main: Assertion
`pt_load_num || (void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso'
failed!

Hope this is of some help.

Cheers

Eric

Hi
For reasons below I think this needs someone with a knowledge of
debugging C to fix it. And that is not me.


On Sat, Apr 26, 2008 at 09:20:33PM +0100, John Edwards wrote:
> <snip IPCop not booting on Pentium CPUs> 
> 
> So I think that the problem is with our version of busybox. Either
> how we configure it or how we compile it, I am not sure.

With the help of some members of the GLLUG mailing list I've found an
easier way of testing this. This is to unpacked using:
    gzcat <file> | cpio -idmu
and then run programs in the chroot.

On Pentium (i586) machine:
----------------------------------------------------------------------
$ sudo chroot ipcop-1.9.1_trunk-r1332+busybox-static_instroot+hello /bin/busybox
Illegal instruction
$ sudo chroot ipcop-1.9.1_trunk-r1332+busybox-static_instroot+hello /bin/hello
Hello world!
----------------------------------------------------------------------
where /bin/hello is the previously mentioned "Hello world" C program.
On a Pentium II or above (i686) both work.

This confirms what I tested yesterday with 'rdinit=/bin/hello'.

With a statically compiled version of busybox we do not even need to
chroot for the libraries:
----------------------------------------------------------------------
$ ./ipcop-1.9.1_trunk-r1332+busybox-static_instroot+hello/bin/busybox
Illegal instruction
----------------------------------------------------------------------


Here is the tail end of strace run on the above static busybox:
----------------------------------------------------------------------
execve("./ipcop-1.9.1_trunk-r1332+busybox-static_instroot+hello/bin/busybox", ["./ipcop-1.9.1_trunk-r1332+busybo"...], [/* 20 vars */]) = 0
uname({sys="Linux", node="marathon.local.cornerstonelinux.co.uk", ...}) = 0
brk(0)                                  = 0x8126000
brk(0x8126cd0)                          = 0x8126cd0
set_thread_area({entry_number:-1 -> 6, base_addr:0x8126850, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
brk(0x8147cd0)                          = 0x8147cd0
brk(0x8148000)                          = 0x8148000
getpid()                                = 6409
--- SIGILL (Illegal instruction) @ 0 (0) ---
+++ killed by SIGILL +++
Process 6409 detached
----------------------------------------------------------------------


The equivalent section of strace when I run the static Debian of
busybox is:
----------------------------------------------------------------------
execve("/bin/busybox-static", ["/bin/busybox-static"], [/* 21 vars */]) = 0
uname({sys="Linux", node="marathon.local.cornerstonelinux.co.uk", ...}) = 0
brk(0)                                  = 0x83c5000
brk(0x83c5cd0)                          = 0x83c5cd0
set_thread_area({entry_number:-1 -> 6, base_addr:0x83c5850, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
brk(0x83e6cd0)                          = 0x83e6cd0
brk(0x83e7000)                          = 0x83e7000
stat64("/etc/busybox.conf", 0xbf8a2048) = -1 ENOENT (No such file or directory)
ioctl(0, TIOCGWINSZ, {ws_row=40, ws_col=121, ws_xpixel=0, ws_ypixel=0}) = 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fed000
write(1, "BusyBox v1.1.3 (Debian 1:1.1.3-5"..., 1806BusyBox v1.1.3 (Debian 1:1.1.3-5) multi-call binary
----------------------------------------------------------------------
and it then prints the help instructions and exits.


So this confirms that we have built a version of busybox that does
not work on Pentiums. Please can a C programmer have a look at this.

If not then the only option I can see is to dump the current
initramfs system and move to something that works, such as
Debian's initramfs-tools.


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

On Wed, Apr 23, 2008 at 08:09:05PM +0100, John Edwards wrote:
<snip IPCop not booting on Pentium CPUs> 
> I think we can safely say that this is a problem when the initramfs
> is either loaded or accessed.

I've run some more tests with a basic "hello world" program statically
compiled, as suggested in the Linux kernel ramfs-rootfs-initramfs.txt:
----------------------------------------------------------------
#include <stdio.h> #include <unistd.h>

int main(int argc, char *argv[])
{
  printf("Hello world!\n");
  sleep(999999999);
}
----------------------------------------------------------------

The first test was an initramfs with only this file as init. That
booted as print "Hello world!" and then stopped as expected. So the
kernel can load and run an initramfs.

The second test was including this binary in the normal initramfs and
then using "rdinit=/bin/hello" to get the kernel to run this instead
of the normal init script. This also printed "Hello world!" and
stopped. So the kernel can load and run our initramfs.

I also ran a rebuild of r1332 with busybox converted to statically
compiled. But this did not change anything the machine failed to
boot. So the problem is not with dynamic/static compiling.

The last test was using Debian's statically compiled busybox. This
boots, runs the init script, and runs the installer but with a whole
bunch of errors about missing features.

So I think that the problem is with our version of busybox. Either
how we configure it or how we compile it, I am not sure.


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