ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: "Eric Oberlander" <eri...@gm...>
To: "IPCop devel" <ipc...@li...>
Sent: Wednesday, September 30, 2009 6:39 PM
Subject: [IPCop-devel] Unable to make root filesystem


> Now I'm having trouble installing from CD, using a build of SVN 3615.
> 
> Unable to make root filesystem
> 
> It partitions the hard drive and fails while running the command:
> /usr/bin/mke2fs -L root -q -j /dev/sda1
> 
> Error messages on Alt-F3 are:
> Done: partition table erased
> Done: parted -s /dev/sda mklabel msdos
> Done: parted -s /dev/sda mkpart primary ext2 63s 768MiB
> Done: parted -s /dev/sda mkpart primary ext2 768MiB 3093MiB
> Done: parted -s /dev/sda set 1 boot on
> Could not stat /dev/sda1 --- No such file or directory
> The device apparently does not exist; did you specify it correctly?
> 
> It might be the hard drive, but it installs earlier versions.
> 
> Any hints at what to look at?
> 
> Eric
> 
Just tested, partitionning work with my hda.

What hard disk controller is on your machine?
I still have an issue with eth2 that got eth2_renamed name during install.

Gilles

Hi Bob,
Bob schrieb:
> Thank you for this info (and for the replies I received via email). Although 
that happens when you do a 'reply to all' - which I forgot with first
reply - therefore you got it twice privately :)
> the Soekris board would seem ideal when I checked the prices it worked out 
> at about 350 UKP here in the UK, so I have ordered a Alix board which is 
> less than half the price of the Soekris. 
> 
> I have also ordered a Wistron CM9 802.11 adaptor. Do you know if there is 
> support for this adaptor in Ipcop2?
not out-of-the-box, but for 1.9.7 there's an updated Wlan-AP package
available which basically works:
http://www.ipcop-forum.de/forum/viewtopic.php?f=22&t=25074
although its in German I guess you can detect the link to the package
close to the top ...

HTH, Gün.

----- Original Message ----- 
From: "Eric Oberlander" <eri...@gm...>
To: "IPCop devel" <ipc...@li...>
Sent: Wednesday, September 30, 2009 6:39 PM
Subject: [IPCop-devel] Unable to make root filesystem


> Now I'm having trouble installing from CD, using a build of SVN 3615.
>
> Unable to make root filesystem
>
> It partitions the hard drive and fails while running the command:
> /usr/bin/mke2fs -L root -q -j /dev/sda1
>
> Error messages on Alt-F3 are:
> Done: partition table erased
> Done: parted -s /dev/sda mklabel msdos
> Done: parted -s /dev/sda mkpart primary ext2 63s 768MiB
> Done: parted -s /dev/sda mkpart primary ext2 768MiB 3093MiB
> Done: parted -s /dev/sda set 1 boot on
> Could not stat /dev/sda1 --- No such file or directory
> The device apparently does not exist; did you specify it correctly?
>
> It might be the hard drive, but it installs earlier versions.
>
> Any hints at what to look at?
>
> Eric
>
If you look at disk-partition script, boot flag has been made successfully.
Next operation are sync,partprobe and a sleep 1 before to create the file
system.
I would try to add some sleep before partprobe. You could eventually edit on
disk during install with vi and restart disk-partition x86 sda <size of
boot> <size of disk>

Gilles

Guenter wrote:

>> I have been looking at installing Ipcop on Soekris net5501 headless board
>> which seems to be possible using my debian system as a PXE install
>> server. It would be simpler if Ipcop supported headless installs so are
>> there any plans for Ipcop to natively support installation with control
>> via a serial terminal.
> sure, and it is already in the net-install package of 1.9.7 - you just
> need to use the *-serial-* pxe boot file ...
> I did that a couple of times already with my Alix boards.

Thank you for this info (and for the replies I received via email). Although 
the Soekris board would seem ideal when I checked the prices it worked out 
at about 350 UKP here in the UK, so I have ordered a Alix board which is 
less than half the price of the Soekris. 

