ipcop-devel Mailing List for IPCop Firewall

On Mon, Mar 31, 2008 at 11:54 AM, Gilles Espinasse <g....@fr...> wrote:
> Selon "imap.gmail.com" <kor...@gm...>:
>
>
>  > O/H Gilles Espinasse ??????:
>  > > ----- Original Message -----
>  > > From: "imap.gmail.com" <kor...@gm...>
>  > > To: "Olaf Westrik" <wei...@ip...>
>  > > Cc: <ipc...@li...>
>  > > Sent: Sunday, March 30, 2008 10:04 AM
>  > > Subject: Re: [IPCop-devel] Cross compiling lfs
>  > >
>  > >
>  ...
>
> > > Give the pci ID with lspci -nvv
>  > >
>  > > Gilles
>  > >
>  >
>  > lspci:
>  >
>  > 00:02:09.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x
>  > DEC-Tulip compatible 10/100 Ethernet (rev 31)
>  > 00:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
>  > RTL-8139/8139C/8139C+ (rev 10)
>  > 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
>  > Gigabit Ethernet (rev 10)
>  >
>  Please use the exact command given.
>  lspci -nvv
>  I don't care about the names, I want pid/vid
>
>  Gilles
>

Sorry, here you are ( /# lspci -nvv/  );

>>> Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
10ec:8169 (rev 10)
        Subsystem: 1458:e000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at e800 [size=256]
        Region 1: Memory at eb009000 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 50020000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: r8169


>kernel module: r8169

>>> Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip
compatible 10/100 Ethernet (rev 31)
Class 0200: 1282:9102 (rev 31)
        Subsystem: 3030:5032
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (5000ns min, 10000ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at e000 [size=256]
        Region 1: Memory at d9001000 (32-bit, non-prefetchable) [size=256]
        [virtual] Expansion ROM at 20000000 [disabled] [size=256K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2+ AuxCurrent=220mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

>kernel module dmfe

>>> Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Class 0200: 10ec:8139 (rev 10)
        Subsystem: 10ec:8139
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (8000ns min, 16000ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at dc00 [size=256]
        Region 1: Memory at d9000000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

> kernel module 8139too

lspci results come from different machines; 100mbps cards are still on
p3 tartget (where the above results come), but 1gbps card has moved to
another machine for testing, and that's why you may notice differences
in the output format.

Nikos

-- 
-
Postgrad student of Department of Computer Engineering and Informatics
( http://www.ceid.upatras.gr )

 WARNING: posting to or from gmail might disclose sensitive information
 to people you don't entirely trust. For safe, private communication use
 korkarak (at) ceid (dot) upatras (dot) gr , and my public PGP key from
 http://students.ceid.upatras.gr/~korkakak/mykey

Selon "imap.gmail.com" <kor...@gm...>:

> O/H Gilles Espinasse ??????:
> > ----- Original Message -----
> > From: "imap.gmail.com" <kor...@gm...>
> > To: "Olaf Westrik" <wei...@ip...>
> > Cc: <ipc...@li...>
> > Sent: Sunday, March 30, 2008 10:04 AM
> > Subject: Re: [IPCop-devel] Cross compiling lfs
> >
> >
...
> > Give the pci ID with lspci -nvv
> >
> > Gilles
> >
>
> lspci:
>
> 00:02:09.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x
> DEC-Tulip compatible 10/100 Ethernet (rev 31)
> 00:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169
> Gigabit Ethernet (rev 10)
>
Please use the exact command given.
lspci -nvv
I don't care about the names, I want pid/vid

Gilles

O/H Gilles Espinasse ??????:
> ----- Original Message ----- 
> From: "imap.gmail.com" <kor...@gm...>
> To: "Olaf Westrik" <wei...@ip...>
> Cc: <ipc...@li...>
> Sent: Sunday, March 30, 2008 10:04 AM
> Subject: Re: [IPCop-devel] Cross compiling lfs
> 
> 
> ...
> ...
>> |
>> |> The reason I need to build ipcop on my own is that the shipped sources
>> |> does not include some kernel modules that are needed in order for my
>> |> hardware to work correctly.
>> |
>> | ? why are you cross compiling if all you want is a kernel module?
>> |
>> | It would probably be helpful if you tell us which host & destination
>> | arch you are using / want to use and which kernel module you miss.
>> |
>> I have 3 x86_64 machines (amd64) and the destination machine is a p3.
>>
> You don't need CLFS cross-compilation
>  # this will load a prepackaged toolchain to your machine
> ./make.sh gettoolchain
> 
>  # this will load from sourceforge a big package with all packages used to
> build your machine
> ./make.sh getothersrc
> 
> and you should be able to compile on a 32b distrib or on a 64b distrib
> inside a 32 console.
> 
> On cvs, I have fixed some problem to compile the toolchain on cvs from
> different distrib on the last two days. I have not yet commited everything
> (in particular glibc part) and I just find that if it fix some problem, it
> break the build with the toolchain package we are using since 1.4.11.
> That's not a big problem, I could upload a newer toolchain package but
> that's actually not yet done.
> 
>> The correct kernel modules missing during installation are;
>> *dmfe (davidcom 100mbps nic) and instead it loads tulip (pci).
>> *I cannot load realtek 8139 100mbps module which is really a bummer
>> since I have two of those one the machine (pci).
>> *Again realtek is the honoured party the D-Link gigabit nic cannot play
>> on the machine (r8169) (pci).
>> [1](Score : 3 realteks 1 davidcom still no network :-P)
> Give the pci ID with lspci -nvv
> 
> Gilles
> 

lspci:

00:02:09.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x 
DEC-Tulip compatible 10/100 Ethernet (rev 31)
00:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL-8139/8139C/8139C+ (rev 10)
00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 
Gigabit Ethernet (rev 10)

The other realtek is away but from the board but is exactly the same 
board (pcbs manufacturer hw rev)
To operate davicom (which is the only that is identified by the system) 
I have to rmmod the tulip driver and then install the correct one dmfe 
(or to add it @ modprobe.conf :-P) That was the workaround back when I 
was using slackware (and 2.4 kenrel) at the machine.

Nikos

----- Original Message ----- 
From: "imap.gmail.com" <kor...@gm...>
To: "Olaf Westrik" <wei...@ip...>
Cc: <ipc...@li...>
Sent: Sunday, March 30, 2008 10:04 AM
Subject: Re: [IPCop-devel] Cross compiling lfs


...
...
> |
> |> The reason I need to build ipcop on my own is that the shipped sources
> |> does not include some kernel modules that are needed in order for my
> |> hardware to work correctly.
> |
> | ? why are you cross compiling if all you want is a kernel module?
> |
> | It would probably be helpful if you tell us which host & destination
> | arch you are using / want to use and which kernel module you miss.
> |
> I have 3 x86_64 machines (amd64) and the destination machine is a p3.
>
You don't need CLFS cross-compilation
 # this will load a prepackaged toolchain to your machine
./make.sh gettoolchain

 # this will load from sourceforge a big package with all packages used to
build your machine
./make.sh getothersrc

and you should be able to compile on a 32b distrib or on a 64b distrib
inside a 32 console.

On cvs, I have fixed some problem to compile the toolchain on cvs from
different distrib on the last two days. I have not yet commited everything
(in particular glibc part) and I just find that if it fix some problem, it
break the build with the toolchain package we are using since 1.4.11.
That's not a big problem, I could upload a newer toolchain package but
that's actually not yet done.

> The correct kernel modules missing during installation are;
> *dmfe (davidcom 100mbps nic) and instead it loads tulip (pci).
> *I cannot load realtek 8139 100mbps module which is really a bummer
> since I have two of those one the machine (pci).
> *Again realtek is the honoured party the D-Link gigabit nic cannot play
> on the machine (r8169) (pci).
> [1](Score : 3 realteks 1 davidcom still no network :-P)
Give the pci ID with lspci -nvv

Gilles

On Sun, Mar 30, 2008 at 11:04 AM, imap.gmail.com <kor...@gm...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  O/H Olaf Westrik ??????:
>
>  Thank you olaf for your quick response.
>
>  |> Is it possible to cross compile ipcop from another system (host and
>  |> destination are different arch) ?
>  |
>  | Not really.
>  |
>  |
>  |> Furthermore some packages I tried to download with make.sh prefetch
>  |> failed [1].
>  |
>  | The websites for libpcap/tcpdump, openssl and squid seem to be
>  | unreachable or down.  A ./make.sh getothersrc may helop you get all
>  sources.
>  |
>  |
>  |> The reason I need to build ipcop on my own is that the shipped sources
>  |> does not include some kernel modules that are needed in order for my
>  |> hardware to work correctly.
>  |
>  | ? why are you cross compiling if all you want is a kernel module?
>  |
>  | It would probably be helpful if you tell us which host & destination
>  | arch you are using / want to use and which kernel module you miss.
>  |
>  I have 3 x86_64 machines (amd64) and the destination machine is a p3.
>
>  In order to reproduce the problem; _used the IPCop v 1.4.18 which @
>  ipcop.org is stated as the current release_
>  After [1] i decided to take some action by building it myself.
>
>  The correct kernel modules missing during installation are;
>  *dmfe (davidcom 100mbps nic) and instead it loads tulip (pci).
>  *I cannot load realtek 8139 100mbps module which is really a bummer
>  since I have two of those one the machine (pci).
>  *Again realtek is the honoured party the D-Link gigabit nic cannot play
>  on the machine (r8169) (pci).
>  [1](Score : 3 realteks 1 davidcom still no network :-P)
>
>  The reason some self build was required is that the supplied kernel is a
>  bit old and to use some extra security (like selinux patch) with some
>  stable of the 2.6 line.
>  The thought of building just an LFS tailored for the p3 with clfs was
>  the first that came out but  I guess that many things would be broken.
>
>  |
>  | Olaf
>  |
>
>  Nikos :-)
>  -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v2.0.7 (GNU/Linux)
>  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>  iD8DBQFH70mUlslej7PCiasRAorQAJ0aHeu2b3uWwk/UaOCU+R/6bPuFFACeOJtG
>  Vi6sr/o0tWfJD2WDNvu/fYc=
>  =ly1K
>  -----END PGP SIGNATURE-----
>

I sincerely apologize for the spam.
Something goes terribly wrong with thunderbird and instead of saving
the draft it sends it :-(

-- 
-
Postgrad student of Department of Computer Engineering and Informatics
( http://www.ceid.upatras.gr )

 WARNING: posting to or from gmail might disclose sensitive information
 to people you don't entirely trust. For safe, private communication use
 korkarak (at) ceid (dot) upatras (dot) gr , and my public PGP key from
 http://students.ceid.upatras.gr/~korkakak/mykey

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

O/H Olaf Westrik ??????:

Thank you olaf for your quick response.

|> Is it possible to cross compile ipcop from another system (host and
|> destination are different arch) ?
|
| Not really.
|
|
|> Furthermore some packages I tried to download with make.sh prefetch
|> failed [1].
|
| The websites for libpcap/tcpdump, openssl and squid seem to be
| unreachable or down.  A ./make.sh getothersrc may helop you get all
sources.
|
|
|> The reason I need to build ipcop on my own is that the shipped sources
|> does not include some kernel modules that are needed in order for my
|> hardware to work correctly.
|
| ? why are you cross compiling if all you want is a kernel module?
|
| It would probably be helpful if you tell us which host & destination
| arch you are using / want to use and which kernel module you miss.
|
I have 3 x86_64 machines (amd64) and the destination machine is a p3.

In order to reproduce the problem; _used the IPCop v 1.4.18 which @
ipcop.org is stated as the current release_
After [1] i decided to take some action by building it myself.

The correct kernel modules missing during installation are;
*dmfe (davidcom 100mbps nic) and instead it loads tulip (pci).
*I cannot load realtek 8139 100mbps module which is really a bummer
since I have two of those one the machine (pci).
*Again realtek is the honoured party the D-Link gigabit nic cannot play
on the machine (r8169) (pci).
[1](Score : 3 realteks 1 davidcom still no network :-P)

The reason some self build was required is that the supplied kernel is a
bit old and to use some extra security (like selinux patch) with some
stable of the 2.6 line.
The thought of building just an LFS tailored for the p3 with clfs was
the first that came out but  I guess that many things would be broken.

|
| Olaf
|

Nikos :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH70mUlslej7PCiasRAorQAJ0aHeu2b3uWwk/UaOCU+R/6bPuFFACeOJtG
Vi6sr/o0tWfJD2WDNvu/fYc=
=ly1K
-----END PGP SIGNATURE-----

On Friday 28 March 2008, Olaf Westrik wrote:
> Ivan Kabaivanov wrote:
> > I will do this instead:  I'll redesign mkinitramfs's --with-modules
> > switch so that it will work in three modes:
> > 1) --with-modules=/path/to/modules.list -- this will take only the
> > modules (plus dependencies) found in a file
> > 2) --with-modules=ata,scsi,ide,fs etc etc -- this will copy the entire
> > modules subdirectories
> > 3) --with-modules=all -- this will copy all modules
>
> 2 separate switches would be ok. --module-list= and --modules (or
> something like that).




just committed new_mkinitramfs for testing.  --with-modules takes any 
combination of individual modules, whole modules subdirectories, a filename 
with a list of modules and the keyword 'all' which will include all modules.

Also fixed a bug in find_module_deps() that omitted modules in some cases.

One problem in the new script is that all the modules are piped into 
modules.conf which is parsed at boot time and all the modules in it are 
loaded.  There isn't really a problem, only the list is a bit redundant -- 
all modules are listed instead of the major ones.  Modprobe knows to load any 
module dependencies so we don't need to include every single module in 
modules.conf.  I will try to come up with a better solution.




>
> > I also want to make mkinitramfs a self extracting script (with makeself)
> > so that the script is self-sufficient.  Right now the basic structure of
> > the initramfs is in /usr/lib/mkinitramfs and /sbin/mkinitramfs copies
> > that structure into a temporary directory and adds the requested modules
> > (and binary firmware, if requested).  If something were to happen
> > to /usr/lib/mkinitramfs then the script will be broken.  I propose we
> > embed an archive of that directory into /sbin/mkinitramfs so the script
> > always works.
>
> If something where to happen /usr/lib/mkinitramfs it could also happen
> to /sbin/mkinitramfs, no ?



yes, good point.  John also pointed out the same thing.  I guess I was itching 
to play with making self extracting scripts :-)

IvanK.

> Is it possible to cross compile ipcop from another system (host and 
> destination are different arch) ? 

Not really.


> Furthermore some packages I tried to download with make.sh prefetch 
> failed [1].

The websites for libpcap/tcpdump, openssl and squid seem to be 
unreachable or down.  A ./make.sh getothersrc may helop you get all sources.


> The reason I need to build ipcop on my own is that the shipped sources 
> does not include some kernel modules that are needed in order for my 
> hardware to work correctly.

? why are you cross compiling if all you want is a kernel module?

It would probably be helpful if you tell us which host & destination 
arch you are using / want to use and which kernel module you miss.


Olaf

-- 

A weizen a day helps keep the doctor away.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello list,

Is it possible to cross compile ipcop from another system (host and 
destination are different arch) ? I tried to build a system via CLFS and 
add the ipcop sources but I think I drastically failed. Are there any 
howtos available (some quick search engine lookup didn't provide any 
useful information).
Furthermore some packages I tried to download with make.sh prefetch 
failed [1].
The reason I need to build ipcop on my own is that the shipped sources 
does not include some kernel modules that are needed in order for my 
hardware to work correctly.


thank you in advance




[1] failed packages
Archive-Zip (Attempt: 
3)                                                                                  
[ FAIL ] [ FAIL ]
CnxADSL (Attempt: 
3)                                                                                      
[ FAIL ] [ FAIL ]
Compress-Zlib (Attempt: 
3)                                                                                
[ FAIL ] [ FAIL ]
Digest (Attempt: 
3)                                                                                       
[ FAIL ] [ FAIL ]
grub (Attempt: 
3)                                                                                         
[ FAIL ] [ FAIL ]
libpcap (Attempt: 
3)                                                                                      
[ FAIL ] [ FAIL ]
tcpdump (Attempt: 
3)                                                                                      
[ FAIL ] [ FAIL ]
*** 7 package(s) could not be downloaded
*** 7 package(s) had incorrect md5sum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH7x+5lslej7PCiasRAhnqAJ4+XyEUJs6rWIFV4CY3bXfxrjDvqwCghkqq
8qtgmZgM9skWG0SSJEUhO3o=
=Kh8l
-----END PGP SIGNATURE-----

Hi
Here's the current status.

I have managed to get Knoppix to install IPCop using the attached
shell script. You need to copy the script plus the three tarballs
(ipcop-1.9.1.tar.gz, ipcop-1.9.1-config.tar.gz and
ipcop-1.9.1-varlog.tar.gz) into a directory that can be accessed by
Knoppix.


Booting with the standard IPCop kernel and an initrd with only the
modules that Knoppix loads doesn't work 100% becase Knoppix has some
drivers in the kernel not as modules. These include some SATA and IDE
controllers, so the effect is that the root filesystem will not mount
(same as the current install method).

Booting IPCop with the Knoppix kernel on the other hand works fine, so
the theory is sound. We could configure the IPCop kernel to be more
like the Knoppix one, but I think that would might be a dead end. A
better way is to use an initrd with the essential modules and use udev
for hardware detection in the same that other Linux distributions do.

The normal IPCop setup program runs inside a chroot on the new
installation as 'setup INSTALL', and seems to work except that the
translations are completely missing. Maybe because it has not been
passed the language from the installer and is missing the ability
to ask the user if it is unset.


I'm not suggesting that we should use a shell script to install IPCop,
only that the install can be seperated from setup and hardware
detection. The only reason I choose bash is that is was quick to write
and test without recompiling and Python or Perl would add to the size
of a future install disk.

If anyone does want to test IPCop 2.0 and the normal install disk just
won't work, then you could try this method.



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

Feature Requests item #1928615, was opened at 2008-03-29 11:35
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=1928615&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: Interface Improvements (example)
Group: Next release
Status: Open
Priority: 5
Private: No
Submitted By: SoftGil (softgil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lack of Logs from previous year(s).

Initial Comment:
Hello everyone.

I was questioned about this for which I have no answer:

Is there any chance for IPCop to display the logs for previous years instead of only the current year? Hard disk space is not a problem.

What triggered this question was an implementation of IPCop in a motherboard in which the internal battery failed. As such, date and time were reverted back to 2001. This happened 3 days ago and, even though IPCop kept on running, this situation was only detected today. After changing the motherboard's faulty battery everything returned to a smooth operation BUT logs for those 3 days were lost. I know they are tagged as belonging to January 1-2-3, 2001 but I have no chance to search and view them via the web GUI.  

Would that be hard to implement in IPCop?

Many thanks and best regards.

SoftGil


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

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

Bugs item #1928374, was opened at 2008-03-28 19:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1928374&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
Resolution: None
Priority: 5
Private: No
Submitted By: Jeff D. Hanson (jhansonxi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor httpd memory leak

Initial Comment:
IPCop 1.4.18
I've got IPCop running on an old K6/2 system and was playing around with Snort.  After it nearly hung with Snort hogging all the memory I reduced it to only monitoring Green and it's happy now.  Nothing surprising there but I became more aware of memory usage and noticed that free memory was slowly being consumed over time.  After monitoring it for a while I found that the httpd processes are source of the problem and it seems to be triggered by my use of the IPCop administration web pages.  Is this a normal caching behavior?  I'm not using Squid.

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

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

Ivan Kabaivanov wrote:

> that would be the best solution, but busybox-1.9.x doesn't support gzipped 
> modules.  The old Busybox (I can't remember now if it was 0.x or 1.4.x) had a 
> patch to do that, but I haven't seen (nor searched for) an updated patch.

This one (busybox 1.2.1) seems trivial enough: 
http://busybox.net/lists/busybox/2006-November/025410.html

Olaf

-- 

A weizen a day helps keep the doctor away.

On Fri, Mar 28, 2008 at 04:43:48PM +0100, Gilles Espinasse wrote:
> Selon John Edwards <jo...@co...>:
> 
> It look your mail system is sending more than you want ;-)

Not mine. The guilty party has been condemned to attend children's
swimming lessons for the rest of the weekend.
;)

On a related note, this week I've had some ipcop-devel emails take up
to 2 days to be delivered. They seem to get held up somewhere in
"netdirect.ca" after leaving sourceforge.net. 

The delayed email was from Gilles, and they all seem to have been
routed through netdirect after sourceforge and have an extra header
of:
  "X-Envelope-To: <jo...@ne...>" 

Other ipcop-devel email doesn't have this header, or go through
netdirect.

I have never been jo...@ne..., but that is the email address of
John Van Ostrand who runs Net Direct in Canada. Maybe my email is
getting caught in an old email filter somewhere.

Could other people check the headers of their sourceforge email,
especially anyone with a "john@" email address.

If all else fails I could try email jo...@ne..., if it's
still a valid email address.


> Concerning the related subject, I think to have answered that
> I was ok the way you want to include many modules in the initrd.
> 
> I have given a possible solution to spare some space on disk
> by compressing the modules (like it is done on 1.4).
> If you google 'ko.gz', there is some hits, notabily Mandriva and
> some Suse.

Yeah, I remember using Mandrake several years with compressed modules.
I think it was a pain adding extra drivers, but then Mandrake did some
strange things and the whole system was buggy, so I didn't use it for
long.


> This spare 10 MB for one of our full tree.
> 
> We have to check how mkinitramfs behave with compressed modules.
> And we may need to include rebuilding initramfs each time a module include is
> updated.

According to the module-init-tools docs compression support is enabled
with "--enable-zlib", which is already in the LFS script. So IPCop
should be able to support it now.

Personnally I would wait a while for other things to be fixed and then
enable it to reduce space. Saving 10MB out of about 100MB is quite
useful, even more so if there is more than one kernel installed.


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

On Fri, Mar 28, 2008 at 10:46:37PM +0100, Olaf Westrik wrote:
> John Edwards wrote:
>> We already have a hard-coded minimum of 256 MB for hard disks in
>> IPCop 2.0, which on an i386 machine will be laid out like:
>> Boot = 16 MB
>> Root (excluding swap file) = 148 MB (min of 128 MB)
>> Swap file = 52 MB (min of 32 MB)
>> Logs = 40 MB
> 
> The current partitioning needs different calculation.
> 
> 128 MB as / minimum size requirement is not enough.
> We install ~ 110 MB on /. Add to that at least 20 MB for 
> /lib/modules/KVER for 1 extra kernel (not counting initrd and all other 
> stuff).
> Add some space for addons and other goodies.
> Add additional space again to be able to do an update at all.
> 
> So the minimum of 128 is too low.

Yes, I would agree that is the bare minimum to install and not enough
to keep IPCop running with updates. The calculations where taken from
partition.c.

So are we looking at a new minimum hard drive size of somewhere
between 350MB and 500MB?

500MB could be a useful round number, as it was also around the time
of some changes to the IDE standard. Early BIOS could only use C/H/S
upto 528MB. Keeping it just below that limit would allow very old
hardware to still be used.

If the root filesystem is short on space but RAM and swap are
available then /tmp could be used for unpacking updates as it is now
tmpfs in RAM.

Calculations for flash system sizes would need to be done
independently, as they have a different partition layout.
I think 256MB should still be possible if the user is careful.


ps Does JackB still have his famous 486sx?
If so than it may need a hardware upgrade.
;)


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

On Fri, Mar 28, 2008 at 02:43:40PM -0400, Ivan Kabaivanov wrote:
> On Wednesday 26 March 2008 18:34, Gilles Espinasse wrote:
<snip>
>> We could recover the supplemental place used on /boot by compressing 
>> kernel modules under /lib/modules. We alreay have modules-init-tools
>> with --enable-zlib
>>
>> [chroot-i486] root:/$ du -s /lib/modules
>> 20480   /lib/modules
>> [chroot-i486] root:/$ find /lib/modules/ -name '*.ko' -a -type f | xargs
>> gzip -nf9
>> [chroot-i486] root:/$ du -s /lib/modules
>> 9572    /lib/modules
>>
>> Not tested at all how that behave with initramfs.
>> There has been a kernel patch proposed to compress the modules during 'make
>> modules_install'
>> Anyway the find line work in any case with the maintenance cost of a patch.
>> http://lkml.org/lkml/2008/2/25/361
>>
>> Gilles

> Gilles,
> 
> that would be the best solution, but busybox-1.9.x doesn't support gzipped 
> modules.  The old Busybox (I can't remember now if it was 0.x or 1.4.x) had a 
> patch to do that, but I haven't seen (nor searched for) an updated patch.
> 
> I will do this instead:  I'll redesign mkinitramfs's --with-modules switch so 
> that it will work in three modes:
> 1) --with-modules=/path/to/modules.list -- this will take only the modules 
> (plus dependencies) found in a file
> 2) --with-modules=ata,scsi,ide,fs etc etc -- this will copy the entire modules 
> subdirectories
> 3) --with-modules=all -- this will copy all modules
> 
> I will also add return codes.  Something like:
> 0 -- success
> 1 -- kernel directory not found
> 2 -- module(s) (file) not found
> 3 -- firmware not found
> 4) -- insufficient space on /boot for the requested ipcoprd.img
> etc
> 
> I also want to make mkinitramfs a self extracting script (with makeself) so 
> that the script is self-sufficient.  Right now the basic structure of the 
> initramfs is in /usr/lib/mkinitramfs and /sbin/mkinitramfs copies that 
> structure into a temporary directory and adds the requested modules (and 
> binary firmware, if requested).  If something were to happen 
> to /usr/lib/mkinitramfs then the script will be broken.  I propose we embed 
> an archive of that directory into /sbin/mkinitramfs so the script always 
> works.
> 
> If everyone agrees I can do the changes today.
> 
> IvanK.

