On Wed, Mar 26, 2008 at 05:14:13PM +0100, Gilles Espinasse wrote:
> Selon John Edwards <john@...>:
>> On Wed, Mar 26, 2008 at 03:24:52PM +0100, Gilles Espinasse wrote:
>>> we are there talking about gadget features rarely used when nobody
>>> has time to work on our high priority features completion.
>> I am talking about having a kernel+initrd that will boot on more than
>> one configuration of machine. To me it a fundemental feature not to
>> make software that only works on a particular set of hardware.
>> IPCop 1.4 could boot if you changed the hardware, so I feel that if
>> the boot fails when the hardware changes then we are going backwards.
>> And backward into a dangerous dead-end.
> that's true for IDE only with driver built-in.
> For an scsi disk, you would have to keep the same controller driver.
I understand that this is easier in IPCop 1.4 because it doesn't
support the wide range of hardware the we want to use in IPCop 2.0.
But it shows that it is possible.
Other Linux systems do this. Do we think it is not possible or not
worth the effort?
>>> John Edwards <john@...> 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.
>>> when you add 4.3 MB to the initrd, you mostly add three time that
>>> size in the free space requirement to be able to install an update
>> Not true.
>> If we rebuild the initrd using mkinitramfs then we need some temp
>> space for the uncompressed files. At the moment this is in /tmp, which
>> in IPCop 2.0 is tmpfs and uses RAM not disk space.
>>> That may not be
>>> a problem if initrd is packaged separatly from other parts but package
>>> management is not yet there.
>> What do you mean by "packaged separately"? The initrd is not packaged
>> at all - it is built by mkinitramfs. Though at the moment the only
>> way to do this is during the install.
> My error, too much time with 1.4, time to have something newer.
Now does anyone have a good reason why we shouldn't include more
modules in the initrd?
One possible reason is disk space, but I hope the following will show
that a larger initrd is not the major problem here.
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
Increasing the boot partition to 24 MB would give room for 2 kernels +
large initrds, or 32 MB for 3. Assuming max of 3 kernels (King, an
heir and a spare), we have:
Boot = 32 MB
Root (excluding swap file) = 144 MB (min of 128 MB)
Swap file = 48 MB (min of 32 MB)
Logs = 32 MB
Which is probably not enough log space for a heavily used firewall.
But I also think 40 MB is not enough and we may need to increase the
minimum hard disk size to 350 or 400 MB. One of my firewalls that gets
heavily hammered has 190 MB on the log partiton for the year, and it
doesn't run snort or Squid.
This is not so much of a problem for 256 MB flash systems as they hold
their log files in RAM. Compressed log files are between 5 and 10
But back to the point - why are we planning to make IPCop only work on
the particular set of hardware that it was installed on?
| John Edwards Email: john@... |