ipcop-devel Mailing List for IPCop Firewall

There is actually a bug on restore from install as /etc/domainname and
/etc/hostname are only set with default values.

On rc.sysinit, /bin/hostname -F /etc/hostname is run and the wrong
ipcop.localdomain is used instead of the values from
/var/ipcop/main/settings.

I think the wisest solution would be to revert to 1.4 behavior :
- suppress etc/{hostname,domainname} files and use in rc.sysinit the 1.4
code
echo "Setting hostname"
if [ -z "$DOMAINNAME" ]; then
    /bin/hostname $HOSTNAME
else
    /bin/hostname ${HOSTNAME}.${DOMAINNAME}
fi

This solution look better because if you write any of
etc/{hostname,domainname} manually, the behavior will be inconsistent with
the value from /var/ipcop, so we really should not have them.

The alternative is to stop writing hostname,domainname into /var/ipcop but
this will require some more changes and I doubt there is added value, only
more works needed.

Gilles

Gilles Espinasse wrote:

> Still the issue on halt without and with acpi=off on ipcop 2.6.25 and debian
> 2.6.26
> Still '/dev is busy'.

Yes.  I think the problem is our umount -a.
If I look at Debian shutdown I see they parse all mounted devices first 
and then umount selectively (for example no umount for dev, shm etc.)

Not sure if that is worth the trouble for us.


> There is a problem on restore from floppy.
> 70-persistent-net.rules is not include in backup (and maybe that's wise).
> But our COLOR_1_DEV eth value no more match the pseudo-random interface
> number given by udev. So network is unsuable. What should we do on restore?
> 
> First, should we not save the MAC instead of a network interface name on
> backup?
> That may require some works as grep -r 1_DEV src match a lot.
> But that allow to check on restore if all ethernet interfaces are unchanged.
> 
> Probably saving both MAC and an interface name on
> /var/ipcop/ethernet/settings allow an easier transition.

I think so too. OTOH I think we can also include 70-persistent-net in 
backup.
Doing backup/restore across differing HW is always problematic. Using 
persistent net at least restores the network cards that are present in 
the restored machine correctly.


> Could be the best solution be to generate a persistent rule directly for
> green1/blue1/orange1 names with corresponding MAC?
> Would be cool to be able to ifconfig green1 without the need to know what
> was the order in wich drivers has been loaded.

Yes. I have tested this (and already made some changes some days ago) so 
we can use green, green1, green_1 (not green-1 though) or also lan1, 
wlan1, etc.  Combined with the colored netstatus.cgi, and other .cgi 
this looks extremely good if you ask me.
I have not found an easy way to manipulate rules yet, but I definitively 
  want to include interface naming like that.

Just doing ifconfig green1, ethtool green1 or even tcpdump -i green1 on 
the console makes live so much easier :-)

This will be my next job.
Also I want to make something to be able to change network assignment in 
setup. Something like /etc/rc.d/rc.network reconfigure.
I currently think of following solution:
  - setup creates a backup of the network config
  - in setup network config is changed (colors, addresses etc.)
  - setup writes the new network config
  - rc.network uses the old config for ifconfig down, rmmod etc.
  - new config is used for modprobe, ifconfig up etc.

This way it should be possible to change more easily the network as with 1.4


Olaf

-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

> Tested with another PNP isa card using 'ne' driver.
> Driver name is not reported in /sys/class/net.
> 
> Concerning 3c509, I look at linux-2.6 changes since 2.6.25, there is 43kb of
> changes (including commit messages). The fact that the name appear after
> 2.6.25 is related to a code change that, to summarize 43kb of changes in a 3
> lines replace
> -#include <linux/isapnp.h>
> +#include <linux/isa.h>
> +#include <linux/pnp.h>
> So new code, new features and driver name...


I have some problem with my ISA test machine, it report clocksource tsc 
unstable and is very, very slow at some points during boot.
Probably time to put this machine to junk and look thru my old HW for 
another board with ISA slot.


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Saturday, November 29, 2008 8:01 AM
Subject: [2.0] ide-generic (was Reading module corresponding to a network
interface)


> Gilles Espinasse wrote:
>
> > I have a few problem actually running 1.9.3 on my test machine.
> > The first issue could be IRQ related. On first boot eth0 fail to go up.
I
> > have to rmmod, modprobe e100. I have tested lenny install on the same
> > machine to understand better and it work.
> > Could be related to loading ide_generic (see Alan Cox answer)
> > http://marc.info/?l=linux-kernel&m=122754225521290&w=2
>
> OK. If I read that correctly the installer should try pata_legacy and
> ide_generic in (rare ?) case where no IDE disk could be found.
>
> We can try that easy enough.
>
Look good for the ide change, no more the trouble with e100 at boot.