Hi Ivan

Your method of some/most/all modules is very similar to the Debian &
Ubuntu mkinitrd scripts. Would it be possible to have second option
to allow someone to add any extra modules that are unusual? Examples
would be the Mac G5 fan someone mentioned earlier or a strange ISA
network card.


I have succesfully booted IPCop with a Debian kernel, modules and
initrd on the machine where IPCop would not automatically detect
hardware. I believe this to be because Debian & Ubuntu use udev
for hardware detection.

Similarly booting IPCop with the Knoppix kernel works as well, but
that is probably because Knoppix includes more drivers inside the
kernel instead as modules.


I have done some work on the modules in the initrd in order to try
and understand why udev on Debian & Ubuntu can automatically load
detect hardware and load modules but IPCop's udev doesn't.

All the docs on udev say that we should be able to do this very
early on in the init process (udevtrigger will kick it off if
udevd is running).

References:
  http://www.linuxfromscratch.org/lfs/view/stable/chapter07/udev.html
  http://vrfy.org/log/recent-state-of-udev.html


I'm not sure if this will ever remove the need for the discover
package, as the docs say that ISA devices are not supported well.

I have modified your patch that included most drivers, but excluded
the net directory as that take almost half the total size, and
fixed the paths in the cp command.


The first problem I found was the modules.alias file was not being
created because depmod -a needs to rebuild them. That was simple
enough to add.