I have also ordered a Wistron CM9 802.11 adaptor. Do you know if there is 
support for this adaptor in Ipcop2?


Bob

Now I'm having trouble installing from CD, using a build of SVN 3615.

Unable to make root filesystem

It partitions the hard drive and fails while running the command:
/usr/bin/mke2fs -L root -q -j /dev/sda1

Error messages on Alt-F3 are:
Done: partition table erased
Done: parted -s /dev/sda mklabel msdos
Done: parted -s /dev/sda mkpart primary ext2 63s 768MiB
Done: parted -s /dev/sda mkpart primary ext2 768MiB 3093MiB
Done: parted -s /dev/sda set 1 boot on
Could not stat /dev/sda1 --- No such file or directory
The device apparently does not exist; did you specify it correctly?

It might be the hard drive, but it installs earlier versions.

Any hints at what to look at?

Eric

Hi Bob,
Bob schrieb:
> I have been looking at installing Ipcop on Soekris net5501 headless board 
> which seems to be possible using my debian system as a PXE install server. 
> It would be simpler if Ipcop supported headless installs so are there any 
> plans for Ipcop to natively support installation with control via a serial 
> terminal.
sure, and it is already in the net-install package of 1.9.7 - you just
need to use the *-serial-* pxe boot file ...
I did that a couple of times already with my Alix boards.

Günter.

Hi

I have been looking at installing Ipcop on Soekris net5501 headless board 
which seems to be possible using my debian system as a PXE install server. 
It would be simpler if Ipcop supported headless installs so are there any 
plans for Ipcop to natively support installation with control via a serial 
terminal.

Thanks

Bob Brewer

Feature Requests item #2869166, was opened at 2009-09-28 22:18
Message generated for change (Tracker Item Submitted) made by waw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=2869166&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: John Seifarth (waw)
Assigned to: Nobody/Anonymous (nobody)
Summary: URL Filter and update accelerator