This machine is a bit special as on-board ide controller is disabled and the
machine boot from scsi (pci) controller.

Still the issue on halt without and with acpi=off on ipcop 2.6.25 and debian
2.6.26
Still '/dev is busy'.

Tested with another PNP isa card using 'ne' driver.
Driver name is not reported in /sys/class/net.

Concerning 3c509, I look at linux-2.6 changes since 2.6.25, there is 43kb of
changes (including commit messages). The fact that the name appear after
2.6.25 is related to a code change that, to summarize 43kb of changes in a 3
lines replace
-#include <linux/isapnp.h>
+#include <linux/isa.h>
+#include <linux/pnp.h>
So new code, new features and driver name...

There is a problem on restore from floppy.
70-persistent-net.rules is not include in backup (and maybe that's wise).
But our COLOR_1_DEV eth value no more match the pseudo-random interface
number given by udev. So network is unsuable. What should we do on restore?

First, should we not save the MAC instead of a network interface name on
backup?
That may require some works as grep -r 1_DEV src match a lot.
But that allow to check on restore if all ethernet interfaces are unchanged.

Probably saving both MAC and an interface name on
/var/ipcop/ethernet/settings allow an easier transition.

Could be the best solution be to generate a persistent rule directly for
green1/blue1/orange1 names with corresponding MAC?
Would be cool to be able to ifconfig green1 without the need to know what
was the order in wich drivers has been loaded.


Gilles

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Saturday, November 29, 2008 12:02 PM
Subject: Re: [IPCop-devel] Reading module corresponding to a network
interface


> Gilles Espinasse wrote:
>
> > I find too that this test machine does not halt (display Power down
message
> > only).
> > This is because of the acpi usage, now default on grub.
> > Maybe we could parse the bios with dmidecode to look at the bios date?
>
> Does that machine power down without acpi?
>
>
Will test this afternoon.
On 2.4 kernel, no stop with acpi kernel, normal stop with acpi=off

Gilles

Gilles Espinasse wrote:

> I find too that this test machine does not halt (display Power down message
> only).
> This is because of the acpi usage, now default on grub.
> Maybe we could parse the bios with dmidecode to look at the bios date?

Does that machine power down without acpi?


Olaf

-- 

A weizen a day helps keep the doctor away.

>> At least for /proc I found a solution in Debian / Ubuntu.
>> Debian / Ubuntu init moves /proc and /sys, so that look like we can skip
>> umount and mount /sys and simply move /proc. This avoid double /proc.
>>
>> For /dev this look something different. Not sure yet how to do that.
>>
>>
>> Looks like udev is stopped by killall5 -15 in rc.halt, so /dev busy must
>> come from something else. Maybe because we have it mounted 2 times ?

using mount move for /dev removes the duplication. The message about 
/dev busy remains however.

If I execute the sequence from rc.halt manually, fuser show me that bash 
is using /dev
Maybe the message is simply there because we use a bash script to shutdown ?
IIRC on 1.4 we have similar situation, not sure, since I normally do not 
reboot and watch ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Saturday, November 29, 2008 10:05 AM
Subject: [2.0] double mounts (was Reading module corresponding to a network
interface)


> Gilles Espinasse wrote:
>
> > Running mount once installed, you could see that /proc /dev and some
other
> > appear mounted twice.
> > That's because :
> > - they are mounted on initramfs,
> > - on rc.sysinit, mountpoint command find them not mounted.
> > I suspect it could be a chicken/eggs issue with mountpoint command  if
/proc
> > if not mounted.
> > mountpoint may not see other mountpoints, but looking at mountpoint.c
code,
> > that's not clear in my mind why moutpoint command fail.
> >
> > We probably could move the initramfs 'ln -sf /proc/mounts /etc/mtab' at
the
> > beginning, so we could mount everything else without -n flag.
> >
> > There is a warning message on halt because /dev is still busy (is udev
still
> > running?)
>
>
> At least for /proc I found a solution in Debian / Ubuntu.
> Debian / Ubuntu init moves /proc and /sys, so that look like we can skip
> umount and mount /sys and simply move /proc. This avoid double /proc.
>
> For /dev this look something different. Not sure yet how to do that.
>
>
> Looks like udev is stopped by killall5 -15 in rc.halt, so /dev busy must
> come from something else. Maybe because we have it mounted 2 times ?
>
Yes that's the alternative.
Maybe mount -f
 Causes everything to be done except for the actual system call; if it's not
obvious, this ``fakes''
 mounting  the file system.  This option is useful in conjunction with
the -v flag to determine what
the mount command is trying to do. It can also be used to add entries for
devices that were mounted earlier with the -n option.

Gilles

Gilles Espinasse wrote:

> Running mount once installed, you could see that /proc /dev and some other
> appear mounted twice.
> That's because :
> - they are mounted on initramfs,
> - on rc.sysinit, mountpoint command find them not mounted.
> I suspect it could be a chicken/eggs issue with mountpoint command  if /proc
> if not mounted.
> mountpoint may not see other mountpoints, but looking at mountpoint.c code,
> that's not clear in my mind why moutpoint command fail.
> 
> We probably could move the initramfs 'ln -sf /proc/mounts /etc/mtab' at the
> beginning, so we could mount everything else without -n flag.
> 
> There is a warning message on halt because /dev is still busy (is udev still
> running?)


At least for /proc I found a solution in Debian / Ubuntu.
Debian / Ubuntu init moves /proc and /sys, so that look like we can skip 
umount and mount /sys and simply move /proc. This avoid double /proc.

For /dev this look something different. Not sure yet how to do that.


Looks like udev is stopped by killall5 -15 in rc.halt, so /dev busy must 
come from something else. Maybe because we have it mounted 2 times ?


Olaf

-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

> I have a few problem actually running 1.9.3 on my test machine.
> The first issue could be IRQ related. On first boot eth0 fail to go up. I
> have to rmmod, modprobe e100. I have tested lenny install on the same
> machine to understand better and it work.
> Could be related to loading ide_generic (see Alan Cox answer)
> http://marc.info/?l=linux-kernel&m=122754225521290&w=2

OK. If I read that correctly the installer should try pata_legacy and 
ide_generic in (rare ?) case where no IDE disk could be found.

We can try that easy enough.


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Thursday, November 27, 2008 8:57 PM
Subject: Re: [IPCop-devel] Reading module corresponding to a network
interface


> Gilles Espinasse wrote:
> > Using ls /sys/class/net/eth*/device/driver/module/drivers, you find the
> > module name (just remove the pci: prefix from the file).
> >
> > Or follow the symlink like with ls -l
> > /sys/class/net/eth*/device/driver/module/drivers and the last word is
the
> > module name.
> >
> > Unfortunately, this does not work with isa modules
> >
> > I don't know for usb network interface.
>
> Ah thanks.
>
> Looks like ls -l /sys/class/net/eth*/device/driver give enough
information:
>
> # ls -l /sys/class/net/eth1/device/driver
> lrwxrwxrwx 1 0 0 0 2008-11-27 20:50 /sys/class/net/eth1/device/driver ->
> ../../../../bus/pci/drivers/r8169
>
> # ls -l /sys/class/net/eth3/device/driver
> lrwxrwxrwx 1 0 0 0 2008-11-27 20:48 /sys/class/net/eth3/device/driver ->
> ../../../../../../bus/usb/drivers/pegasus
>
> Also for USB.
>
> I think ISA is a special case, need to check that.
>
>
I just saw that lenny detect my 3c509 card mostly like the others cards so I
will look there too.

That look special on 2.6.25 but at least on debian 2.6.26 kernel
ls -l /sys/class/net/ethx>/dev/driver work like with pci.

I have a few problem actually running 1.9.3 on my test machine.
The first issue could be IRQ related. On first boot eth0 fail to go up. I
have to rmmod, modprobe e100. I have tested lenny install on the same
machine to understand better and it work.
Could be related to loading ide_generic (see Alan Cox answer)
http://marc.info/?l=linux-kernel&m=122754225521290&w=2


I have some other subjects for cleanup found.

Running mount once installed, you could see that /proc /dev and some other
appear mounted twice.
That's because :
- they are mounted on initramfs,
- on rc.sysinit, mountpoint command find them not mounted.
I suspect it could be a chicken/eggs issue with mountpoint command  if /proc
if not mounted.
mountpoint may not see other mountpoints, but looking at mountpoint.c code,
that's not clear in my mind why moutpoint command fail.

We probably could move the initramfs 'ln -sf /proc/mounts /etc/mtab' at the
beginning, so we could mount everything else without -n flag.

There is a warning message on halt because /dev is still busy (is udev still
running?)

I find too that this test machine does not halt (display Power down message
only).
This is because of the acpi usage, now default on grub.
Maybe we could parse the bios with dmidecode to look at the bios date?

Probably we don't need to run isapnp at boot.
It should even not be needed since some 2.3 kernel.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318359
Slackware (12.1) still ship the package.

Gilles

Gilles Espinasse wrote:
> Using ls /sys/class/net/eth*/device/driver/module/drivers, you find the
> module name (just remove the pci: prefix from the file).
> 
> Or follow the symlink like with ls -l
> /sys/class/net/eth*/device/driver/module/drivers and the last word is the
> module name.
> 
> Unfortunately, this does not work with isa modules
> 
> I don't know for usb network interface.

Ah thanks.

Looks like ls -l /sys/class/net/eth*/device/driver give enough information:

# ls -l /sys/class/net/eth1/device/driver
lrwxrwxrwx 1 0 0 0 2008-11-27 20:50 /sys/class/net/eth1/device/driver -> 
../../../../bus/pci/drivers/r8169

# ls -l /sys/class/net/eth3/device/driver
lrwxrwxrwx 1 0 0 0 2008-11-27 20:48 /sys/class/net/eth3/device/driver -> 
../../../../../../bus/usb/drivers/pegasus

Also for USB.



I think ISA is a special case, need to check that.


Olaf

-- 

A weizen a day helps keep the doctor away.

Using ls /sys/class/net/eth*/device/driver/module/drivers, you find the
module name (just remove the pci: prefix from the file).

Or follow the symlink like with ls -l
/sys/class/net/eth*/device/driver/module/drivers and the last word is the
module name.

Unfortunately, this does not work with isa modules

I don't know for usb network interface.

Gilles

Gilles Espinasse wrote:

>> I see that LANG and TERM are correctly set, so there must be something
>> else that makes newt throw out garbage.
>>
> It's not newt that emit garbage.
> I changed init terminal code to be "exec busybox /bin/ash"
> 
> Then I could play manually and
> /bin/iowrap /dev/tty<whatever> /bin/ash has the same  'Bad character height
> 0'
> 
> I find later that each time the font is changed with /usr/bin/setfont, there
> is this error message.
> Once the font is set, the font is already decompressed and unless you
> recompress the font file manually in /usr/share/kbd/consolefonts, the error
> message is no more emitted.
> 
> Looking with strace, the problem could be located in gzip.
> gzip -d -c /usr/share/kbd/localefonts/la1-16.psu.gz don't keep the gz file
> and replace la1-16.psu.gz  by la1-16.psu.

OK. Then the cause are the busybox changes in getopt32.c and getopt.c ?
Or some combination of busybox gzip and options handling ?

Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>
Cc: "Gilles Espinasse" <g....@fr...>
Sent: Tuesday, November 25, 2008 9:09 AM
Subject: Re: [IPCop-devel] [Ipcop-svn] SF.net SVN: ipcop:[2104] ipcop/trunk



> I see that LANG and TERM are correctly set, so there must be something
> else that makes newt throw out garbage.
>
It's not newt that emit garbage.
I changed init terminal code to be "exec busybox /bin/ash"

Then I could play manually and
/bin/iowrap /dev/tty<whatever> /bin/ash has the same  'Bad character height
0'

I find later that each time the font is changed with /usr/bin/setfont, there
is this error message.
Once the font is set, the font is already decompressed and unless you
recompress the font file manually in /usr/share/kbd/consolefonts, the error
message is no more emitted.

Looking with strace, the problem could be located in gzip.
gzip -d -c /usr/share/kbd/localefonts/la1-16.psu.gz don't keep the gz file
and replace la1-16.psu.gz  by la1-16.psu.

Gilles

Gilles,

> But I just discover result may vary with same code and do not work in 100%
> of the events.
> It look there is a race and sometime you win, others you loose
> With the patch reverted and 1.12.2, average ratio is 30% success, 70%
> failure  (tested on pxe boot with a PII 350, reset with motherboard switch
> button)

Can you test following modification?  This works 100% for me on 2 test 
machines (both fail without this modification).
I still do not fully understand why the behavior change between busybox 
1.12.1 and 1.12.2, but this may well have been something not correct on 
our side.


Index: src/installer/installer.c
===================================================================
--- src/installer/installer.c   (revision 2106)
+++ src/installer/installer.c   (working copy)
@@ -452,6 +452,8 @@
          fprintf(flog, "Boot is unknown ?!\n");
      }