The current state is that only some disk, USB and firewire controllers
are found, but no hard disks are found.

The main example I have been testing with is VMWare Workstation 5.5. 
This may not be the best test platform because the SCSI controller
has a bug where some 2.6.2x kernels can not access devices on it, and 
the IDE controller can be used by either of two modules (piix to get 
hda or libata's ata_piix to get sda).

The IDE controller's alias strings in definitely in the modules.alias
file and modinfo shows that both the piix and ata_piix modules can match
it.

I suspect the problems are in the udev rules or possibly the modprobe.
I have upgrade udev to version 119, which uses a single udevadm binary
instead udevtrigger, udevsettle, etc. This has not changed things.


I have attached my current patch files, but they have not been fully
tested. Also they have not been split into seperate depmod and
udev-119 patches. But I'm sure you can spot and extract the simple
depmod changes by hand.


If you wish to observe the same behaviour on Ubuntu or Debian then add
"break" to the end of the boot parameters in GRUB. This will stop the
init process early on and leave you at a shell in the initrd, similar
to your "rescue" option. Here you can run:

udevd --daemon
udevtrigger --verbose

You can see what is going on by running 'ls' and 'cat' on the /sys and
/proc file systems before and after, and 'dmesg' will give you the
kernel messages. Udev on Debian/Ubuntu seems to find almost everything.

Ubuntu documentation:
  https://wiki.ubuntu.com/HardwareDetection
  https://wiki.ubuntu.com/HardwareActivation
  https://wiki.ubuntu.com/DesktopTeam/Specs/HardyHardwareDetection
  https://wiki.ubuntu.com/UdevRoadmap


I know this automatic hardware detection and activation is possible, 
because it works with Debian & Ubuntu on the same hardware with
the same kernel and udev versions. It is just a question of finding
the missing link (maybe in udev or modprobe config?).

The problem is that I'm starting to come down with a cold, so thinking
may become hard over the next few days. If anyone wants to test or take
over then feel free.


ps. Embedding /usr/lib/mkinitramfs into /sbin/mkinitramfs would
make it hard to alter things while we are testing. I don't think
anything else uses /usr/lib/mkinitramfs, so why would it break?


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

Ivan Kabaivanov wrote:

> yes, saw it.  Thanks!  Is it that simple?  Just put a # $Id$?

don't forget: svn propset svn:keywords Id <filename>

-- 

A weizen a day helps keep the doctor away.

On Friday 28 March 2008 15:57, Achim Weber wrote:
> Hi Ivan
>
> > Added copyright notices to our init files.  Olaf or anyone else, can you
> > add the Id part?  I am not sure how.
>
> Done :-)


