devil-linux-develop Mailing List for Devil-Linux (Page 29)

Quoting Bruce Smith <bw...@re...>:

> Has anyone tried an ext4 filesystem in 1.4RC1?
>
> I see the binary "mkfs.ext4" exists, but I haven't tried it myself yet.
>
> I just want to make sure it works in DL since it seems like many other
> distro's are moving to ext4.  Ubuntu 9.04 includes ext4 as an option
> during installation, and the next release of OpenSuSE will make ext4
> their default FS.

There are a few bugs which are supposed to be fixed in 2.6.30, I'd  
wait at least for that kernel for production use.


-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Has anyone tried an ext4 filesystem in 1.4RC1?

I see the binary "mkfs.ext4" exists, but I haven't tried it myself yet.

I just want to make sure it works in DL since it seems like many other
distro's are moving to ext4.  Ubuntu 9.04 includes ext4 as an option
during installation, and the next release of OpenSuSE will make ext4
their default FS.

  - BS

Quoting Serge Leschinsky <fi...@in...>:

> Heiko,
>
> To fix the problem we should modify ELF section of grub binary. It  
> can be done
> either by paxctl or shpax utility. I see script for chpax in the  
> repository but
> it's enabled for 2.4 kernel only. I've checked PaX homepage and  
> paxctl seems to
> be a new replacement of shpax. So, I suggest using paxctl and remove shpax's
> script.
> I need your advice because my grsec experience is zero.

Would the 'scanelf' utility help any? We got that included already.
Other then that I'd just go by what you saw on the grsecurity website.  
It's a very long time ago since I played with those utilities.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko,

To fix the problem we should modify ELF section of grub binary. It can be done
either by paxctl or shpax utility. I see script for chpax in the repository but
it's enabled for 2.4 kernel only. I've checked PaX homepage and paxctl seems to
be a new replacement of shpax. So, I suggest using paxctl and remove shpax's
script.
I need your advice because my grsec experience is zero.

Serge

roy barnard wrote:
> Hi,
> 
> I just wondered, as no-one has replied, if I am the one one with this issue?
> 
> Many Thanks
> Roy.
> 
> PS Hope sending a reply to my own mail is acceptable :-)
> 
> 
> --- On Thu, 14/5/09, roy barnard <roy...@ya...> wrote:
> 
>> From: roy barnard <roy...@ya...>
>> Subject: [Devil-linux-develop] DL-1.4RC1-2009-05-12 Grub Installation on USB mounted Flash Card issue and workaround
>> To: dev...@li...
>> Date: Thursday, 14 May, 2009, 6:06 PM
>>
>> Hi,
>>
>> I have been having grub installation issues with the 1.3.7
>> and 1.4 Release streams.  I have just reproduced the
>> same issue with 1.4RC1-2009-05-12.
>>
>> What I have established is that the 'install-on-usb' script
>> when used to install to a Flash Card accessed via a /dev/sda
>> (or as applicable), the script calls grub using a shell
>> script variable:
>>
>>  
>>    grub_shell=$TMPDIR/iso-mnt/sbin/grub
>>
>> This gives (dependant on DL release) one of two types of
>> error either grub crashes or the grub fails to install
>> properbly complaining about a device mapping and/or LVM
>> issue.
>>
>> The system being used to install DL onto the flash Card
>> is:
>>
>> CentOS release 4.4 (Final)
>> With Kernal 2.6.9-42.0.8 #1 SMP i686 i386 
>> IDE HardDisk (Non-SCSI system) installed without LVM
>> configured.
>>
>> My workaround for this issue is to change the
>> 'install-on-usb' line from the above to the following:
>>      grub_shell=/sbin/grub
>>
>> I believe that this means that the Grub being installed is
>> the one from CentOS NOT the Grub shipped as part of DL.
>>
>> I appreciate that this is not a good long term fix but it
>> is allowing me to roll out 20 Internal OpenVPN Firewalls
>> using Devil Linux 1.4RC1 :-)
>>
>> I am willing to do any testing you might need in providing
>> a better solution, but I am happy with my current
>> <strikeout>fudge</strikeout> workaround shown
>> here.
>>
>> I would be interested if anyone else has found similar
>> issues and any better fixes for this grub issue.
>>
>> Thanks for all the good work
>>
>> Roy Barnard
>>
>>
>>
>>       
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY
>> circumstances! Your
>> production scanning environment may not be a perfect world
>> - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With
>> the NEW KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with
>> all image 
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 