+    mysystem("/usr/bin/setfont lat0-16");
+
      /* USB keyboard modules are already loaded so no need to load them */
      /* usbcore, ehci_hcd, ohci_hcd, uhci_hcd, usbhid */



Olaf

-- 

A weizen a day helps keep the doctor away.

Olaf Westrik wrote:

> Definitively looks like there is some timing problem, if I make the 
> newtInit sequence slower it works (I always knew that sleeping is good 
> for humans as well as computers :-))
> 

Putting a sleep(1) in front of newtInit() is sufficient for my test box.


I spotted the suggestion by Denys Vlasenko, that does not make a 
difference for my test box.

I am not sure if environment is the problem, if I do:
     fprintf(flog, "LANG=%s\n", getenv("LANG"));
     fprintf(flog, "TERM=%s\n", getenv("TERM"));
     newtInit();

I see that LANG and TERM are correctly set, so there must be something 
else that makes newt throw out garbage.


Olaf

-- 

A weizen a day helps keep the doctor away.

Gilles Espinasse wrote:

> It look there is a race and sometime you win, others you loose
> With the patch reverted and 1.12.2, average ratio is 30% success, 70%
> failure  (tested on pxe boot with a PII 350, reset with motherboard switch
> button)

Thanks, that explains it. I see 100% failure.