Achim,

yes, saw it.  Thanks!  Is it that simple?  Just put a # $Id$?

IvanK.


>
> This is the chapter in the svnbook:
> -> http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.4
>
>
> Achim
>

Ivan Kabaivanov wrote:

> I will do this instead:  I'll redesign mkinitramfs's --with-modules switch so 
> that it will work in three modes:
> 1) --with-modules=/path/to/modules.list -- this will take only the modules 
> (plus dependencies) found in a file
> 2) --with-modules=ata,scsi,ide,fs etc etc -- this will copy the entire modules 
> subdirectories
> 3) --with-modules=all -- this will copy all modules

2 separate switches would be ok. --module-list= and --modules (or 
something like that).


> I also want to make mkinitramfs a self extracting script (with makeself) so 
> that the script is self-sufficient.  Right now the basic structure of the 
> initramfs is in /usr/lib/mkinitramfs and /sbin/mkinitramfs copies that 
> structure into a temporary directory and adds the requested modules (and 
> binary firmware, if requested).  If something were to happen 
> to /usr/lib/mkinitramfs then the script will be broken.  I propose we embed 
> an archive of that directory into /sbin/mkinitramfs so the script always 
> works.

If something where to happen /usr/lib/mkinitramfs it could also happen 
to /sbin/mkinitramfs, no ?