Hi Roy,

Thanks for attracting our attention to the problem. Hopefully it will be fixed
in RC2. I did some test and it looks solvable.

Sincerely,
Serge

roy barnard wrote:
> Hi,
> 
> I just wondered, as no-one has replied, if I am the one one with this issue?
> 
> Many Thanks
> Roy.
> 
> PS Hope sending a reply to my own mail is acceptable :-)
> 

Hi Roy,

you are not the one who faced the problem. I'm afraid anyone have the same
problem. The root source of it is grsecurity. I'd suggest using syslinux loader
in case of grsec enabled version of DL and any loader (grub,syslinux) for DL
builds without grsec.

Thank you for the feedback,

Serge

roy barnard wrote:
> Hi,
> 
> I just wondered, as no-one has replied, if I am the one one with this issue?
> 
> Many Thanks
> Roy.
> 
> PS Hope sending a reply to my own mail is acceptable :-)
> 
> 
> --- On Thu, 14/5/09, roy barnard <roy...@ya...> wrote:
> 
>> From: roy barnard <roy...@ya...>
>> Subject: [Devil-linux-develop] DL-1.4RC1-2009-05-12 Grub Installation on USB mounted Flash Card issue and workaround
>> To: dev...@li...
>> Date: Thursday, 14 May, 2009, 6:06 PM
>>
>> Hi,
>>
>> I have been having grub installation issues with the 1.3.7
>> and 1.4 Release streams.  I have just reproduced the
>> same issue with 1.4RC1-2009-05-12.
>>
>> What I have established is that the 'install-on-usb' script
>> when used to install to a Flash Card accessed via a /dev/sda
>> (or as applicable), the script calls grub using a shell
>> script variable:
>>
>>  
>>    grub_shell=$TMPDIR/iso-mnt/sbin/grub
>>
>> This gives (dependant on DL release) one of two types of
>> error either grub crashes or the grub fails to install
>> properbly complaining about a device mapping and/or LVM
>> issue.
>>
>> The system being used to install DL onto the flash Card
>> is:
>>
>> CentOS release 4.4 (Final)
>> With Kernal 2.6.9-42.0.8 #1 SMP i686 i386 
>> IDE HardDisk (Non-SCSI system) installed without LVM
>> configured.
>>
>> My workaround for this issue is to change the
>> 'install-on-usb' line from the above to the following:
>>      grub_shell=/sbin/grub
>>
>> I believe that this means that the Grub being installed is
>> the one from CentOS NOT the Grub shipped as part of DL.
>>
>> I appreciate that this is not a good long term fix but it
>> is allowing me to roll out 20 Internal OpenVPN Firewalls
>> using Devil Linux 1.4RC1 :-)
>>
>> I am willing to do any testing you might need in providing
>> a better solution, but I am happy with my current
>> <strikeout>fudge</strikeout> workaround shown
>> here.
>>
>> I would be interested if anyone else has found similar
>> issues and any better fixes for this grub issue.
>>
>> Thanks for all the good work
>>
>> Roy Barnard

Hi,

I just wondered, as no-one has replied, if I am the one one with this issue?

Many Thanks
Roy.

PS Hope sending a reply to my own mail is acceptable :-)


--- On Thu, 14/5/09, roy barnard <roy...@ya...> wrote:

> From: roy barnard <roy...@ya...>
> Subject: [Devil-linux-develop] DL-1.4RC1-2009-05-12 Grub Installation on USB mounted Flash Card issue and workaround
> To: dev...@li...
> Date: Thursday, 14 May, 2009, 6:06 PM
> 
> Hi,
> 
> I have been having grub installation issues with the 1.3.7
> and 1.4 Release streams.  I have just reproduced the
> same issue with 1.4RC1-2009-05-12.
> 
> What I have established is that the 'install-on-usb' script
> when used to install to a Flash Card accessed via a /dev/sda
> (or as applicable), the script calls grub using a shell
> script variable:
> 
>  
>    grub_shell=$TMPDIR/iso-mnt/sbin/grub
> 
> This gives (dependant on DL release) one of two types of
> error either grub crashes or the grub fails to install
> properbly complaining about a device mapping and/or LVM
> issue.
> 
> The system being used to install DL onto the flash Card
> is:
> 
> CentOS release 4.4 (Final)
> With Kernal 2.6.9-42.0.8 #1 SMP i686 i386 
> IDE HardDisk (Non-SCSI system) installed without LVM
> configured.
> 
> My workaround for this issue is to change the
> 'install-on-usb' line from the above to the following:
>      grub_shell=/sbin/grub
> 
> I believe that this means that the Grub being installed is
> the one from CentOS NOT the Grub shipped as part of DL.
> 
> I appreciate that this is not a good long term fix but it
> is allowing me to roll out 20 Internal OpenVPN Firewalls
> using Devil Linux 1.4RC1 :-)
> 
> I am willing to do any testing you might need in providing
> a better solution, but I am happy with my current
> <strikeout>fudge</strikeout> workaround shown
> here.
> 
> I would be interested if anyone else has found similar
> issues and any better fixes for this grub issue.
> 
> Thanks for all the good work
> 
> Roy Barnard
> 
> 
> 
>       
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY
> circumstances! Your
> production scanning environment may not be a perfect world
> - but thanks to
> Kodak, there's a perfect scanner to get the job done! With
> the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with
> all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 


      

I tried sending from my google apps account, and a hotmail account.
Both bounced.

I also tried sending to your smiley73 at sourceforge, and that bounced too.

Here is the bounce message from google:

"Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.1.1 <he...@zu...>:
Recipient address rejected: User unknown in virtual alias table (state
14)."

 - BS


On Tue, May 26, 2009 at 12:16, Heiko Zuerker <he...@zu...> wrote:
> Quoting Bruce Smith <bw...@re...>:
>
>> I've been trying to contact Heiko since yesterday and everything sent
>> to his email is bouncing.
>>
>> Does anyone have any other way to contact him, like an another email
>> address or a phone number?  If so, please email me privately.
>
> You're the 2nd person having issues.
> How do the emails bounce? Can you get me the details?
>
> I'm currently messing with DKIM and SPF and hope that's note causing issues.
>
> --
>
> Regards
>   Heiko Zuerker
>   http://www.devil-linux.org
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 
  - BS

Quoting Bruce Smith <bw...@re...>:

> I've been trying to contact Heiko since yesterday and everything sent
> to his email is bouncing.
>
> Does anyone have any other way to contact him, like an another email
> address or a phone number?  If so, please email me privately.

You're the 2nd person having issues.
How do the emails bounce? Can you get me the details?

I'm currently messing with DKIM and SPF and hope that's note causing issues.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

I've been trying to contact Heiko since yesterday and everything sent
to his email is bouncing.

Does anyone have any other way to contact him, like an another email
address or a phone number?  If so, please email me privately.

Thanks!

  - BS

Hi,

I have been having grub installation issues with the 1.3.7 and 1.4 Release streams.  I have just reproduced the same issue with 1.4RC1-2009-05-12.

What I have established is that the 'install-on-usb' script when used to install to a Flash Card accessed via a /dev/sda (or as applicable), the script calls grub using a shell script variable:

     grub_shell=$TMPDIR/iso-mnt/sbin/grub

This gives (dependant on DL release) one of two types of error either grub crashes or the grub fails to install properbly complaining about a device mapping and/or LVM issue.

The system being used to install DL onto the flash Card is:

CentOS release 4.4 (Final)
With Kernal 2.6.9-42.0.8 #1 SMP i686 i386 
IDE HardDisk (Non-SCSI system) installed without LVM configured.

My workaround for this issue is to change the 'install-on-usb' line from the above to the following:
     grub_shell=/sbin/grub

I believe that this means that the Grub being installed is the one from CentOS NOT the Grub shipped as part of DL.

I appreciate that this is not a good long term fix but it is allowing me to roll out 20 Internal OpenVPN Firewalls using Devil Linux 1.4RC1 :-)

I am willing to do any testing you might need in providing a better solution, but I am happy with my current <strikeout>fudge</strikeout> workaround shown here.

I would be interested if anyone else has found similar issues and any better fixes for this grub issue.

Thanks for all the good work