Definitively looks like there is some timing problem, if I make the 
newtInit sequence slower it works (I always knew that sleeping is good 
for humans as well as computers :-))

After something like this:
     printf("1\n");
     sleep(5);
     printf("2\n");
     newtInit();
     printf("3\n");
     sleep(5);
     printf("4\n");
     newtCls();
     printf("5\n");
     sleep(5);

newt comes up fine on language selection. I see following:

Running in install mode
bad character height 0
1
2
3

(with pauses in between).



I have no idea where the bad character message comes from.
Maybe I will find something later. After sleep I tend to need coffee 
first ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>; "Gilles Espinasse" <g....@fr...>
Sent: Monday, November 24, 2008 9:36 PM
Subject: Re: [Ipcop-svn] SF.net SVN: ipcop:[2104] ipcop/trunk


> Gilles,
>
> > Log Message:
> > -----------
> > Fix the first screen appearance by reverting ash changes from 1.12.1 to
1.12.2
> > Bug reported to busybox
>
> I'm not sure that the patch fixes it. I've just tried an installation
> after a full rebuild (including the patch) and still see a garbled box
> in installer first screen?
> Only reverting lfs/busybox to 1.12.1 state fixed it.
>
> Please confirm.
>
I would say I was sure but I haven't made a full rebuild.