Olaf

-- 

A weizen a day helps keep the doctor away.

John Edwards wrote:

> We already have a hard-coded minimum of 256 MB for hard disks in
> IPCop 2.0, which on an i386 machine will be laid out like:
> Boot = 16 MB
> Root (excluding swap file) = 148 MB (min of 128 MB)
> Swap file = 52 MB (min of 32 MB)
> Logs = 40 MB

The current partitioning needs different calculation.

128 MB as / minimum size requirement is not enough.
We install ~ 110 MB on /. Add to that at least 20 MB for 
/lib/modules/KVER for 1 extra kernel (not counting initrd and all other 
stuff).
Add some space for addons and other goodies.
Add additional space again to be able to do an update at all.

So the minimum of 128 is too low.


Olaf

-- 

A weizen a day helps keep the doctor away.

On Wednesday 26 March 2008 18:34, Gilles Espinasse wrote:
> ----- Original Message -----
> From: "John Edwards" <jo...@co...>
> To: "Gilles Espinasse" <g....@fr...>
> Cc: "IPCop devel" <ipc...@li...>
> Sent: Wednesday, March 26, 2008 6:14 PM
> Subject: Re: [IPCop-devel] Including most kernel modules into the initramfs
>
> ...
>
> >>> John Edwards <jo...@co...> wrote:
> >>>> The proposal adds 4.3MB to the initrd. Who many systems are going to
> >>>> break for the lack of an extra 10MB on the hard drive? Only those with
> >>>> 200MB hard drives, or maybe 500MB with large Squid caches.
>
> We could recover the supplemental place used on /boot by compressing 
> kernel modules under /lib/modules. We alreay have modules-init-tools
> with --enable-zlib
>
> [chroot-i486] root:/$ du -s /lib/modules
> 20480   /lib/modules
> [chroot-i486] root:/$ find /lib/modules/ -name '*.ko' -a -type f | xargs
> gzip -nf9
> [chroot-i486] root:/$ du -s /lib/modules
> 9572    /lib/modules
>
> Not tested at all how that behave with initramfs.
> There has been a kernel patch proposed to compress the modules during 'make
> modules_install'
> Anyway the find line work in any case with the maintenance cost of a patch.
> http://lkml.org/lkml/2008/2/25/361
>
> Gilles
>
>
> Gilles
>
>