Initial Comment:
Will url filter (http://www.urlfilter.net) be included in IPCop 2.0 as well as the advanced proxy? Another extremely useful add-on is update accelerator (http://update-accelerator.advproxy.net). Will it be incorporated into 2.0 ? The three plugins were designed to work together, and have worked very well for me in IPCop 1.4.21

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

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

Bugs item #2869126, was opened at 2009-09-28 21:29
Message generated for change (Tracker Item Submitted) made by fedys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2869126&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: V2 alpha
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Fedor Sacksen (fedys)
Assigned to: Nobody/Anonymous (nobody)
Summary: udevd error prevents interfaces to be configured

Initial Comment:
With sources from 19.09. everything is fine, but with sources from 26.09 the following error occures during boot:

udevd-work[522]: error changing netif name eth1 to _rename File exists
Starting interface GREEN      FAIL

The same with eth2

ifconfig has only the RED interface, no 'lo' or other interfaces.


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

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

Olaf Westrik wrote:
> David W Studeman wrote:
>> Some changes in the SVN tree recently broke the HDD section of sysinfo. 
>> I can't see why as the sysinfo.c and sysinfo.cgi files have not changed 
>> recently. 
> 
> Probably one of the changes in udev/e2fsprogs/util-linux-ng and the 
> reshuffling of files in initramfs.
> You may have been hit even if you do not have initramfs.
> 
> My guess is that you no longer have /dev/disk/by-label/root.
> 
> Since we current SVN has some problems with the latest udev and some 
> other related udev things, best is to fix that first and then see if the 
> harddisk info comes back.
> 
> 
> Olaf

That explains a lot. It was working not long ago. I agree, best to fix 
what really needs fixing first and see. Other than the lack of a normal 
bios, and the inability to use an initrd much less a boot loader, there 
really is no reason a Cobalt x86 should show hard drive info any different.


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

David W Studeman wrote:
> Some changes in the SVN tree recently broke the HDD section of sysinfo. 
> I can't see why as the sysinfo.c and sysinfo.cgi files have not changed 
> recently. 

Probably one of the changes in udev/e2fsprogs/util-linux-ng and the 
reshuffling of files in initramfs.
You may have been hit even if you do not have initramfs.

My guess is that you no longer have /dev/disk/by-label/root.

Since we current SVN has some problems with the latest udev and some 
other related udev things, best is to fix that first and then see if the 
harddisk info comes back.


Olaf

Some changes in the SVN tree recently broke the HDD section of sysinfo. 
I can't see why as the sysinfo.c and sysinfo.cgi files have not changed 
recently. I came up with this patch that does work provided that you 
really are booting up with /dev/hda. The only machine you wouldn't be 
booting /dev/hda is the Raq XTR which is way too big and holds too many 
drives to waste it on a firewall appliance, the XTR boots from /dev/hde. 
Anyway, here is the patch I just cobbled up:

--- sysinfo.cgi	2009-09-27 19:45:59.772719329 -0700
+++ sysinfo-cobalt.cgi	2009-09-27 19:54:31.712719620 -0700
@@ -182,6 +182,18 @@

  print "<a name='hdd'/>\n";
  &Header::openbox('100%', 'left', "$Lang::tr{'system info hdd'}:");
+if (-e "/proc/cobalt") {
+      my $outputhdd = `/usr/local/bin/sysinfo -d hda`;
+      $outputhdd = &Header::cleanhtml($outputhdd);
+      print "<pre>";
+       (@lines) = split(/\n/, $outputhdd);
+       my $counter = 0;
+       foreach my $line ( @lines )
+       {
+         print $line."\r" if ( $counter++ > 2);
+       }
+      print "</pre>\n";
+   }
  if (-e "/proc/mdstat") {
      $i = 0;
      open(MDADM, "/usr/local/bin/sysinfo --raid=md0 |");

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

2009/9/27 Olaf Westrik <wei...@ip...>:
> Eric Oberlander wrote:
>
>>> -----------
>>> Start RED at the end from rc.sysinit.
>>> TODO: find a way to use ntpdate for quicker ntp synchronisation after
>>> first RED connection.
>>
>> How about this?
>>
>> At the end of ip-up, look for a 'flagfile' in /tmp, and if it does NOT
>> exist, do a restartntpd -force
>> Then create the 'flagfile' in /tmp
>>
>> I'm assuming that files get wiped from /tmp on boot. If not, delete
>> the 'flagfile' in rc.sysinit
>
>
> We could also do something like this:
> rc.sysinit touches /var/run/ntpdate-red (or something like that)
> rc.updatered runs restartntpd --red
>
> restartntpd first checks whether ENABLED_NTPD is set (of course ;-))
> ntpdate is run when:
> - started with --force
> - started with --red and ntpdate-red file is present, after which the file
> is removed

Yes, that makes sense.

I've been trialling a script in my copy of rc.event.local, and I had
to add a 'sleep 5' in front of the the 'restartntpd -f' command.
Presumably the red interface hadn't settled down quickly enough, or it
was my hardware...

You might want to check this too.

Eric

Eric Oberlander wrote:

>> -----------
>> Start RED at the end from rc.sysinit.
>> TODO: find a way to use ntpdate for quicker ntp synchronisation after first RED connection.
> 
> How about this?
> 
> At the end of ip-up, look for a 'flagfile' in /tmp, and if it does NOT
> exist, do a restartntpd -force
> Then create the 'flagfile' in /tmp
> 
> I'm assuming that files get wiped from /tmp on boot. If not, delete
> the 'flagfile' in rc.sysinit


We could also do something like this:
rc.sysinit touches /var/run/ntpdate-red (or something like that)
rc.updatered runs restartntpd --red

restartntpd first checks whether ENABLED_NTPD is set (of course ;-))
ntpdate is run when:
- started with --force
- started with --red and ntpdate-red file is present, after which the 
file is removed