Roy Barnard



      

Bruce,

Bruce Smith wrote:
>> - rollback kernel to 2.6.29.2 due to troubles with grsecurity
> 
> Hey Serge,
> 
> Is grsecurity the only problem with 2.6.29.3?
> 
> I compiled a "server" version last night (no grsec) with 2.6.29.3.
> Do I need to worry about anything?
No. grsecurity is the only problem with 2.6.29.3. I hope new grsecurity version
will be ready soon and we will be able to update kernel to the latest patch.

I'm sorry for inconvenience

Serge

> - rollback kernel to 2.6.29.2 due to troubles with grsecurity

Hey Serge,

Is grsecurity the only problem with 2.6.29.3?

I compiled a "server" version last night (no grsec) with 2.6.29.3.
Do I need to worry about anything?

 - BS

Done

Serge Leschinsky wrote:
> OOps. My fault. Give me 2 min to fix it.
> 
> Serge
> 
> Bruce Smith wrote:
>> ...
>> Verifying md5 checksums
>> src/atl2-2.0.5.tar.bz2: FAILED open or read
>> src/patch-2.6.29.2.bz2: FAILED open or read

OOps. My fault. Give me 2 min to fix it.

Serge

Bruce Smith wrote:
> ...
> Verifying md5 checksums
> src/atl2-2.0.5.tar.bz2: FAILED open or read
> src/patch-2.6.29.2.bz2: FAILED open or read
\

...
Verifying md5 checksums
src/atl2-2.0.5.tar.bz2: FAILED open or read
src/patch-2.6.29.2.bz2: FAILED open or read

WARNING: The following files exist in directory "src/"
         BUT do not have a md5sum listed in md5sum.lst!

src/patch-2.6.29.3.bz2


 - BS

Hi Bruce,

Bruce Smith wrote:

> 
> Is there an advantage of one over the other?
> Should I switch 'server' to use initramfs too?
> 
initramfs is a "new trends" of Linux distributions. It allows to avoid ramdisk
(block device) creation and saves several bytes(megabytes) of ram. I'd suggest
using initramfs by default...


Serge

I was comparing the default & server profiles, and I noticed that
'default' uses Initramfs for InitRD and 'server' uses ext2.  I can't
remember why I selected ext2 for the server profile in the first
place.

Is there an advantage of one over the other?
Should I switch 'server' to use initramfs too?

Thanks!

  - BS

Thanks for the information.
I downloaded the patch and will upload it to the build system with my  
next check in.

Heiko

Quoting Andrzej Odyniec <an...@ma...>:

> Hi,
>
> Now last 0.99.11 Quagga is practically unusable, because now is in broadcast
> prefix with very long path of 4-byte ASN path. When this prefix is received,
> bgpd (last, 0.99.11, in 1.4RC1) crashes like this:
>
>> 2009/05/03 19:27:30 notifications: BGP: BGPd 0.99.11-realms  
>> starting: vty@2605, bgp@<all>:179
>> 2009/05/03 19:27:35 errors: BGP: 195.187.251.225 [Error]  
>> bgp_read_packet error: Connection reset by peer
>> 2009/05/03 19:27:57 critical: BGP: Assertion `len < str_size'  
>> failed in file bgp_aspath.c, line 619, function aspath_make_str_count
>> 2009/05/03 19:27:57 critical: BGP: Backtrace for 14 stack frames:
>> 2009/05/03 19:27:57 critical: BGP: [bt 0]  
>> /usr/lib/libzebra.so.0(zlog_backtrace+0x34) [0x4f51e7ab]
>> 2009/05/03 19:27:57 critical: BGP: [bt 1]  
>> /usr/lib/libzebra.so.0(_zlog_assert_failed+0xb5) [0x4f51e947]
>> 2009/05/03 19:27:57 critical: BGP: [bt 2] /usr/sbin/bgpd [0x119ea440]
>> 2009/05/03 19:27:57 critical: BGP: [bt 3] /usr/sbin/bgpd [0x119ea4aa]
>> 2009/05/03 19:27:57 critical: BGP: [bt 4] /usr/sbin/bgpd [0x119ea4f5]
>> 2009/05/03 19:27:57 critical: BGP: [bt 5]  
>> /usr/lib/libzebra.so.0(hash_get+0x39) [0x4f513c4b]
>> 2009/05/03 19:27:57 critical: BGP: [bt 6] /usr/sbin/bgpd [0x119ebb63]
>> 2009/05/03 19:27:57 critical: BGP: [bt 7] /usr/sbin/bgpd [0x119a7144]
>> 2009/05/03 19:27:57 critical: BGP: [bt 8] /usr/sbin/bgpd [0x119c7e35]
>> 2009/05/03 19:27:57 critical: BGP: [bt 9]  
>> /usr/sbin/bgpd(bgp_read+0x438) [0x119c9317]
>> 2009/05/03 19:27:57 critical: BGP: [bt 10]  
>> /usr/lib/libzebra.so.0(thread_call+0x69) [0x4f50f5b5]
>> 2009/05/03 19:27:57 critical: BGP: [bt 11]  
>> /usr/sbin/bgpd(main+0x38c) [0x11997b05]
>> 2009/05/03 19:27:57 critical: BGP: [bt 12]  
>> /lib/libc.so.6(__libc_start_main+0x157) [0x4f1b1ff3]
>> 2009/05/03 19:27:57 critical: BGP: [bt 13] /usr/sbin/bgpd [0x11997521]
>
> and propagated via BGP addresses are absent in the Internet. After restart
> bgpd starts new sessions, obtain this ugly prefix again and again crashes
> immediatelly.
>
> I'm not sure, but seems as problem like this is present in other routing
> systems. After solving this problem in transit routers (i.e. via router
> replacement), this path is propagated to the next neibors and today  
> or tomorow
> can crash more BGP routers especially running Quagga.
>
> I solved this problem last night applying patch of Chris Caputo:
>
> https://www.caputo.com/foss/quagga-0.99.11-BGP-4-byte-ASN-bug-fixes.patch
>
> on the file bgpd/bgp_aspath.c
>
> After this my bgpd is working correctly. In my case this is working  
> today from
> 3:30 CET and don't crashes again.
>
> I suggest to connect this patch to bgp patches for now, until guys  
> from Quagga
> don't correct this problem --- or Devil-Linux as BGP router will be unusable.
>
> Best Regards
>
> --
> Andrzej Odyniec
>
> <an...@ma...>
> Rada Nadzorcza Macrologic SA
> ul. Chroscickiego 49, 02-414 Warszawa
> tel. +48(22)8637681x132, fax: +48(22)8639861
> ul. Jagiellonska 36, 03-719 Warszawa
> tel. +48(22)5118115, fax: +48(22)5118117
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi,

Now last 0.99.11 Quagga is practically unusable, because now is in broadcast 
prefix with very long path of 4-byte ASN path. When this prefix is received, 
bgpd (last, 0.99.11, in 1.4RC1) crashes like this:

> 2009/05/03 19:27:30 notifications: BGP: BGPd 0.99.11-realms starting: vty@2605, bgp@<all>:179
> 2009/05/03 19:27:35 errors: BGP: 195.187.251.225 [Error] bgp_read_packet error: Connection reset by peer
> 2009/05/03 19:27:57 critical: BGP: Assertion `len < str_size' failed in file bgp_aspath.c, line 619, function aspath_make_str_count
> 2009/05/03 19:27:57 critical: BGP: Backtrace for 14 stack frames:
> 2009/05/03 19:27:57 critical: BGP: [bt 0] /usr/lib/libzebra.so.0(zlog_backtrace+0x34) [0x4f51e7ab]
> 2009/05/03 19:27:57 critical: BGP: [bt 1] /usr/lib/libzebra.so.0(_zlog_assert_failed+0xb5) [0x4f51e947]
> 2009/05/03 19:27:57 critical: BGP: [bt 2] /usr/sbin/bgpd [0x119ea440]
> 2009/05/03 19:27:57 critical: BGP: [bt 3] /usr/sbin/bgpd [0x119ea4aa]
> 2009/05/03 19:27:57 critical: BGP: [bt 4] /usr/sbin/bgpd [0x119ea4f5]
> 2009/05/03 19:27:57 critical: BGP: [bt 5] /usr/lib/libzebra.so.0(hash_get+0x39) [0x4f513c4b]
> 2009/05/03 19:27:57 critical: BGP: [bt 6] /usr/sbin/bgpd [0x119ebb63]
> 2009/05/03 19:27:57 critical: BGP: [bt 7] /usr/sbin/bgpd [0x119a7144]
> 2009/05/03 19:27:57 critical: BGP: [bt 8] /usr/sbin/bgpd [0x119c7e35]
> 2009/05/03 19:27:57 critical: BGP: [bt 9] /usr/sbin/bgpd(bgp_read+0x438) [0x119c9317]
> 2009/05/03 19:27:57 critical: BGP: [bt 10] /usr/lib/libzebra.so.0(thread_call+0x69) [0x4f50f5b5]
> 2009/05/03 19:27:57 critical: BGP: [bt 11] /usr/sbin/bgpd(main+0x38c) [0x11997b05]
> 2009/05/03 19:27:57 critical: BGP: [bt 12] /lib/libc.so.6(__libc_start_main+0x157) [0x4f1b1ff3]
> 2009/05/03 19:27:57 critical: BGP: [bt 13] /usr/sbin/bgpd [0x11997521]