Gilles,

that would be the best solution, but busybox-1.9.x doesn't support gzipped 
modules.  The old Busybox (I can't remember now if it was 0.x or 1.4.x) had a 
patch to do that, but I haven't seen (nor searched for) an updated patch.

I will do this instead:  I'll redesign mkinitramfs's --with-modules switch so 
that it will work in three modes:
1) --with-modules=/path/to/modules.list -- this will take only the modules 
(plus dependencies) found in a file
2) --with-modules=ata,scsi,ide,fs etc etc -- this will copy the entire modules 
subdirectories
3) --with-modules=all -- this will copy all modules

I will also add return codes.  Something like:
0 -- success
1 -- kernel directory not found
2 -- module(s) (file) not found
3 -- firmware not found
4) -- insufficient space on /boot for the requested ipcoprd.img
etc

I also want to make mkinitramfs a self extracting script (with makeself) so 
that the script is self-sufficient.  Right now the basic structure of the 
initramfs is in /usr/lib/mkinitramfs and /sbin/mkinitramfs copies that 
structure into a temporary directory and adds the requested modules (and 
binary firmware, if requested).  If something were to happen 
to /usr/lib/mkinitramfs then the script will be broken.  I propose we embed 
an archive of that directory into /sbin/mkinitramfs so the script always 
works.