Switching again without the patch, I see the problem again.
Adding the patch back, the screen goes back normal.

But I just discover result may vary with same code and do not work in 100%
of the events.
It look there is a race and sometime you win, others you loose
With the patch reverted and 1.12.2, average ratio is 30% success, 70%
failure  (tested on pxe boot with a PII 350, reset with motherboard switch
button)

Gilles

Gilles,

> Log Message:
> -----------
> Fix the first screen appearance by reverting ash changes from 1.12.1 to 1.12.2
> Bug reported to busybox

I'm not sure that the patch fixes it. I've just tried an installation 
after a full rebuild (including the patch) and still see a garbled box 
in installer first screen?
Only reverting lfs/busybox to 1.12.1 state fixed it.

Please confirm.


Tomorrow I can probably find time to find the change from .1 to .2 that 
causes our first screen to be garbled.


Olaf

-- 

A weizen a day helps keep the doctor away.

> I have build recently for ppc and sparc without trouble.
> Installation is not tested (not tested the install, Hector had on sparc).


I can do a full test of install on Sparc, just let me know when you will
freeze code for alpha (what svn version), and I will test tftp install
(http, ftp, nfs) and cdrom install (with variants all from cd, http, ftp,
nfs)

Other from that, my test server has been working perfectly with moderate
traffic; I can set all the machines in my office to go through that server
if we need more tests.

I can also see if I can spare a floppy and usb card to test backup, my test
servers don't have neither usb nor floppy currently. Currently I'm doing a
full build for SVN 2104 to test Giles changes on gcc

Hector

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: <ipc...@li...>
Cc: "Gilles Espinasse" <g....@fr...>; "Ivan Kabaivanov"
<ch...@ya...>
Sent: Monday, November 24, 2008 10:55 AM
Subject: Re: [IPCop-devel] [Ipcop-svn] SF.net SVN: ipcop:[2096]
ipcop/trunk/make.sh