and propagated via BGP addresses are absent in the Internet. After restart 
bgpd starts new sessions, obtain this ugly prefix again and again crashes 
immediatelly.

I'm not sure, but seems as problem like this is present in other routing 
systems. After solving this problem in transit routers (i.e. via router 
replacement), this path is propagated to the next neibors and today or tomorow 
can crash more BGP routers especially running Quagga.

I solved this problem last night applying patch of Chris Caputo:

https://www.caputo.com/foss/quagga-0.99.11-BGP-4-byte-ASN-bug-fixes.patch

on the file bgpd/bgp_aspath.c

After this my bgpd is working correctly. In my case this is working today from 
3:30 CET and don't crashes again.

I suggest to connect this patch to bgp patches for now, until guys from Quagga 
don't correct this problem --- or Devil-Linux as BGP router will be unusable.

Best Regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Serge Leschinsky wrote:
>>should be replaced with:
>>
>>PARAMETER="@/etc/ntop.conf -d -L -P $NTOP_DB_PATH -Q /var/lib/ntop -u ntop"
> 
> Fixed. Thanks a lot!

There are consequences: parameters from command line are now not overriden by 
parameters from /etc/ntop.conf. But ntp daemon is starting without errors.

Anyway, this new ntop one day after start, was failed via "segmentation 
fault..." as usually. So I'm decided not wait again for corrected version, but 
switched it off in /etc/sysconfig/config and configured to run via 
D.J.Bernstein daemon tools. The only, we must remember is don't use -d 
parameter when script will be managed via svscan and don't use -L when we use 
D.J.Bernstein multilog facility. Now ntop is kept running and is automatically 
restarted after each fail.

Regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Andrzej Odyniec wrote:
> Hi,
> 
> Parameters in ntop starting script are now incompatible with current version 
> of ntop.
> 
> form:
> 
> PARAMETER="-d -L -P $NTOP_DB_PATH -Q /var/lib/ntop -u ntop @/etc/ntop.conf"
> 
> should be replaced with:
> 
> PARAMETER="@/etc/ntop.conf -d -L -P $NTOP_DB_PATH -Q /var/lib/ntop -u ntop"
>

Fixed. Thanks a lot!

--
Serge

Hi,

Parameters in ntop starting script are now incompatible with current version 
of ntop.

form:

PARAMETER="-d -L -P $NTOP_DB_PATH -Q /var/lib/ntop -u ntop @/etc/ntop.conf"

should be replaced with:

PARAMETER="@/etc/ntop.conf -d -L -P $NTOP_DB_PATH -Q /var/lib/ntop -u ntop"

When configuration parameter (@/etc/ntop.conf) is last, ntop exit with error.

When I shift @/etc/ntop.conf parameter to first position, ntop started correctly

Best regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Hello Serge,

> AFAIK there are the both drivers in the kernel  - e1000 and e1000e. I think
> these drivers are not identical, so if you need not only Intel's original e1000
> but e1000e as well we caт just add it.