If everyone agrees I can do the changes today.

IvanK.

Hi Ivan

> Added copyright notices to our init files.  Olaf or anyone else, can you add
> the Id part?  I am not sure how.

Done :-)

This is the chapter in the svnbook:
-> http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.4


Achim

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

It look your mail system is sending more than you want ;-)

Concerning the related subject, I think to have answered that
I was ok the way you want to include many modules in the initrd.

I have given a possible solution to spare some space on disk
by compressing the modules (like it is done on 1.4).
If you google 'ko.gz', there is some hits, notabily Mandriva and
some Suse.
This spare 10 MB for one of our full tree.

We have to check how mkinitramfs behave with compressed modules.
And we may need to include rebuilding initramfs each time a module include is
updated.

Gilles

On Thu, Mar 27, 2008 at 08:44:07PM +0100, Olaf Westrik wrote:
> IMNSHO calling people, who you hardly know anything about, "disconnected 
> from the community" is not in sync with reality.
> I know Gilles (personally as well as electronically) and he is very much 
>   involved in multipe IPCop Communities, of which you have probably 
> never even heard, but which are much more lively then ipcop-user

OK, lets calm this down before this turns into a flame war. I did not
post that email to the ipcop-user mailing list. A friend that I was
talking to mistakenly sent it to the wrong email address.