Olaf

Bugs item #2868194, was opened at 2009-09-27 18:21
Message generated for change (Tracker Item Submitted) made by fedys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2868194&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: V2 alpha
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Fedor Sacksen (fedys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Forwarding of special port fails in iptables nat

Initial Comment:
Trying to forward a special port (eg.26999) to an internal service port (eg. 80 http) fails.
'Use source port' is selected at the rule definition page and the port is correctly shown in the config file (var/ipcop/firewall: 11th position of the CSV string).

'iptables -t nat -L' shows a destination 'provider.de tcp dtp:http to target_ip:80'.

Sources are from 19.09.2009

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

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

On 25 Sep 2009, at 21:05, ow...@us... wrote:

> -----------
> Start RED at the end from rc.sysinit.
> TODO: find a way to use ntpdate for quicker ntp synchronisation after first RED connection.

How about this?

At the end of ip-up, look for a 'flagfile' in /tmp, and if it does NOT
exist, do a restartntpd -force
Then create the 'flagfile' in /tmp

I'm assuming that files get wiped from /tmp on boot. If not, delete
the 'flagfile' in rc.sysinit

Eric
.

Gilles Espinasse wrote:

> Brian Kadzban has posted various patches on linux-hotplug as a solution to
> sys/signalfd.h
> http://article.gmane.org/gmane.linux.hotplug.devel/14081
> http://marc.info/?l=linux-hotplug&m=124776148705775&w=2

After some minor modifications udev 146 builds.
I can also install but booting the final system fails to load udevd.
Complaining about some relocation error in libc, might be link failure.

Sigh. Booting a system without udevd is not an easy task so not sure 
what is the problem exactly :-(

Patches for udev 146 attached

Olaf

Selon ow...@us...:

> Revision: 3594
>           http://ipcop.svn.sourceforge.net/ipcop/?rev=3594&view=rev
> Author:   owes
> Date:     2009-09-25 08:58:13 +0000 (Fri, 25 Sep 2009)
>
> Log Message:
> -----------
> Upgrade e2fsprogs to 1.41.9 and util-linux-ng to 2.16.1
> Building order is changed slightly, as e2fsprogs now depends on util-linux.
>
> I think we can drop e2fsprogs from the toolchain, but this needs
> verification.
>
Yes e2fsprogs is dropped on LFS-6.5 toolchain
http://linuxfromscratch.org/pipermail/lfs-dev/2009-July/062970.html
utils-linux-ng too is not build on toolchain stage.

Gilles


Gilles

Gilles Espinasse wrote:

>>> Should we not have all our installer specific variables in capital?
>> You mean nousb, nombr and such variables?
>>
> Yes

OK.
We can document uppercase variables in manual and installer help 
screens. And accept both upper- and lowercase versions in the installer.
I will change installer.


>>> Concerning udev upgrade, I noticed that a newer libblkid from
> util-linux-ng is
>>> required in udev-142. So we should upgrade first util-linux-ng (and
> e2fsprogs)
>>> to have the newer libblkid. Not tested at all.
>> I have managed to upgrade e2fsprogs to 1.41.9 and util-linux-ng to
>> 2.16.1. Required some configure modifications for e2fsprogs and
>> reordering in make.sh.
>> Still fighting with the modifications for the toolchain.

I think I got it, doing a full rebuild to verify.
util-linux-ng needs 'shrinking' by using some ./configure magic and can 
then be installed normally using make && make install.
Looks like e2fsprogs can be dropped from the toolchain.


> Brian Kadzban has posted various patches on linux-hotplug as a solution to
> sys/signalfd.h
> http://article.gmane.org/gmane.linux.hotplug.devel/14081
> http://marc.info/?l=linux-hotplug&m=124776148705775&w=2

Ah, nice thanks.
I will see if this applies and works after upgrading e2fsprogs and 
util-linux-ng.


Olaf

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCop devel" <ipc...@li...>
Sent: Thursday, September 24, 2009 7:03 PM
Subject: Re: [Ipcop-svn] SF.net SVN: ipcop:[3586] ipcop/trunk


> Gilles Espinasse wrote:
>
> > Not yet send what I discover with udev.
> > On 16 attempts I register udevadm settle duration:
> > - it take 5 s in 12 attempt
> > - it take 112 s in 4 attempt
>
> I have seen udevadm settle taking more than 15 minutes after which I
> gave up waiting.
>
>
> > I have added an easy way on init script to register on an usb key
whatever log
> > you want. You just need to add on the kernel line DEBUGDEV=sda to have a
log
> > created on init script saved to sda key.
> > If DEBUGDEV does not exist, nothing is made.
> > I think that could be helpfull.
>
> Yes.
> Early in the boot process can be fairly difficult, as there are no other
> consoles available.
>
I have attached the change I made for comment.
I had just some date >>/udev.log before to fill my simple log file.

>
> > Should we not have all our installer specific variables in capital?
>
> You mean nousb, nombr and such variables?
>
Yes
>
> > I have now another issue wich I think is udev related, not sure it is in
all
> > attempt yet :
> > first card with e100 driver that I pxe-boot from, is renamed to
eth1_rename
> > second card with 8139too appear as eth0
> > third card with n2kpci appear as eth1
> > Then everything went wrong, because boot interface is not detected and
installer
> > try to 'ifconfig 192.168.... up (the boot ip) without an interface name.
> > And installer think eth2 exist but it does not appear in /sys/class/net,
only
> > eth1_rename.
> > I don't know why the rename happen
>
> I saw an error message on 1 attempt, something like failed to rename to
> eth0_rename.
>
Reading linux-hotplug mailing list, I find a similar case rename error :
http://marc.info/?l=linux-hotplug&m=125062902125925&w=2
>
> > Concerning udev upgrade, I noticed that a newer libblkid from
util-linux-ng is
> > required in udev-142. So we should upgrade first util-linux-ng (and
e2fsprogs)
> > to have the newer libblkid. Not tested at all.
>
> I have managed to upgrade e2fsprogs to 1.41.9 and util-linux-ng to
> 2.16.1. Required some configure modifications for e2fsprogs and
> reordering in make.sh.
> Still fighting with the modifications for the toolchain.
>
>
> Olaf

Brian Kadzban has posted various patches on linux-hotplug as a solution to
sys/signalfd.h
http://article.gmane.org/gmane.linux.hotplug.devel/14081
http://marc.info/?l=linux-hotplug&m=124776148705775&w=2

Gilles

Gilles Espinasse wrote:

> Not yet send what I discover with udev.
> On 16 attempts I register udevadm settle duration:
> - it take 5 s in 12 attempt
> - it take 112 s in 4 attempt

I have seen udevadm settle taking more than 15 minutes after which I 
gave up waiting.


> I have added an easy way on init script to register on an usb key whatever log
> you want. You just need to add on the kernel line DEBUGDEV=sda to have a log
> created on init script saved to sda key.
> If DEBUGDEV does not exist, nothing is made.
> I think that could be helpfull.

Yes.
Early in the boot process can be fairly difficult, as there are no other 
consoles available.


> Should we not have all our installer specific variables in capital?

You mean nousb, nombr and such variables?


> I have now another issue wich I think is udev related, not sure it is in all
> attempt yet :
> first card with e100 driver that I pxe-boot from, is renamed to eth1_rename
> second card with 8139too appear as eth0
> third card with n2kpci appear as eth1
> Then everything went wrong, because boot interface is not detected and installer
> try to 'ifconfig 192.168.... up (the boot ip) without an interface name.
> And installer think eth2 exist but it does not appear in /sys/class/net, only
> eth1_rename.
> I don't know why the rename happen

I saw an error message on 1 attempt, something like failed to rename to 
eth0_rename.


> Concerning udev upgrade, I noticed that a newer libblkid from util-linux-ng is
> required in udev-142. So we should upgrade first util-linux-ng (and e2fsprogs)
> to have the newer libblkid. Not tested at all.

I have managed to upgrade e2fsprogs to 1.41.9 and util-linux-ng to 
2.16.1. Required some configure modifications for e2fsprogs and 
reordering in make.sh.
Still fighting with the modifications for the toolchain.


Olaf

Selon Olaf <mai...@ba...>:

> Hello Gilles,
>
>
> > Split display for udevd start and udevadm.
> > There is a bug in udevadm actually, and better show where the problem is.
> > More on that later.
> >
>
> Maybe related: I have been trying for some time to upgrade udev to more
> recent version (146).
> That fails because of missing sys/signalfd.h. I have no idea yet why we
> do not have that file.
> There is a Gentoo report http://bugs.gentoo.org/show_bug.cgi?id=281520
> but we have glibc 2.7 ?
>
> sigh.
>
> Olaf
>
Not yet send what I discover with udev.
On 16 attempts I register udevadm settle duration:
- it take 5 s in 12 attempt
- it take 112 s in 4 attempt

I have added an easy way on init script to register on an usb key whatever log
you want. You just need to add on the kernel line DEBUGDEV=sda to have a log
created on init script saved to sda key.
If DEBUGDEV does not exist, nothing is made.
I think that could be helpfull.

Should we not have all our installer specific variables in capital?


Sorry for the bad quality of my changes.
I think some of the changes I have made have not been commited when they should
have been.
Not sure of the reason, maybe I copy a bad file versions, maybe that may have
been my method with some of the changes made. I was thinking to have used
find src/installer/* -maxdepth 0 -exec sed -i
But it look sometime -maxdepth may have been omitted and files under .svn have
been modified and in that case svn diff think the files have not been modified
even if they are different from server repository.

I have now another issue wich I think is udev related, not sure it is in all
attempt yet :
first card with e100 driver that I pxe-boot from, is renamed to eth1_rename
second card with 8139too appear as eth0
third card with n2kpci appear as eth1
Then everything went wrong, because boot interface is not detected and installer
try to 'ifconfig 192.168.... up (the boot ip) without an interface name.
And installer think eth2 exist but it does not appear in /sys/class/net, only
eth1_rename.
I don't know why the rename happen

Concerning udev upgrade, I noticed that a newer libblkid from util-linux-ng is
required in udev-142. So we should upgrade first util-linux-ng (and e2fsprogs)
to have the newer libblkid. Not tested at all.

Gilles

> Achim, can you remember the reasons to not have the ability to choose 
> DROP/ACCEPT/REJECT on RED interface?
> Or was it wanting to keep things simple?
> 
> 
> Olaf

Ups, this should be possible. Will look into it...

Ahim

David W Studeman wrote:
> As far as the RTC battery, I think some of us might neglect our 
> batteries a bit much. I never have bought one but I think even my local 
> grocery store has them not far from the gum and breath mints. What next? 
> USB sticks on a rack by the cash register?
>
>   

Come on Dave, that's so last week.  :)  Then I suppose not everyone out 
there buys their groceries at Fry's, so it could take a while to trickle 
down.  :)

later...

Melvin

Bugs item #2862576, was opened at 2009-09-20 13:10
Message generated for change (Tracker Item Submitted) made by fedys
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=2862576&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: User Interface
Group: V2 alpha
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jan Fedor Sacksen (fedys)
Assigned to: Nobody/Anonymous (nobody)
Summary: fwrules.cgi: False Ruletype

Initial Comment:
When clicking the up or down arrow of the port-forwarding section, I get the following error: "false Ruletype at /home/httpd/cgi-bin/fwrules.cgi line 341."

The sources are from 13th September.

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

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