I again read and analysed Intel documents about e1000 and e1000e drivers. Both 
drivers are for near all Intel ethernet controllers, not only gigabit. They 
call e1000e "a new driver". Maybe is coded from scratch again? But letter "e" 
at end suggest, driver is coded especially for PCIe bus. They loss 
compatibility with old 82546GB PCI-X circuit, so they leaved e1000 driver in 
use. But for many chips both should be working. On machine identical with this 
from my examples identical 4 port card is working on driver e1000 (DL compiled 
year ago). Response to netdriverinfo.sh script is:
> eth4 : 04:00.1
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000
>     Driver version = 7.3.20-k2-NAPI
But as I remember, year ago standard kernel driver was not working with my card.

> So, you suggest to update e1000e driver to the latest e1000e, do you? If you
> have tested it and it's working, I suppose it may be done.

I think, driver e1000 in kernel is mature and for compatibility with old 
chips, not supported by e1000e, is sufficient. As for now, we haven't 
alternative, because Intel e1000 is not compiling with 2.6.29 kernel. Looking 
on dates (http://sourceforge.net/project/showfiles.php?group_id=42302) we can 
see, that e1000e is touched 19 March -- and is working with changed driver 
interface in 2.6.29. But Intel e1000 driver is left unchanged and (probably) 
will never compile with new kernels. So Intel e1000 driver and "Intel e1000" 
configuration option is now obsolete.

For warranty to work (kernel can change again in this place) I suggest to left 
kernel driver e1000e working. For eventual differences, changes, corrections 
and adoptions for new Intel Circuits I think, is needed alternaive: e1000e 
from Intel --- choosen as today e1000. Another question is: what should be 
default? I dont'n know. Maybe (as today) -- kernel driver.

> I have a version. It's a result of rounding... As a hotfix I'd remove the
> following code (mount_cdrom):

Big thanks for solution. I will try.

Serge, Heiko. Big thanks for Devil-Linux initiative. Is great. I use as for 
now 3 routers on DL (one with BGP) an one separate spam filtering MTA. I think 
to run separate Kerberos server on it. It is great work.

Best Regards

Andrzej Odyniec
Warsaw, Poland

Hello Andrzej,

Andrzej Odyniec wrote:

>> eth4 : 04:00.1
>>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>>     VenID:DevID = 8086:10a4
>>     Driver name = e1000e
>>     Driver version = 0.5.18.3-NAPI
> 
> Previus was from original kernel driver (because of little bug in my script 
> compiled driver was not properly installed in CD image). As we can see, kernel 
> has e1000e driver but in older version than this from Intel.
AFAIK there are the both drivers in the kernel  - e1000 and e1000e. I think
these drivers are not identical, so if you need not only Intel's original e1000
but e1000e as well we caт just add it.


> In Ubuntu forums 
> I found, that this old driver is not working correctly in some situations and 
> guys used Intel 0.5.18.3 instead. I need this DL installation for my main 
> router, so I will compile actual Intel driver using my script, reducing (I 
> hope) risk.
So, you suggest to update e1000e driver to the latest e1000e, do you? If you
have tested it and it's working, I suppose it may be done.


>> System is configured to run from ram
>> Copying system image (327 MB) to ramdisk...|done.
>> ERROR: ramdisk size calculation error
>>        the image to copy was bigger than expected
>>
...
> 
> I don't know, why? Do You have this same effect or not?

I have a version. It's a result of rounding... As a hotfix I'd remove the
following code (mount_cdrom):

        # get size of the copied image
        local REAL_SIZE=$(du -k ${RAMDISK}/${IMAGE} | awk '{print $1}')
        let REAL_SIZE=REAL_SIZE*10/1024+5 # do correct rounding
        let REAL_SIZE=REAL_SIZE/10

        # check if we at least match the image size estimated before
        if [ ${REAL_SIZE} -lt ${IMAGE_SIZE_MB} ]; then
                $RED;
                echo "FATAL-ERROR: copying failed - only ${REAL_SIZE} MB out of
${IMAGE_SIZE_MB} MB copied"
                echo '             a possible source of this problem could be:'
                echo '               * read errors - media defective?'
                echo '               * out of RAM - need to install more RAM?'
                echo
                $NORMAL
                run_from_ram_cleanup
                return 1
        fi


And you will completely rely on error handling during "copy" operation. To
guarantee the image integrity we can implement checksumming (size calculation is
not reliable parameter anyway).


--
Serge