> Gilles Espinasse wrote:
>
> >> Log Message:
> >> -----------
> >> Remove the test directory when cleaning the build directory
> >>
> > That was intentionally that I didn't remove that test directory.
> > This way I have the result of the tests even when I didn't run the test
each
> > time because it's time consuming.
> >
> > Another solution should be to give a result summary of the tests in doc
for
> > each arch but I have no time now to do that.
>
> We can keep test_i486 after clean, only problem I see is the existence
> of test results when starting another (non full) build and this mixing
> former and new test results.
> But I guess one needs to be careful anyway when running and interpreting
> the test suites.
>
Yes it does not cover the dependency case.
If binutils is upgraded, you have another binutils log file with a different
version name but gcc test log file remain the same. Anyway, that's simple
and far better than nothing.

I have reverted Ivan change.

> We should at least add test_* to svn ignore list, so that it does not
> show up on svn status.
Yes, that's in my todo stack
> I can do that later today (evening), if nobody beats me to it ;-)
>
I find the syntaxe
svn propedit svn:ignore .
But I have to empty  my tree of uncommited changes before before as svn
commit . send every changes. Now done...

Gilles

Gilles Espinasse wrote:

>> Log Message:
>> -----------
>> Remove the test directory when cleaning the build directory
>>
> That was intentionally that I didn't remove that test directory.
> This way I have the result of the tests even when I didn't run the test each
> time because it's time consuming.
> 
> Another solution should be to give a result summary of the tests in doc for
> each arch but I have no time now to do that.

We can keep test_i486 after clean, only problem I see is the existence 
of test results when starting another (non full) build and this mixing 
former and new test results.
But I guess one needs to be careful anyway when running and interpreting 
the test suites.

We should at least add test_* to svn ignore list, so that it does not 
show up on svn status.
I can do that later today (evening), if nobody beats me to it ;-)


Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: <ch...@us...>
To: <ipc...@li...>
Sent: Monday, November 24, 2008 10:25 AM
Subject: [Ipcop-svn] SF.net SVN: ipcop:[2096] ipcop/trunk/make.sh


> Revision: 2096
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=2096&view=rev
> Author:   chepati
> Date:     2008-11-24 09:25:24 +0000 (Mon, 24 Nov 2008)
>
> Log Message:
> -----------
> Remove the test directory when cleaning the build directory
>
That was intentionally that I didn't remove that test directory.
This way I have the result of the tests even when I didn't run the test each
time because it's time consuming.

Another solution should be to give a result summary of the tests in doc for
each arch but I have no time now to do that.

Gilles

Gilles Espinasse wrote:

>>> I don't think we should install iface-modules-list into
>>> $(CONFIG_ROOT)/ethernet/modules-list
>>> (that's the list of card driver loaded by manual button)
>>> We would need to exclude that file from backup, that's a source of
> troubles.
>>> Are you ok if I move the file in /etc (in installer too)?
>> Thinking about this, probably better to move to /lib/modules/${KVER} and
>> call it ipcop-modules-list, since this list is kernel version dependent.
>> We may even need architecture specific lists ?
>>
> This is not so much kernel related. That's very unlikely a new ISA card
> driver will appear on a new kernel. So we could consider this  list as
> kernel independent.

OK


> And we should only have ISA card and remove every pci cards that are handled
> by the normal pci/usb detection. I know some of them (as ne2000 for example
> are available in both ISA and PCI).

OK. At the time of creation I just added several cards for which I could 
not find any reference in discover.
But since this is a list only, I think we can be very flexible as to 
which cards add or remove there.


> I think we may even detect ISA PNP card. Just run dmesg | grep isapnp on
> install boot and you have the name and number of cards detected. What I
> don't know, is where the displayed name come from. I think this is not from
> the kernel code. My 3C509 report '3Com 3C509B EtherLink III' and the small
> 3C509B string does not exist in source tree.

OK, the HW detection when doing a NIC scan can do that.
We probably need to add a field in the list so that it becomes:
drivername, isapnp reported name, full name


> Not sure ipcopbackup is the best place to load floppy module .
> Imagine one would try to use the floppy for something else than ipcopbackup.

Not sure if there is a situation where floppy is needed, other than 
backup. I would assume that people use USB stick or scp network transfer 
to move files from/to IPCop.


Olaf

-- 

A weizen a day helps keep the doctor away.