I have already emailed a clarification and apology to the ipcop-user
mailing list, so I won't copy that here. Short version is that the
comments was out of context and was just me expressing a little
fustration at the "reinstall for hardware change". It was not about
anything more general.

How could it be? Olaf and Gilles have been very patient and helpful
with my many questions and lack of knowledge about IPCop development.
And they have been very receptive about my patches, even when I had to
post a fix for a stupid mistake just a few hours after posting the
broken patch.

While it may not make any damage disappear I do hope the apology email
will stop others from getting the wrong idea about what I was saying.
I also hope it does not draw any more attention to a silly mistake.


You and Gilles have every right to be angered, and I would probably be
fuming for a few days. I would expect anyone that made continuous
personnal attacks on another member in a mailing list to be
unsubscribed.

I also hope that this will pass and you will take any contributions
from myself on there technical merits. In fact hope that people post
technical criticisms of my work. If there is something wrong it needs
to be fixed.


You are right that I do not know Gilles, and I'm sure that is my
loss. I completely agree that he is much more involved with IPCop than
I could ever be. By my own admission in previous emails I've not
contributed anything in three years, and even then it was mostly
testing, bug fixes, code clean ups and some now obsolete addons.

The constant hard work all the IPCop developers put in gives me
inspiration for my own small work on IPCop.

Thank you.


<order reversed>
>>> I tested IPCop for a dare
>>> It used a CDROM that wasn't there
>>> It wasn't there again today
>>> I hope we find it someday
> 
> 
> I like this one better:
> 
> 
> people come and people go
> sometimes even with a big blow
> 
> one is always there and persistent
> to keep our poor networks resistant
> 
> it is a little man from France
> protecting us against aberrance
> 
> may he stay there for us
> and keep IPCop glorious
> 
> 
> Thanks Gilles, on behalf of the IPCop Community, for all that hard work 
> you put into IPCop year after year.

Rhyming "France" and "aberrance" brought a big grin to my face.
Almost as good as Bob Dylan managing to rhyme "Pope" and "Europe".


ps. I little bit of background on the silly rhyme, it comes from an
old English bit of nonsense about "A man who wasn't there" (a ghost I
think). It was on the news here in the UK when I doing some work on
IPCop. It was just a bit of silliness about my struggles with hardware
detection made up on the spot.

pps. I promise not to post any more bad poetry pastiches.


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

 >> I tested IPCop for a dare
 >> It used a CDROM that wasn't there
 >> It wasn't there again today
 >> I hope we find it someday


I like this one better:


people come and people go
sometimes even with a big blow

one is always there and persistent
to keep our poor networks resistant

it is a little man from France
protecting us against aberrance

may he stay there for us
and keep IPCop glorious


Thanks Gilles, on behalf of the IPCop Community, for all that hard work 
you put into IPCop year after year.


IMNSHO calling people, who you hardly know anything about, "disconnected 
from the community" is not in sync with reality.
I know Gilles (personally as well as electronically) and he is very much 
  involved in multipe IPCop Communities, of which you have probably 
never even heard, but which are much more lively then ipcop-user


Olaf

-- 

A weizen a day helps keep the doctor away.