[leaf-user] A few notes about the upcoming Bering-uClibc 6.1.0 release

[kp kirchdoerfer via leaf-user]

Hi all;

today 6.1.0-beta1 has been made available in the FRS

https://sourceforge.net/projects/leaf/files/Bering-uClibc/6.1.0-beta1/

LEAF Bering-uClibc  6.1.0 will be based on uClibc-ng 1.0.25, gcc 5.4.0, kernel 
4.9, perl 5.26.0 and busybox 1.27.

The full blown libiconv package (approx 650kb) has been replaced with uClibc-
ng  implementation of libiconv (adding a few kb to initrd).

initrd merged root.lrp and config.lrp into initrd.lrp

In addition to Raspberry1 support for Raspberry3 has been added. The 
Raspberry3 tarball may also work with Raspberry Pi2, though this hasn't been 
tested.

Also it provides numerous  packages updated to latest upstream versions and 
feature improvements (e.g. shorewall, tor, bind, openvpn, added ldap support 
to dhcpd).

Also new packages has been added:

libndp -   a library which provides a wrapper for IPv6 Neighbor Discovery 
Protocol and   a tool named ndptool for sending and receiving NDP messages

libaio -   Library for doing asynchronous I/O

libtirpc - The libtirpc package contains libraries that support programs that 
use the Remote Procedure Call (RPC) API.

rpcbind - The rpcbind program is a replacement for portmap. It is required for 
import or export of Network File System (NFS) shared directories.

sqlite -  SQLite is a self-contained, high-reliability, embedded, full-
featured, public-domain, SQL database engine; required for NFSv4 support.

ca-certificates -  ca-certificates provides a list of Certification 
Authorities. 
It is based on the Debian package, which itself provides the ones from Mozilla 

dehydrated - ACME client implementation for Let's Encrypt 
(https://letsencrypt.org/)

The default http[s] daemon mini_httpd[s] has been replaced with lighttpd. 
Therefor lighttpd has been adjusted to run webconf.
A note here: by default lighttpd/webconf are installed without ssl support.
To add ssl support you need to create your own certificates in 
/etc/ssl/private, change the lighttpd configuration and save the configuration.

A short recipe is given, if you run "help lighttpd" on the commandline.

Using lighttpd with ssl is flexible, so you are not bound to the default name 
"lighttpd.pem", you may create your keys elsewhere, you may even try to use 
letsencrypt with the dehydrated package to create a key supported by your 
browser out-of-the box. (If someone works out how to use that, a documentation 
for the Bering-uClib  User Guide is welcome :))

Speaking about the User Guide, there are still gaps in the 6.1 version 

https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.x_-_User_Guide

if you are capable to fill those or like  to add a new chapter, let us know, 
any help is welcome.

For more information see about the changes for  LEAF Bering-uClibc 6.1 :

https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.1.x_-_Changelog

Feedback and suggestions are welcome.

thx for your attention
kp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] moving to Bering-uClibc 6.1.0-alpha2

[kp kirchdoerfer]

Hi Erich;

Am Samstag, 27. Mai 2017, 20:05:50 schrieb Erich Titl:
> Hi KP
> 
> Am 27.05.2017 um 19:15 schrieb kp kirchdoerfer:
> > Hi all;
> > 
> > the recent discussions about ntpd failing on i686 SMP and patching it,
> > required to test the proposed patch with uClibc-ng 1.0.24.
> 
> Wouldn't it be easier and better to just wait for the uClibc team to fix
> the mainstream code?

This *is* the patch for the mainstream code. It will be only a small change in 
buildtool.*  to adjust this once we move to a later uClibc-ng version.

But with all the work to get this patch tested, the move to 1.0.24 was almost 
done, so why to throw the work away?

The major hurdles are rpc.mountd, which could be related to uClibc-ng, but it 
occurs with earlier versions as well.

Failing libaio is unrelated to any uClibc-ng version AFAIK.

kp


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] moving to Bering-uClibc 6.1.0-alpha2

[kp kirchdoerfer]

Hi all;

the recent discussions about ntpd failing on i686 SMP and patching it, 
required to test the proposed patch with uClibc-ng 1.0.24.

The most visible change when building our packages with uClibc-ng 1.0.24 was 
the deletion of RPC support in uClibc-ng.
A replacement is libtiprpc  with a more recent version of RPC

I've changed  and tested all packages affected. 
It occured that despite all patches I can't get nfs-utils (more specific rpc-
mountd) to work on x86_64. It still segfaults, which does not happen on 
i486...

Another problem, though not important yet, is libaio failing on toolchains 
other than x86_64.

I'll building all toolchains today right now to move toward a new alpha 
version.


Any help to solve the above mentioned issues is welcome.

kp


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] ntpd segfaulting (copied to leaf-devel)

[kp kirchdoerfer]

Hi Bob, Hi Erich;

thanks for the profound work on this bug.

I've contacted the maintainer of uClibc-ng and received some homework to track 
this issue. The proposed patch by by ddrown needs testing and if successful, 
might be accepted.

kp

Am Mittwoch, 3. Mai 2017, 22:04:53 schrieb Erich Titl:
> Hi Bob
> 
> (copying this to leaf-devel)
> 
> Sorry, I was too fast, I did not look into the i386 code but the one in
> x86_64
> 
> Am 03.05.2017 um 20:03 schrieb Robert K Coffman Jr. -Info From Data Corp.:
> > Eric,
> > 
> > IRC user ddrown confirmed the x64 patch I mentioned earlier seems to fix
> > the issue on i386 as well.  I'm not really sure what to do with that
> > information.  Is it possible to patch Leaf with it?
> > 
> > https://gist.github.com/ddrown/15e943b8fe1da398320b0c0518c95554
> 
> I don't know. It looks like the RESTORE2 macro is extended with a nop
> operator in this patch. This looks like assembly code.
> 
> ...
> 
> This is i386...
> 
> #define RESTORE(name, syscall) RESTORE2(name, syscall)
> 
> #ifdef __NR_rt_sigaction
> /* The return code for realtime-signals.  */
> # define RESTORE2(name, syscall) \
> __asm__ (   \
>  ".text\n"   \
>  "__" #name ":\n"\
>  "   movl$" #syscall ", %eax\n"  \
>  "   int $0x80\n"\
> );
> RESTORE(restore_rt, __NR_rt_sigreturn)
> #endif
> 
> #ifdef __NR_sigreturn
> /* For the boring old signals.  */
> # undef RESTORE2
> # define RESTORE2(name, syscall) \
> __asm__ (   \
>  ".text\n"   \
>  "__" #name ":\n"\
>  "   popl%eax\n" \
>  "   movl$" #syscall ", %eax\n"  \
>  "   int $0x80\n"\
> );
> RESTORE(restore, __NR_sigreturn)
> #endif
> 
> and this is x86_64
> 
> #define RESTORE(name, syscall) RESTORE2(name, syscall)
> #define RESTORE2(name, syscall) \
> __asm__ (   \
>  "nop\n" \
>  ".text\n"   \
>  "__" #name ":\n"\
>  "   movq$" #syscall ", %rax\n"  \
>  "   syscall\n"  \
> );
> 
> #ifdef __NR_rt_sigaction
> /* The return code for realtime-signals.  */
> RESTORE(restore_rt, __NR_rt_sigreturn)
> #endif
> #ifdef __NR_sigreturn
> RESTORE(restore, __NR_sigreturn)
> #endif
> 
> So in i386 the patch appears to be possible, if it is necessary I don't
> know as it looks like the nop operator could be used to make the
> assembly code align to instruction size. The nop operator is already in
> the x86_64 code.
> 
> I have not followed uClibc development. I am wondering what their
> position is on this issue.
> 
> cheers
> 
> ET


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] wget-ssl.lrp missing in Buc 6.0.2 rev 1

[kp kirchdoerfer]

Am Freitag, 28. April 2017, 23:09:10 schrieb Jean-Roch Blais:
> Hello list,
> 
> is there a reason why wget-ssl.lrp is missing from Buc 6.0.2 rev 1 and maybe
> others distributions. It is required to perform a webconf firmware upgrade…
> https://sourceforge.net/p/leaf/bering-uclibc/ci/143fcc117549efc0d6bd42de141
> cdfb7de8fca6c/tree/repo/config/upgrade
>  1cdfb7de8fca6c/tree/repo/config/upgrade> ’s function "check
> wget_dependencies" checks for this.

Hi Jean-Roch;

I believe sometnig went wrong here;

wget and wget-ssl has been merged  AFAIR since 5.2.5.

The check seems wrong, it smells like a bug - we'll look into it.

Do you have openssl installed? In that case it should work with either wget or 
busybox wget.

kp 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] 6.1 - troubles in syslinux

[kp kirchdoerfer]

Am Donnerstag, 6. April 2017, 18:21:34 schrieb Andrew:
> Hi all.
> 
> It seems like syslinux i LEAF becomes broken - I can't make flash
> bootable with it. I've got 'Error converting to codepage 850 Success'
> error, IMHO it's related to uClibc-ng libiconv.
> 
> Anybody tried to make bootable disk from LEAF 6.1? Or from 6.0?

Hi Andrew;

I think I've found the problem (syslinux needs to be changed), pls test latest 
commit.

kp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] 6.1 - troubles in syslinux

[kp kirchdoerfer]

Hi Andrew;

Am Donnerstag, 6. April 2017, 18:21:34 schrieb Andrew:
> Hi all.
> 
> It seems like syslinux i LEAF becomes broken - I can't make flash
> bootable with it. I've got 'Error converting to codepage 850 Success'
> error, IMHO it's related to uClibc-ng libiconv.
> 
> Anybody tried to make bootable disk from LEAF 6.1? Or from 6.0?

Probably a kernel misconfiguration

# CONFIG_NLS_CODEPAGE_850 is not set

kp


> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] logrotate

[kp kirchdoerfer]

Am Mittwoch, 5. April 2017, 09:26:42 schrieb Otto Halák - TeleLarm:
> Hi,
> is there some kind of "postrotate" option in lrp.conf?
> SMSTools3 needs to be reloaded after log file rotation since it still
> writes to previous old logfile (smsd.log.1).
> Thanks in advance
> Otto

None in the old spacecheck that I'm aware off; 6.x has a more advanced 
logrotation which restarts a given daemon.

kp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Installing Openvpn

[kp kirchdoerfer]

HI Mansoor;

Am Montag, 20. März 2017, 09:16:45 schrieb Mansoor Ahmad:
> Hello Everyone.
> 
> In brief I have had a few years now working with leaf and its many
> packages. In our camp, we typically used the old floppy, cd disk setup
> with the Bering-uClibc distribution. We are now trying to boot from the
> hdd. After having some initial problems with the network cards swapping
> drivers, and a few other minor issues, we are now trying to get our vpn
> setup on this new box with the latest Bering-uClibc distribution. My
> questions are as follows and thank you guys in advanced for aiding me
> indeed:
> 
> 1. How do we get openvpnz on this box? Once I get the box online, is
> there a certain command similar to 'apt-get install' I can use that'll
> automatically grab the package from is repository?

No, there is no such command. You should have openvpnz.lrp on the (iso) image, 
tarball whatever you've downloaded from leaf.sourceforge.net. Add it to your 
hdd, if it' not already there, add "openvpnz" to the LRP line  in leaf.cfg and 
reboot. Pls be aware you also need to add "tun" module to /etc/modules and 
save the configuration via lrcfg to load the module during boot.

There has been a discussion on this list how to create keys recently, it may 
help. You may also find some help here

https://bering-uclibc.zetam.org/wiki/Main_Page

Look for the appropriate User Guide (note: the 6.0 USer Guide still has some 
empty chapters).

> 2. I copied the keys over to a windows laptop. Traditionally opening a
> notepad file in windows, then placing it on a floppy within leaf has
> caused many problems with the placement of periods through out the file.
> Is that the same case with the new distributions.

AFAIK yes; though the main problem is the handling of linefeed (CR/LF).

> 3. Is there a place I can demo the mconf-httpd/ui of a leaf distribution
> anywhere? We've always used the cli.

I'm not aware of any- and I stick with the CLI, esp for more advanced tasks.

hth
kp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] kernel 4.9 in master

[kp kirchdoerfer]

Am Samstag, 28. Januar 2017, 10:04:59 schrieb Andrew:
> On 28.01.2017 03:30, kp kirchdoerfer wrote:
> > Hi Andrew;
> > 
> > Am Freitag, 27. Januar 2017, 20:55:15 schrieb Andrew:
> >> Hi.
> >> 
> >> I've fixed perf, it should be built now.
> > 
> > I'm testing...
> > 
> >> Also I noticed one trouble with packaging: when owner/group is set as
> >> literal (for ex., www-data), buildpacket.pl tried to resolve it using
> >> system passwd file. Which may not correspond to platform passwd...
> > 
> > Do you have an (example) package you refer to?
> > 
> > kp
> 
> lighttpd, vnstats
> 
> I have no local www-data user, and packaging fails.

Can you pls try to change user/group "www-data" in lighttpd buildtool.cfg with 
"33"?

kp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] kernel 4.9 in master

[kp kirchdoerfer]

Hi Andrew;

Am Freitag, 27. Januar 2017, 20:55:15 schrieb Andrew:
> Hi.
> 
> I've fixed perf, it should be built now.

I'm testing...

> Also I noticed one trouble with packaging: when owner/group is set as
> literal (for ex., www-data), buildpacket.pl tried to resolve it using
> system passwd file. Which may not correspond to platform passwd...

Do you have an (example) package you refer to?

kp

> On 15.01.2017 18:35, kp kirchdoerfer wrote:
> > Hi all;
> > 
> > I've committed a 4.9.(3) kernel to master for review.
> > 
> > While I believe we should wait for an official new LTS kernel (probably
> > 4.10), upgrading the kernel to 4.9 made me aware of missing and failing
> > packages (ipt-netflow, igb,...), the only remaining package to fail is
> > perf.lrp. And hopefully it will be easier to upgrade to 4.10, once we
> > ironed out errors with the 4.9 kernel.
> > 
> > Note: Currently the arm* toolchains do not build with with the 4.9 kernel.
> > 
> > Please review the configs for x86_64, i486, geode etc..
> > 
> > Andrew maybe you can look into perf and fix it?
> > 
> > I'm currently running the x86_64 kernel, and it seems to work pretty well.
> > 
> > regards kp
> > 
> > --
> >  Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> > 
> > ___
> > leaf-devel mailing list
> > leaf-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/leaf-devel
> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Module loading issues in 6.0.2-rc1

[kp kirchdoerfer]

Hi;

I understand you are talking neither about about shorewall nor 
/etc/init.d/iptables (start/stop/restart), which seesm to work, but plain 
iptables(-restore) binary?

kp

Am Mittwoch, 18. Januar 2017, 10:15:03 schrieb John Sager:
> I'm trying to get 6.0.2-rc1 working on a PC Engines apu2c2 but there are
> problems with loading modules in some cases. I note that the moddb stuff has
> been removed and all module loading is now done from modules.sqfs mounted
> to /lib/modules/$KVER. Although this works at early boot time to load
> modules in /etc/modules it fails later on for iptables-restore and
> ip6tables-restore. iptables and ip6tables autoload modules as needed for the
> specific rules required. Although the scripts in /etc/init.d for iptables &
> ip6tables mount modules.sqfs to load the helper modules in IPTABLES_MODULES
> they don't for the -restore operation. iptables-restore is effectively just
> a wrapper round iptables so it autoloads modules in the same way.
> 
> There are other configuration applications that operate closely with the
> kernel - e.g tc - and perhaps some of them also autoload modules as
> necessary. They will also fail in the absence of a mounted modules.sqfs, as
> will ad-hoc use of iptables during testing of new configurations in a
> working environment.
> 
> For the moment I will solve it by creating a version of /etc/modules from a
> lsmod listing once everything is running properly but a better solution than
> that is needed. Are there issues with mounting modules.sqfs permanently?
> Would mounting /dev/sda1 permanently & readonly interfere with mounting it
> readwrite temporarily somewhere else to update configdb.lrp?
> 
> regards,
> 
> John Sager
> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] FYI: 6.0.2-rc1 works on a PC Engines apu2c2 but with issues

[kp kirchdoerfer]

Am Mittwoch, 18. Januar 2017, 16:42:43 schrieb John Sager:
> I've got coreboot version 20160307. According to the PC Engines website this
> introduces SD boot support. There is a 20160311 version so I may try that.

I don't believe that will help a lot, according to the sparse notes it just 
adds pxe boot, and the thread you've linked to was related to the latest BIOS.

As I said, it still seems to be an issue and the advice from support tells the 
same story in other words :(

kp

> John
> 
> On 18/01/17 15:40, kp kirchdoerfer wrote:
> > Hi John;
> > 
> > Am Mittwoch, 18. Januar 2017, 09:41:26 schrieb John Sager:
> >> For some years I've run leaf-bering on a PC Engines Alix 2D13 board as my
> >> main router, but now I need to upgrade to a board that supports gigabit
> >> ethernet, vlans, baby jumbo frames, etc.
> >> 
> >> The apu2c2 board has 3 gigabit LAN ports, 2 USB3 ports, SD card reader
> >> plus
> >> mSATA & PCI express sockets.
> >> 
> >> Using Bering-uClibc_6.0.2-rc1_x86_64_syslinux_serial115200.tar.gz on a
> >> USB
> >> stick the board boots fine. However I can't get it to boot from a SD
> >> card.
> >> The bios boot (coreboot) recognises the SD card in the boot list but then
> >> hangs at the point where it should transfer to syslinux. This is
> >> obviously a PC Engines issue and not one for Leaf. There is a thread
> >> about this on PC Engines' forum:
> >> 
> >> http://pcengines.info/forums/?page=post=1532182F-D982-4735-A4BF-7E786E
> >> C42 179
> > 
> > Do you even have installed a BIOS with SD support?
> > I've got one of the earlier borads with an older BIOS and had to update to
> > 160211 to get the wlee200nx to work, works fine with mSATA. I've updated
> > later the kernel because a user had a SD card with support for the SD
> > card, but AFAIR got no feedback since.
> > 
> > But it seems, following the  thredad above SD issus might not be solved
> > finally ...?
> > 
> > kp
> > 
> >> However the recommendation seems to be to use a mSATA card instead:(
> >> 
> >> If I go down that route though that brings up another problem - the
> >> apu2c2
> >> is the only mSATA interface I have available, and the tools required to
> >> transfer the working config from the USB stick to mSATA (fdisk,
> >> mkfs.vfat,
> >> syslinux) don't seem to be available in any of the Leaf packages. I would
> >> probably have to boot up TinyCore Linux temporarily to do the transfer.
> >> 
> >> Having transferred the appropriate (5.2.4) configs from the old router, I
> >> have run into module loading problems - see my next e-mail for a
> >> discussion
> >> of this.
> >> 
> >> regards,
> >> 
> >> John Sager
> >> 
> >> -
> >> --- -- Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >> 
> >> leaf-user mailing list: leaf-user@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/leaf-user
> >> Support Request -- http://leaf-project.org/
> > 
> > --
> >  Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > 
> > leaf-user mailing list: leaf-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/leaf-user
> > Support Request -- http://leaf-project.org/
> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] FYI: 6.0.2-rc1 works on a PC Engines apu2c2 but with issues

[kp kirchdoerfer]

Hi John;

Am Mittwoch, 18. Januar 2017, 09:41:26 schrieb John Sager:
> For some years I've run leaf-bering on a PC Engines Alix 2D13 board as my
> main router, but now I need to upgrade to a board that supports gigabit
> ethernet, vlans, baby jumbo frames, etc.
> 
> The apu2c2 board has 3 gigabit LAN ports, 2 USB3 ports, SD card reader plus
> mSATA & PCI express sockets.

> Using Bering-uClibc_6.0.2-rc1_x86_64_syslinux_serial115200.tar.gz on a USB
> stick the board boots fine. However I can't get it to boot from a SD card.
> The bios boot (coreboot) recognises the SD card in the boot list but then
> hangs at the point where it should transfer to syslinux. This is obviously a
> PC Engines issue and not one for Leaf. There is a thread about this on PC
> Engines' forum:
> 
> http://pcengines.info/forums/?page=post=1532182F-D982-4735-A4BF-7E786EC42
> 179

Do you even have installed a BIOS with SD support? 
I've got one of the earlier borads with an older BIOS and had to update to   
160211 to get the wlee200nx to work, works fine with mSATA. I've updated later 
the kernel because a user had a SD card with support for the SD card, but 
AFAIR got no feedback since.

But it seems, following the  thredad above SD issus might not be solved finally 
...?

kp

> However the recommendation seems to be to use a mSATA card instead:(
> 
> If I go down that route though that brings up another problem - the apu2c2
> is the only mSATA interface I have available, and the tools required to
> transfer the working config from the USB stick to mSATA (fdisk, mkfs.vfat,
> syslinux) don't seem to be available in any of the Leaf packages. I would
> probably have to boot up TinyCore Linux temporarily to do the transfer.
> 
> Having transferred the appropriate (5.2.4) configs from the old router, I
> have run into module loading problems - see my next e-mail for a discussion
> of this.
> 
> regards,
> 
> John Sager
> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] kernel 4.9 in master

[kp kirchdoerfer]

Hi Erich;

Am Sonntag, 15. Januar 2017, 20:08:59 schrieb Erich Titl:
> Hi KP
> 
> Am 15.01.2017 um 16:35 schrieb kp kirchdoerfer:
> > Hi all;
> > 
> > I've committed a 4.9.(3) kernel to master for review.
> > 
> > While I believe we should wait for an official new LTS kernel (probably
> > 4.10), upgrading the kernel to 4.9 made me aware of missing and failing
> > packages (ipt-netflow, igb,...), the only remaining package to fail is
> > perf.lrp. And hopefully it will be easier to upgrade to 4.10, once we
> > ironed out errors with the 4.9 kernel.
> 
> I am not overly concerned, but should such a change not be committed to
> a different branch until the problems are ironed out?

I'm not concerned as well.
You probaly may correct, but then i486 and x86:_64 toolchain are AFAIK in a 
good shape when building all packages - with the only exception of perf.lrp.

The master repository is meant for the next major version, and therefor for a 
given time in a fluent state. Providing a repo that builds and works for most 
of our targets seems good enough to commit changes.

IMHO important is now to review the changes and to find errors I may have made 
whe updating the kernel.

kp

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] kernel 4.9 in master

[kp kirchdoerfer]

Hi all;

I've committed a 4.9.(3) kernel to master for review.

While I believe we should wait for an official new LTS kernel (probably 4.10), 
upgrading the kernel to 4.9 made me aware of missing and failing packages 
(ipt-netflow, igb,...), the only remaining package to fail is perf.lrp. And 
hopefully it will be easier to upgrade to 4.10, once we ironed out errors with 
the 4.9 kernel. 

Note: Currently the arm* toolchains do not build with with the 4.9 kernel. 

Please review the configs for x86_64, i486, geode etc..

Andrew maybe you can look into perf and fix it?

I'm currently running the x86_64 kernel, and it seems to work pretty well.   

regards kp

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] 6.0.1 issue with DNAT

[kp kirchdoerfer]

Hi Joern;

Am Dienstag, 3. Januar 2017, 11:32:03 schrieb Jørn Eriksen:
> Hello there,
> 
> It seams also that 6.0.x has issues with DNAT when using Shorewall. Not
> sure as to all the sub-modules involved - Tom belived is was due to
> issues with
> xt_nat
> nf_nat
> nf_nat_ipv4

I've started a fresh build of i486 iso image (based on latest changes for 
6.0.2 and a patch for shorewall Martin sent) with a DNAT command added to 
/etc/shorewall/rules for testing.

It starts without errors and I have 
xt_nat
nf_nat_masquerade_ipv6
iptable_nat
nf_nat_ipv4
nf_nat

loaded after boot.

kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Perl error from buildtool.pl

[kp kirchdoerfer]

Hi;

Am Montag, 2. Januar 2017, 15:22:49 schrieb Frederick E. Stevens:
> Hi,
> 
> I was building BuC 6.0.1 from git maint branch.  When
> I tried to build argp-standalone the following error was produced:
> 
> Error: Can't call method "isa" on unblessed reference
> at /usr/share/perl5/vendor_perl/Hash/Merge.pm line 100.
> 
> There was at least one other package that produced the same error but I
> wasn't able to catch the name.  I am using Perl 5.18.1

This doesn't happen with Perl 5.18.2 on Debian and derivates; though there is 
a commit request on github, but it's two yrs old...?

We use the Perl from your build host, so we can't fix it.

kp
 
> If this has already been dealt with please disregard this message.
> 
> Regards,
> 
> Fred
> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] libmnl.lrp missing in 6.0.1 tarballs/images

[kp kirchdoerfer]

Hi Martin;

thx for spotting this.

It seems building the complete image with buildall fools us for some packages  
- it was all "green" but it failed for libmnl and strongswan as another user 
detected

Am Donnerstag, 29. Dezember 2016, 19:59:36 schrieb Martin Hejl:
> Hi all,
> 
> it appears that the libmnl.lrp package is missing in all 6.0.1 tarballs
> as well as the iso-images. Booting from one of the iso-images, I get
> 
> LINUXRC: Installing - root: /dev/sr0 (lots of other packages)
> libmnl: libmnl(nf!)
> 
> Trying to build the package myself, I noticed that libmnl-1.0.4 creates
> /usr/lib/libmnl.so.0.2.0
> and no longer
> /usr/lib/libmnl.so.0.1.0 (as 1.0.3 did), which caused buildpacket.pl to
> fail with an error.
> 
> After updating the "Contents" section in repo/libmnl/buildtool.cfg, I
> was able to build the package (but I haven't tested it yet).
> 
> In short, replace "0.1.0" with "0.2.0":
> 
>
>  
>Filename = usr/lib/libmnl.so.0.2.0
>Source   = usr/lib/libmnl.so.0.2.0
>Type = binary
>  
>  
>Filename = usr/lib/libmnl.so
>Target   = usr/lib/libmnl.so.0.2.0
>Type = link
>  
>  
>Filename = usr/lib/libmnl.so.0
>Target   = usr/lib/libmnl.so.0.2.0
>Type = link
>  
>

fixed in git.

> 
> Martin
> 
> P.S. Is it correct that none of the packages for 6.0.1 are in the
> packages repository so far? Or am I just looking in the wrong spot?

You haven't looked int the wrong spot; I hesitated to provide the packages 
yet, minor issue is time, major issue is that the packages repository is the 
base if running upgrade from the router and 5.2.8 releases will fail to load 
after upgrade, if the user does not take of the changes in syslinux.cfg.

And most important, it is a good time to rethink the repository layout.
It occured that adding new directories might not the way to go with git - it 
will probably easier to have a more flat one and use tags etc...
I also feel the need to provide packages in the packages repository, so rework 
the repo layout should be moved until  6.1.x is going live
 No decision made yet 

regards kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] automatic upgrade from 5.2.4

[kp kirchdoerfer]

HI Boris;

Am Dienstag, 27. Dezember 2016, 09:00:43 schrieb Boris:
> Hej Andrew (sorry fpr PM) and hej list,
> 
> thanks for your answer! Is that working for upgrade to next major
> release (6.x), too?

As Andrew said it should, but currently it won't work.

The 6.0 series has not been made available for remote upgrades yet.
Still a task on my agenda.

And once done pls read 
 
https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.x_-_User_Guide_-_Appendices_-_Upgrading_from_Bering-uClibc_5.x

before rebooting.

kp

> Boris
> 
> Am 26.12.2016 um 19:48 schrieb Andrew:
> > Just replace all files on CF by new one, leaving configdb untouched.
> > 
> > Better way - do after this 'apkg -u file.lrp' for each .lrp file to be
> > sure that you didn't missed config updates.
> > 
> > On 26.12.2016 20:41, Boris wrote:
> >> Hej Andrew,
> >> 
> >> 
> >> thanks for your hint!
> >> 
> >> I followed your advice and made /tmp 60 MB large, thinking 6 MB was
> >> a wrong dimension
> >> 
> >> So the upgrade did _something_ contacting sourceforge with a path like
> >> ...\tree\i386 , what seems to be not th right path for a geode system.
> >> Finally, I got a wrong file /syslinux/linux and my box did not boot any
> >> longer the right modules.
> >> 
> >> After all, I have it back working but don't think I have the courage to
> >> try the automatic upgrade any longer.
> >> 
> >> Is there a documentation how to upgrade manually without doing the whole
> >> config from the beginning?
> >> 
> >> Thanks,
> >> 
> >> 
> >> Boris
> >> 
> >> Am 25.12.2016 um 18:48 schrieb Andrew:
> >>> Hi.
> >>> 
> >>> You should increase /tmp size (it can be set in leaf.cfg that is placed
> >>> in the root of your storage).
> >>> 
> >>> On 25.12.2016 16:16, Boris wrote:
>  Hej leaf-list,
>  
>  
>  Christmas is a good time to work on the box... ;-)
>  Merry Christmas!!
>  
>  I tried to use the automatic upgrade with my leaf-box 5.2.4 Rev.1.
>  First I replaced wget with the one from 5.2.5 because auf the
>  https-issue.
>  
>  Execution of upgrade --release 5.2.5 (little steps) brings me:
> > # upgrade --release 5.2.5
> > upgrade: Your system has insufficient temporary storage available for
> > upgrade: upgrade to run successfully. Please check the size of your
> > upgrade: /tmp file system and increase it to at least 6 MB
> > aborting: check_prerequisites: temporary storage size insufficient
> > upgrade: abort check_prerequisites: temporary storage size
> > insufficient
> > upgrade: upgrade terminated successfully
>  
>  Im running leaf on an alix box with a CF-Card to boot from (/mnt).
>  /tmp is in RAM-Disk and far away from 6 MB (!??).
>  
> > # df -h
> > FilesystemSize  Used Available Use% Mounted on
> > tmpfs 8.0M 0  8.0M   0% /tmp
> > tmpfs 8.0M  1.5M  6.5M  19% /var/log
> > root 40.0M 21.0M 19.0M  52% /
> > /dev/sda1   989.8M212.9M776.9M  22% /mnt
>  
>  Is there a chance to make upgrade work and how to do so?
>  
>  Thanks,
>  
>  
>  Boris
>  
>  ---
>  ---
>  
>  Developer Access Program for Intel Xeon Phi Processors
>  Access to Intel Xeon Phi processor-based developer platforms.
>  With one year of Intel Parallel Studio XE.
>  Training and support from Colfax.
>  Order your platform today.http://sdm.link/intel
>  ---
>  -
>  
>  leaf-user mailing list: leaf-user@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/leaf-user
>  Support Request -- http://leaf-project.org/
> >>> 
> >>> 
> >>> --
> >>> 
> >>> Developer Access Program for Intel Xeon Phi Processors
> >>> Access to Intel Xeon Phi processor-based developer platforms.
> >>> With one year of Intel Parallel Studio XE.
> >>> Training and support from Colfax.
> >>> Order your platform today.http://sdm.link/intel
> >>> 
> >>> leaf-user mailing list: leaf-user@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/leaf-user
> >>> Support Request -- http://leaf-project.org/
> 
> 
> -- Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/

Re: [leaf-user] Bering-uClibc 6.0.1 release : Missed strongswan package

[kp kirchdoerfer]

Hi;

Am Mittwoch, 21. Dezember 2016, 15:41:15 schrieb Ecran Total:
> Hi Leaf team,
> 
> 
> 
> Missed  strongswan  package  in
> Bering-uClibc_6.0.1_geode_syslinux_serial115200 !!
> 
> (6.0.1-rc1 changelog: strongswan  updated to upstream version 5.5.1)

Indeed; it hasn't been packaged and added to image/tarball.

Will be fixed in 6.0.2.

Thx for reporting
kp

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] dnsmasq does not start on boot with Bering-uClibc 6.0.0

[kp kirchdoerfer]

Hi Sven;

Am Montag, 5. Dezember 2016, 23:22:34 schrieb Sven Kirmess:
> On Mon, Nov 28, 2016 at 12:45 AM, Erich Titl  wrote:
> > It might be easier to just add the modules to /etc/modules. They are also
> > referenced at start up.
> 
> That works also, thanks. I think that really should (probably must) be the
> default. Dnsmasq should not fail to start.

In your previous mail you mentioned the error is caised by the lack of the 
ipv6 module.

I doublecked with a pristine 6.0.1-rc1 i486 iso image and I see ipv6 is loaded 
as well as dnsmasq started.

Do you load shorewall6 in your leaf.cfg?

kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[leaf-devel] post_upgrade branch

[kp kirchdoerfer]

Hi Erich;

can you pls explain, what we do have expect with the post_upgrade branch and 
how to test it?

If all goes well, which branch do you want  it to merged with?

kp 

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] CLAMPMSS=Yes requires TCPMSS Target in your kernel and iptables

[kp kirchdoerfer]

Am Mittwoch, 23. November 2016, 22:59:37 schrieb Sven Kirmess:
> As Erich pointed out, it seems to not load the module during boot. (That's
> again on a fresh system without a configdb.lrp)
> 
> firewall# shorewall show capabilities | grep -i tcpmss
>TCPMSS Match (TCPMSS_MATCH): Not available
>TCPMSS Target (TCPMSS_TARGET): Not available
> firewall# mount_modules
> firewall# shorewall show capabilities | grep -i tcpmss
>TCPMSS Match (TCPMSS_MATCH): Available
>TCPMSS Target (TCPMSS_TARGET): Available
> firewall#


I started a pristine 6.0.0 x86_64 iso image and set clampmss to "yes"

shorewall restart gave the error you see.

/etc/init.d/shorewall stop

/etc/init.d/shorewall start 

loads the module in question successfully

Save to config and it will be fine if you reboot.

kp

--

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] CLAMPMSS=Yes requires TCPMSS Target in your kernel and iptables

[kp kirchdoerfer]

Hi Sven;

Am Dienstag, 22. November 2016, 21:43:48 schrieb Sven Kirmess:
> I get this error message when I try to enable CLAMPMSS=Yes. This worked
> with LEAF Bering-uClibc 5.2.5 but doesn't work with LEAF Bering-uClibc
> 6.0.0.
> 
> Was something in the kernel changed or did I do something wrong with the
> migration?

It does work for me.

How did you migrate?

What does
shorewall show capabilities

show?

And 
lsmod | grep TCPMSS

And of course 
apkg -l

kp

--

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[leaf-devel] Important: git package shrink

[kp kirchdoerfer]

Hi all,

Yves pointed me to BFG Repo-Cleaner 
(https://rtyley.github.io/bfg-repo-cleaner/)
to shrink our Pagackes repo.

After a lot of testing it has been time to finally make the step to push a 
shrinked version to our git repo.

The packages repository has been reduced from 11GB to 2GB.

It is necessary that everyone deletes the local packages repository and starts 
a fresh clone.

"At this point, you're ready for everyone to ditch their old copies of the 
repo and do fresh clones of the nice, new pristine data. It's best to delete 
all old clones, as they'll have dirty history that you don't want to risk 
pushing back into your newly cleaned repo." 

Please follow this advice

thx kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Bering-uClibc-6.0.0 introduces the new major version of LEAF Bering-uClibc

[kp kirchdoerfer]

Am Sonntag, 30. Oktober 2016, 07:20:06 schrieb n22e113:
> On 10/23/2016 12:26, kp kirchdoerfer wrote:
> > * Support for PCEngines APU2 incl watchdog support and booting from SD
> > card
> 
> Many thanks!
> Is the earlier PCEngines alix2d13 (with CF card) continue to be supported as
> well?

yes.

kp

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Bering-uClibc-6.0.0 introduces the new major version of LEAF Bering-uClibc

[kp kirchdoerfer]

Hi Marko

Am Dienstag, 25. Oktober 2016, 18:27:59 schrieb Mark Berndt:
> I have some problem with openvpn not starting.  I will post another thread
> later when I get a chance to look at it.  Other than that, all is good.
> 
> cheers
> Marko

Is this still an issue?

just curious
kp

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] leaf upgrade versioning

[kp kirchdoerfer]

Hi Andrew;

Am Samstag, 29. Oktober 2016, 20:12:11 schrieb Andrew:
> hi.
> 
> about versioning:
> 
>  The current proposed translation is:
> 
>  5.2.8 -> 52800
>  6.0.0 -> 6
>  6.0.0-minorfix -> 60001
>  6.0.1-beta1 -> 60010
>  6.0.1-rc-1 -> 60020
>  6.0.1 -> 60100
>  6.0.1-minorfix -> 60101
>  6.0.2-beta1 -> 60110
> 
> this limits versioning to max 10 releases per branch. I think that it'll be
> better to use 2 digits per release (for ex., 5020800).

Good catch! I've started with 508020 as well, but get confused, when thinking 
about extra release versions with minor, though important fixes between 
releases, something Erich worked with in the past.

You're right we need seven digits.


kp

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-commits] [bering-uclibc] Repository for Bering-uClibc. branch remove_moddb deleted. v5.2.5-rc1-160-g53cc407

[kp kirchdoerfer]

Am Sonntag, 23. Oktober 2016, 16:58:23 schrieb Erich Titl:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "Repository for Bering-uClibc.".
> 
> The branch, remove_moddb has been deleted
>was  53cc407d731ab3cf0ba9d7dba40aaa027dba3625
> 
> ---
> 53cc407d731ab3cf0ba9d7dba40aaa027dba3625 let /lib/modules/$KVER stay after
> linuxrc
> ---
> 
> 
> hooks/post-receive


Das hat noch nicht geklappt

it branch -r
  origin/HEAD -> origin/master
  origin/andrew/extend_initrd
  origin/maint
  origin/maint-4.3
  origin/maint-5.0
  origin/maint-5.1
  origin/maint-5.2
  origin/master
  origin/new-initrd
  origin/new-initrd-6.x
  origin/new-kernel
  origin/next
  origin/pu
  origin/remove_moddb
  origin/ybl/modules-OO
  origin/yves/buildtool-annex
  origin/yves/git_archive_download


Hast du

git push origin :remove_moddb

ausgeführt?

gruss kp



--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
leaf-git-commits mailing list
leaf-git-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-git-commits

[leaf-user] Bering-uClibc-6.0.0 introduces the new major version of LEAF Bering-uClibc

[kp kirchdoerfer]

Hi all

After a year development started and five month after the first alpha release
a new major version of LEAF Bering-uClibc is considered stable.

Major features of the 6.0.0 version are:
* upgrading uClibc to uClibc-ng, receiving maintenance and regular updates 
(1.0.17)
* upgrading to current LTS Linux kernel 4.4 (4.4.26)
* initmod.lrp has been removed, after having been splitted from initrd.lrp 
four years ago.
The kernel drivers previously loaded from initmod.lrp are now either included 
in the kernel or 
will be loaded by demand, like shorewall init does.
This way we free up RAM and it will improve boot time significantly. 
* a new WRAP optimized kernel and image is provided
* firmware is saved via local.lrp
* logrotation has been improved (see /etc/logrotate.d/syslog)
In addition /var/log/messages has been removed, previously containing entries 
also available in other 
log files and therefore only wasting (RAM) space.
* A new package libpam to support PAM access with openvpn has been added (Thx 
to dino muzic for his help getting that done)
* perl has been updated to 5.24.0
* The Raspberry image, still a proof of concept, supports booting with device 
tree (and overlays)
* Support for PCEngines APU2 incl watchdog support and booting from SD card

Most of the remaining packages has received updates to the latest
upstream versions. 
See https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.0.x_-_Changelog
for more details.

* Upgrade considerations
Please note: Due to the removal of initmod upgrading from 5.x to 6.0.0 will 
not work as seamless as usual.
If you don't setup a new router from scratch, be aware that you have to change 
syslinux.cfg otherwise it may fail to boot.

To get an upgrade properly done, you need to replace 
DEFAULT linux initrd=/initrd.lrp,/initmod.lrp
with
DEFAULT linux initrd=/initrd.lrp

(See also 
https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.x_-_User_Guide_-_Appendices_-_Upgrading_from_Bering-uClibc_5.x)

In the past the upgrade utility has been improved, but due to changes outlined 
above it won't work to use it to upgrade from 5.2.x to 6.0.0.
As a result we do not offer 6.0.0 for the upcoming weeks. Once we add 6.0.0 to 
latest or stable, please do not use upgrade to update your 5.2.x router 
without taking the above made considerations seriously.
It may work, if you change syslinux.cfg by hand, but it isn't recommended 
unless you have a backup or using dual boot.

With 6.0.0 becoming stable, the 5.2 series will be put on hold with one, final 
release left for 5.2.8.

kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[leaf-devel] git branches refreshed

[kp kirchdoerfer]

Hi Gents;

I've created a new branch maint-5.2, containing previous maint (5.2.x ) with 
the purpose to commit fixes to 5.2.x if necessary, and merged master into maint 
(now 6.0.x).
maint should be for fixes and changes for the 6.0.x series.

master is open for development >= 6.1.x

Andrew now is the time to merge extend_initrd which worked pretty well in a 
test environment.

Please be more careful, than I have been with my first commit by old habits 
after moving branches,  when committing changes to choose the correct branch.

thx kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[kp kirchdoerfer]

Am Montag, 3. Oktober 2016, 10:41:05 schrieb Andrew:
> On 02.10.2016 23:37, Erich Titl wrote:
> > Hi Andrew
> > 
> > Am 02.10.2016 um 19:58 schrieb Andrew:
> >> On 02.10.2016 20:45, Erich Titl wrote
> >> 
> > :...
> > :
> >>> We need to find out if this is an issue for the majority of our users.
> >>> most of the drivers will probably just work as they work in standad
> >>> distros.
> >> 
> >> This is issue for everybody who uses intel server cards in high-load
> >> applications.
> > 
> > Yes and this is why I asked if this was an issue for the _majority_
> 
> I don't know statistics how much people uses LEAF as home box/small
> office router, and how much people uses LEAF somewhere in production
> environment with high traffic.
> I know at least some people who uses LEAF in production (access
> servers/borders/etc), and I know only one case of usage as office
> router(just because soho router in that place frequently hangs).
> 
> > ...
> > 
> >> Actually intel NIC card is the only available choice for high-troughput
> >> routing. Other cards have too high CPU usage, or starts to drop packets
> >> at 60-70% of bandwidth usage.
> > 
> > So on a Gbit card you would have a throughput of roughly 600 Mbit. For
> > most users and I said _most_ users they will never be able to buy that
> > much power.
> > 
> > And unless you have a massive parallel system you will have difficulties
> > to pass that much data through any kind of traffic management. I
> > observed issues in that aera, never at NIC level.
> > 
> > So - yes, if it isn't a home routing box,
> > 
> >> it uses Intel NIC.
> > 
> > Still the same question, is this an issue for the majority and therefore
> > a killer criterion? It might well be so, but I would like to know numbers.
> > 
> > I for once do not have any intel NICs in usage, but yes, I did use them
> > a few years back and might have been happy to have hight troughput, but;
> > even then I never had a saturation issue at hand. YMMV
> > 
> > Still I would not consider it a killer criterion, but yes, if someone is
> > willing to put in the effort to overcome limitations in that area,
> > great. I understand that you are working in a high speed/throughput
> > environment and there I see of course the usefulness of having
> > specialized drivers, but I _guess_ the majority of our users are not
> > limited there. They have problems in the integration of some of our
> > packages as seen lately in the leaf-user list.
> > 
> > cheers and yes, please if you have spare time to integrate those
> > drivers, go for it.
> > 
> > ET
> 
> It isn't too hard to integrate them. I'll try to update drivers to
> latest version in master (which is 4.4-based), because there's no
> 4.7-based branch in git.

This was meant as testing what has to be done when moving to a newer kernl, 
prefrrably a LTS as well.
And it occured that migrations issues will be with e1000e and igb.

There will be enough time to solve once we move on.

kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] intel network drivers

[kp kirchdoerfer]

Am Sonntag, 2. Oktober 2016, 19:48:21 schrieb Andrew:
> On 02.10.2016 19:36, kp kirchdoerfer wrote:
> > Hi;
> > 
> > Am Sonntag, 2. Oktober 2016, 19:29:37 schrieb Andrew:
> >> Hi.
> >> 
> >> Built-in drivers have much less parameters. For ex., interrupt
> >> throttling, etc.
> > 
> > Is this also true for kernel driver 4.7+?
> 
> I think yes. You may try to look in source.

Only when needed :))

> 
> > If so, we'll need certainly need to fix the buildtoo setup, when moving to
> > a newer kernel.
> 
> Just update e1000e/igb drivers, + fix other kernel-related packages.

Yes, it occurs it's all what's needed- though it will require some more work - 
e.g. the patches for cross-compile fail...

That's why I've asked.

Anyway it's not important immediately, just observations, when trying to catch 
up with newer kernels.

kp 

> > kp
> > 
> >> On 02.10.2016 19:25, kp kirchdoerfer wrote:
> >>> Hi;
> >>> 
> >>> I've had some spare time and was looking at what is ahead .
> >>> 
> >>> I've updated for testing uclibc-ng to 1.0.18 (which seems about 100 kb
> >>> smaller) and kernel 4.7.6 (which seems about 100 kb larger).
> >>> 
> >>> A few packages are failing to compile - notably ipt-netflow (looking
> >>> into
> >>> the src repository it claims to be for kernel up to 4.4; and both
> >>> packages providing Intel network drivers  (igb and e1000e) fail to
> >>> build.
> >>> 
> >>> Is there any advantage to use these compared to the ones in the kernel
> >>> source?
> >>> 
> >>> kp
>

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] intel network drivers

[kp kirchdoerfer]

Hi;

I've had some spare time and was looking at what is ahead .

I've updated for testing uclibc-ng to 1.0.18 (which seems about 100 kb 
smaller) and kernel 4.7.6 (which seems about 100 kb larger).

A few packages are failing to compile - notably ipt-netflow (looking into the 
src repository it claims to be for kernel up to 4.4; and both packages 
providing Intel network drivers  (igb and e1000e) fail to build.

Is there any advantage to use these compared to the ones in the kernel source?

kp

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] More/Many Missing Drivers in 5.2.x Series?!

[kp kirchdoerfer]

Am Sonntag, 4. September 2016, 18:45:56 schrieb groups, freeman:
> Having setup BuC5.2.7 under a VM and gotten it all setup I went to run
> it on my production machine (an old ASUS mobo with Semperon 3400+ CPU)
> and came up missing some more drivers.
> 
> Of particular urgency is for me is the 'forcedeth' drive
> (/kernel/drivers/net/ethernet/nvidia), since this is the netcard built
> into the mobo.
> 
> In my diagnosing this absence I ran 'lspci -k' and got an interesting
> comparison between the drivers included in (and some used by me) in BuC
> 5.1.5, and the current 5.2.7.
> 
> In my case I no longer had 'k8temp' driver (for CPU temp monitoring).
> 
> Also absent were 'i2c-nforce2' (SMbus stuff, maybe temp/fanspeed sensor
> related) and 'pcieport' (which I couldn't locate within the modules of
> 5.1.5, but is tagged in lspci as 'PCI bridge: NVIDIA Corporation MCP61
> PCI Express bridge (rev a2)').
> 
> When I did a more detailed comparison of drivers of 515 versus 527, as a
> quick & dirty I counted 200 files that were in 515 but weren't in 527
> (coming to 4.1MB).
> 
> If there's a willingness to restore some or all of the drivers that used
> to be in 515, I'd point to the ones found in:
> - /kernel/drivers/acpi/*(pwr mgmt?)
> - /kernel/drivers/i2c/*(temps sensors, etc)
> - /kernel/drivers/hwmon/*(temps sensors, etc)
> - /kernel/drivers/cpufreq/*(cpu throttling?)
> - /kernel/drivers/net/ethernet/*(esp 'atheros' & 'broadcom')
> - /kernel/fs/ext2/*(ext2 driver?!?!)
> - /kernel/fs/ext3/*(ext3 driver?!?!)
> - /kernel/drivers/usb/usb-common(required by other drivers?!)
> 
> as key candidates, in addition to my current need for 'forcedeth'.
> (Hopefully it'll be under the 5.2 series? : )
> 
> Cheers & thanks again for LEAF - I guess I'm one of the few remaining
> who use it on old repurposed PC's!

But it should work there also.

I'll look into the issues; some are really missing, others like ext2/3 are 
replaced by a common driver like ext4 supporting ext2 and ext3 as well, others 
are provided AFAIK (hwmon, i2c), though special modules might be missing.

Of course what's needed, will be added to 5.2 series.

Again the suggestion the suggestion to users , pls test early to get it fixed 
ASAP - 5.2 is nearly a year old...

kp



--

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Seeking vmxnet3 driver; was: Re: Missing AMD/PCnet32 Driver from 5.2.*?

[kp kirchdoerfer]

Am Freitag, 2. September 2016, 13:36:08 schrieb groups, freeman:
> On 16/09/01 13:09, kp kirchdoerfer wrote:
> > HI;
> > 
> > Am Mittwoch, 31. August 2016, 19:49:43 schrieb groups, freeman:
> >> I seem to need the an AMD 79C970 driver (which is fulfilled by PCnet32)
> >> for my VMWare Player v5 testbed.
> >> 
> >> [...]
> > 
> > Yes you are right, and yes it will be added into next version.
> > 
> > kp
> 
> Super, thanks!
> 
> I also discovered a workaround for the interim - by adding the
> not-configurable-by-GUI line:
>ethernet0.virtualDev = "e1000"
> 
> to the VM's .vmx configfile. (Also valid, to VMware v5 anyway, are
> 'vmxnet,' 'vmxnet3,' 'e1000e' and 'vlance' [the default and the source
> of my need for the AMD driver] though IIRC none had drivers within LEAF).
> 
> KP, might you consider also the addition of the vmxnet3 adapter?
> (/drivers/net/vmxnet3 folder in the kernel tree.) Per VMware's KB
> article "Choosing a network adapter for your virtual machine (1001805)"
> (
> https://kb.vmware.com/selfservice/microsites/search.do?language=en_US=di
> splayKC=1001805 ) it's billed as "the next generation of a
> paravirtualized NIC designed for performance".

Ok, I've changed kernel config to build the  module.

Also changed the 4.4 kernel config of the upcoming 6.0.0-beta1 version to add 
the AMD and vmxnet3 modules to modules.sqfs.

kp

--

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Missing AMD/PCnet32 Driver from 5.2.*?

[kp kirchdoerfer]

HI;

Am Mittwoch, 31. August 2016, 19:49:43 schrieb groups, freeman:
> I seem to need the an AMD 79C970 driver (which is fulfilled by PCnet32)
> for my VMWare Player v5 testbed.
> 
> Trying BuC v5.2.7, I notice that the modules.sqfs filesystem contains no
> "amd" dir under the 'drivers/net' subdir and since the pcnet32 driver is
> stored in that 'amd' dir, it explains the driver's absence. (The 'amd'
> dir seems to be missing going back to at least BuC v5.2.2).
> 
> Could someone let me know if that's a correct observation & all, and if
> in a future BuC release the 'amd' dir's drivers shall be included?
> 
> Cheers & thanks for LEAF!

Yes you are right, and yes it will be added into next version.

kp


--

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] PC Engines APU2 - Having Trouble Booting BuC 5.2.x

[kp kirchdoerfer]

Am Samstag, 13. August 2016, 11:56:26 schrieb David M Brooke:
> Thanks for the feedback.
> 
> @Andrew - removing ‘quiet’ didn’t provide any further diagnostics.
> 
> I upgraded to the latest APU2 BIOS / firmware to see if that helped.
> Since that supports iPXE boot I was able to pull in the BuC x86_64 kernel
> and initrd, initmod. That worked fine so there’s no compatibility issue,
> but it still doesn’t want to boot from the SD.
> 
> @kp - which device are you using to boot from - an mSATA drive, USB or the
> SD slot? Maybe I need to invest in a small mSATA drive.

I boot from mSATA, also USB worked, at least  for the installation.

I have also an older bios (1/20/2016), and neither checked SD cards nor iPXE.

kp

> Thanks,
> David
> 
> > On 12 Aug 2016, at 23:17, kp kirchdoerfer <kap...@users.sourceforge.net>
> > wrote:
> > 
> > Hi David;
> > 
> > Am Freitag, 12. August 2016, 12:02:56 schrieb Andrew:
> >> Hi.
> >> 
> >> Try to remove 'quiet' option from kernel line. Maybe it'll say you some
> >> more info.
> >> 
> >> On 12.08.2016 00:17, David M Brooke wrote:
> >>> Hi Leaf Users,
> >>> 
> >>> Does anybody have experience of using the PC Engines APU2 boards with
> >>> BuC
> >>> 5.2.x ?
> >>> 
> >>> I have a brand new apu2c4 board with the 20160307 BIOS.
> >>> I know the board is good because it works OK with PC Engines’ TinyCore
> >>> Linux.
> >>> 
> >>> I've tried using the
> >>> Bering-uClibc_5.2.6_i686_syslinux_serial115200.tar.gz
> >>> image extracted onto an SD card with a 2GB FAT32 partition, mounted in
> >>> the on-board SD slot. It boots into SYSLINUX (v6.03) OK and I see the LP
> >>> shield logo via the serial console>
> >>> 
> >>> but it hangs after:
> >>> Loading /syslinux/linux… ok
> >>> Loading /initrd.lrp… ok
> >>> Loading /initmod.lrp… ok
> >>> 
> >>> That implies it’s loading the files OK but it’s not able to boot the
> >>> kernel, right?
> >>> 
> >>> I’ve tried a few other BuC versions (5.1.7, 5.2.7-rc1) and also the
> >>> x86_64
> >>> variant but with the same result. I’ve also tried using the SD card in a
> >>> USB adaptor (so the APU sees it as USB) but again the same result.
> >>> 
> >>> On the Hardware Specific Guides page for the APU board I see evidence
> >>> the
> >>> APU is working but maybe the APU2 needs different drivers or something?
> > 
> > I'm running 5.2 on a APU2. I use the x86_64 version and boot from ext4
> > partition. Other than that it should be the stock image.
> > 
> > kp
> 
> 
> -- What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic patterns at an interface-level. Reveals which users, apps, and
> protocols are consuming the most bandwidth. Provides multi-vendor support
> for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using
> capacity planning reports. http://sdm.link/zohodev2dev
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] PC Engines APU2 - Having Trouble Booting BuC 5.2.x

[kp kirchdoerfer]

Hi David;

Am Freitag, 12. August 2016, 12:02:56 schrieb Andrew:
> Hi.
> 
> Try to remove 'quiet' option from kernel line. Maybe it'll say you some
> more info.
> 
> On 12.08.2016 00:17, David M Brooke wrote:
> > Hi Leaf Users,
> > 
> > Does anybody have experience of using the PC Engines APU2 boards with BuC
> > 5.2.x ?
> > 
> > I have a brand new apu2c4 board with the 20160307 BIOS.
> > I know the board is good because it works OK with PC Engines’ TinyCore
> > Linux.
> > 
> > I've tried using the Bering-uClibc_5.2.6_i686_syslinux_serial115200.tar.gz
> > image extracted onto an SD card with a 2GB FAT32 partition, mounted in
> > the on-board SD slot. It boots into SYSLINUX (v6.03) OK and I see the LP
> > shield logo via the serial console> 
> > but it hangs after:
> >  Loading /syslinux/linux… ok
> >  Loading /initrd.lrp… ok
> >  Loading /initmod.lrp… ok
> > 
> > That implies it’s loading the files OK but it’s not able to boot the
> > kernel, right?
> > 
> > I’ve tried a few other BuC versions (5.1.7, 5.2.7-rc1) and also the x86_64
> > variant but with the same result. I’ve also tried using the SD card in a
> > USB adaptor (so the APU sees it as USB) but again the same result.
> > 
> > On the Hardware Specific Guides page for the APU board I see evidence the
> > APU is working but maybe the APU2 needs different drivers or something?


I'm running 5.2 on a APU2. I use the x86_64 version and boot from ext4 
partition. Other than that it should be the stock image.

kp


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[leaf-devel] linux-headers

[kp kirchdoerfer]

Hi Andrew;

I saw you committed new linux-headers to toolchain.
Just out of interest, has there been anythin wrong with the tarball I 
committed a few days ago, and if so what have I done wrong?

I did 
#./buildtool.pl headers linux 
#cd headers/include
#tar cvfJ  repo/toolchain/linux-headers.tar.xz headers/include/

I'll add a note to the deveoper wiki pages, if that the way to go or a 
corrected procedure if needed.

kp



--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] 6.0.0-beta

[kp kirchdoerfer]

Hi Andrew;

Am Donnerstag, 28. Juli 2016, 12:24:58 schrieb Andrew:
> Hi.
> 
> I think that we should move root, config and maybe some other 'core'
> packages to initrd - to make it possible to run on tiny systems with
> small amount of RAM and available persistent ROM for permanently mounted
> initrd (like SOHO routers).

Looks almost like a packaging task, or am I wrong?
Do you expect space savings or just simplification?

I think the most important task for very small platforms is to get rid of 
modules.sqfs.
E.g. the modules for rpi kernel is still 4.9MB, and of course it can be 
reduced nect to zero, if decisions are made what devices will be supoorted and  
what not - though rpi is still an somewhat open platform and with enough space 
on the CF and RAM, so I'm not bothered too much; but for closed SOHO routers 
this won't be acceptable. 

Not shure if we should add it to 6.0.0 (for a beta), but if we do make steps 
forward it could be at least for 6.1.0, which could be targeted until end of 
year if things goes well. 
Will you try in a new branch??


For 6.0.0 an issue with perf needs to be solved, may I ask you to have a look 
at it first?
 
> Also, on beta release we should also freeze uClibc-ng version for this
> branch.

Agreed.

kp

> 27.07.2016 20:03, kp kirchdoerfer пишет:
> > Hi all;
> > 
> > I've comitted changes to support the linux 4.4.x kernel for raspberry pi
> > boards rev 1.
> > While the raspberry pi 1 was mainly a proof-of-concept, we now support all
> > the platforms that we did with 5.2.x.
> > With the changes for rpi rev 1, we do have an example how to support
> > booting architectures depending on device trees (and overlays) - though
> > it shurely can be improved.
> > 
> > Done that it, I think we are on the way to a first beta version for 6.0.0.
> > Therefor I'd like to pint you to some errors during a complete build amd
> > packaging of the sources in git.
> > 
> > There aren't many, but
> > 
> > perf  fails to build
> > initmod fails to build (no surprise, as we do not need initmod anymore)
> > ... maybe i forgot one more?
> > 
> > 
> > Any help to fix that errors are welcome.
> > 
> > Any ideas what should be accomplished before moving forward to a first
> > beta?
> > 
> > regards kp
> > 
> > --
> >  What NetFlow Analyzer can do for you? Monitors network bandwidth and
> > traffic patterns at an interface-level. Reveals which users, apps, and
> > protocols are consuming the most bandwidth. Provides multi-vendor support
> > for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using
> > capacity planning reports.http://sdm.link/zohodev2dev
> > 
> > ___
> > leaf-devel mailing list
> > leaf-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/leaf-devel
> 
> 
> --
> 
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] 6.0.0-beta

[kp kirchdoerfer]

Hi all;

I've comitted changes to support the linux 4.4.x kernel for raspberry pi 
boards rev 1. 
While the raspberry pi 1 was mainly a proof-of-concept, we now support all the 
platforms that we did with 5.2.x.
With the changes for rpi rev 1, we do have an example how to support booting 
architectures depending on device trees (and overlays) - though it shurely can 
be improved.

Done that it, I think we are on the way to a first beta version for 6.0.0.
Therefor I'd like to pint you to some errors during a complete build amd 
packaging of the sources in git.

There aren't many, but
 
perf  fails to build
initmod fails to build (no surprise, as we do not need initmod anymore)
... maybe i forgot one more?


Any help to fix that errors are welcome.

Any ideas what should be accomplished before moving forward to a first beta?

regards kp

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] problem with upgrade 5.2.6-rc1 -> 5.2.6

[kp kirchdoerfer]

Hi;

Am Dienstag, 21. Juni 2016, 12:01:05 schrieb Erich Titl:
> Hi Berndt
> 
> Am 21.06.2016 um 11:50 schrieb Mark Berndt:
> > there is plenty of free space in /tmp, but the upgrade script fails:
> > 
> > firewall# df
> > Filesystem   1K-blocks  Used Available Use% Mounted on
> > tmpfs   524288 18204506084   3% /tmp
> > tmpfs   131072   692130380   1% /var/log
> > root131072 31864 99208  24% /
> > 
> > 
> > firewall# upgrade -v --stable
> > upgrade: compare_installed: cannot check linux, it is missing on
> > sha1sum.list
> Mhhh loks like the sha1sum.list was not installed on the server.

Indeed the sha1sum-list is missing for x86_64.
Either I did something wrong when preparing and commiting or there is a bug in 
the release-to-git script we use.
Erich, any idea?

> > upgrade: compare_installed: cannot check initmod.lrp, it is missing on
> > sha1sum.list
> > upgrade: compare_installed: cannot check modules.sqfs, it is missing on
> > sha1sum.list
> > upgrade: could not extract /tmp/tmp.mBMLah/astmoh.lrp
> 
> This is bad, well you don't have enough temprorary storage to extract
> astmoh, whatever that package is. If you have enough memory, try to grow
> /tmp

It's part of the asterisk suite. If one does not use asterisk it can be 
deleted on the disk as well as other ast* packages.

kp


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] small dhcpd/shorewall problem in 5.2.6

[kp kirchdoerfer]

HI Timothy;

Am Freitag, 3. Juni 2016, 18:58:09 schrieb Timothy Wegner:
> I have a LEAF router  on a Soekris box.
> 
> LEAF Bering-uClibc 5.2.6-rc1 works perfectly. But 5.2.6 does not. Shorewall
> complains that it can't get an ip and won't start, and the boot messages
> just before shorewall runs indicate that an ipv6 ip was obtained but not
> ipv4.  After boot, the ip addr show command shows that an ipv4 ip was in
> fact obtained (eventually). So strangely, if I just run webmin after boot
> (which shows shorewall not started) and start shorewall all is well and
> everything works.
> 
> I would appreciate any suggestions of what might have changed between 5.2.6
> rc1 and the 5.2.6 versions that might have caused the behavior change. The
> exact same configdb.lrp is used in both cases. I updated by hand by just
> copying everything except leaf.cfg, configdb.lrp, and ldlinux.sys. I used
> the Bering-uClibc_5.2.6_x86_64_syslinux_serial115200.tar.gz version.


For the complete changelog see:

http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.2.x_-_Changelog#Changes_between_5.2.6-rc1_and_5.2.6

Only the kernel update could be a cause, if at all.

For more diagnostics you may try to change dhcpcd.conf
- enable debug
- disable switch to background
- ENABLE a a timeout (e.g. 60), otherwise if something goes wrong, the boot 
process will stop here forever and it will be a pain to get it up and running 
again.


kp


> Thanks,
> 
> Tim
> 
> Below are two fragments of the boot messages, the first from rc1. As you
> can see, in 5.2.6 rc1 dhcpcd reports a few lines more than 5.2.6 (see bold).
> 
> 5.2.6 rc1:
> 
> dhcpcd[11482]: eth0: adding address 2001:558:6022:13:e927:a4e3:a97e:5064/128
> dhcpcd[11482]: eth0: renew in 172800 seconds, rebind in 276480 seconds
> *dhcpcd[11482]: eth0: leased 98.201.221.124 for 299348 seconds*
> *dhcpcd[11482]: eth0: adding route to 98.201.220.0/23
> *
> *dhcpcd[11482]: eth0: adding default route via 98.201.220.1*
> dhcpcd[11482]: forked to background, child pid 11523
> done.
> Starting software watchdog... done.
> Starting caching dns forwarder: dnsmasq.
> Starting ulogd: ulogd.
> Starting "Shorewall firewall": Compiling using Shorewall 4.6.13.4...
> Shorewall configuration compiled to /var/lib/.start
> Starting Shorewall
> done.
> 
> 
> 5.2.6:
> 
> dhcpcd[11514]: eth0: adding address 2001:558:6022:13:c102:74f4:65a9:de80/128
> dhcpcd[11514]: eth0: renew in 172800 seconds, rebind in 276480 seconds
> dhcpcd[11514]: forked to background, child pid 11554
> done.
> Starting software watchdog... done.
> Starting caching dns forwarder: dnsmasq.
> Starting ulogd: ulogd.
> Starting "Shorewall firewall":*ERROR: Can't determine the IP address of
> eth0*
> Terminated
> 
> -- What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic patterns at an interface-level. Reveals which users, apps, and
> protocols are consuming the most bandwidth. Provides multi-vendor support
> for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using
> capacity planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] Something has changed with master

[kp kirchdoerfer]

Am Samstag, 7. Mai 2016, 17:59:55 schrieb Erich Titl:
> Hi Folks
> 
> I tried to look into the init bug, just to run into one with the build
> environment
> 
> mega@leafbuilder64:~/leaf/devel/bering-uclibc$ git branch
>maint
> * master
>new-initrd
>new_upgrade
> mega@leafbuilder64:~/leaf/devel/bering-uclibc$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> 
> nothing to commit, working directory clean
> mega@leafbuilder64:~/leaf/devel/bering-uclibc$ ./buildtool.pl srcclean
> initrd
> Error: can't expand variable $uClibc_loader_link2
> 
> What happened here and why does it affec me?

commit here:

e0d04e358c9173b843efce293d59ef922180d487

ld*-uClibc.so.1 is needed for uClibc-ng

git pull rebase?

kp

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] init problem sda1 still mounted

[kp kirchdoerfer]

Hi Erich;

Am Montag, 11. April 2016, 21:24:53 schrieb Erich Titl:
> Hi KP
> 
> Am 11.04.2016 um 15:39 schrieb kp kirchdoerfer:
> > Am Samstag, 9. April 2016, 14:23:31 schrieb Erich Titl:
> 
> 
> >> Need to look into linuxrc, where this should be umounted. As I forgot
> >> the charger for my other laptop, I have no access to the source code,
> >> sorry.> 
> > Another observation: it only happens with vfat formated sda1, formating
> > with ext[234] doesn't show this error.
> 
> This is completely weird, AFAIK the code does not make a difference
> between file system types. It could be a race situation unmounting the
> device and if so IMHO it would be a driver bug

Yes it is weird, but I doubt it's a kernel driver bug.
Pls have a look yourself, I'd consider it as a showstopper, because it breaks 
a mostly working install routine from ISO to sda.

kp
(Pls note; I'll be offline for a week from tomorrow)

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Update(grade) to Bering 5.x

[kp kirchdoerfer]

Am Sonntag, 10. April 2016, 22:57:58 schrieb n22e113:
> On 4/9/2016 05:51, kp kirchdoerfer wrote:
> > But why do I invest time as Linux user to explain other Linux users
> > ancient
> > Windows filesystem limitations? I could have used Windows if I'm
> > interested in such problems. I use ext4 on my routers instead.
> 
> Just to report that by using alix2d3, Grub 0.97x and ext2 (ext4 module) file
> system, I also ran into this bug and unable to copy (via bash script) the
> entire unzipped tar.gz file to a 512mb or 1GB CF from a Debian based system
> using a SATA-to-CF card in the past. Don't remember exactly the workaround?
> Will report back if I have a solution. Cheers!


Hi;

I've checked in a VM.
vfat shows the error with 512 root-dir-entries; ext2/3/4 works.

So it could be a also problem with formating CF cards, but then it's a 
different issue IMHO

We better try to fix one pb after another tahn mixing things up.

kp 

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] init problem sda1 still mounted

[kp kirchdoerfer]

Am Samstag, 9. April 2016, 14:23:31 schrieb Erich Titl:
> Hi KP
> 
> Am 09.04.2016 10:44, schrieb kp kirchdoerfer:
> > Hi;
> > 
> > I've booted LEAF 6.0.0-alpha1 iso image in a vm with an attached (virtual)
> > hd. If the disk is partitioned and formatted it will be mounted during
> > boot, but never umounted.
> > 
> > mount shows
> > /dev/sda1 on /tmp/tmp.kci8fg type vfat etc
> > 
> > This shouldn't happen.
> > I suspect the problem is in linuxrc/init.
> 
> Yes I guess this is possible. Probably something that is not checked in
> the current linuxrc. I have never used a CD image so I would not know.
> 
> > Any ideas how to solve?
> 
> Need to look into linuxrc, where this should be umounted. As I forgot
> the charger for my other laptop, I have no access to the source code, sorry.

Another observation: it only happens with vfat formated sda1, formating with 
ext[234] doesn't show this error.


kp

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] init problem sda1 still mounted

[kp kirchdoerfer]

Am Sonntag, 10. April 2016, 15:49:21 schrieb Erich Titl:
> Hi KP
> 
> Am 10.04.2016 14:55, schrieb kp kirchdoerfer:
> > Hi Erich;
> 
> ...
> 
> >>>> Need to look into linuxrc, where this should be umounted. As I forgot
> >>>> the charger for my other laptop, I have no access to the source code,
> >>>> sorry.>
> >>> 
> >>> Are you away for a few days, or will it have to wait until end of
> >>> summer?
> >> 
> >> You will have to wait until I have a power supply for my laptop :-)
> > 
> > Ok.
> > I'll wait until you are charged :))
> 
> with murder?

power.

kp

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] init problem sda1 still mounted

[kp kirchdoerfer]

Hi Erich;

Am Sonntag, 10. April 2016, 14:18:34 schrieb Erich Titl:
> Hi KP
> 
> Am 10.04.2016 13:28, schrieb kp kirchdoerfer:
> > Hi;
> 
> ...
> 
> >> Need to look into linuxrc, where this should be umounted. As I forgot
> >> the charger for my other laptop, I have no access to the source code,
> >> sorry.> 
> > Are you away for a few days, or will it have to wait until end of summer?
> 
> You will have to wait until I have a power supply for my laptop :-)

Ok.
I'll wait until you are charged :))

> >> On the otherr tread about the amount of directory/FAT table entries.
> >> Nobody will ever need all the LEAF packages, so copying all of them is
> >> plain crazyness. Upgrade could provide a solution, elsse maybe the
> >> images should just hold the basic packages and we should point to a
> >> package repository. This would make thesee errors go away.
> > 
> > It will not help, if a user loads more packages than the ~80MB limit, or
> > less if he'll add a unknown amount packages with long names(?), from a
> > packages repository.
> 
> No _reasonable_ user has that many packages in use. Our images have just
> grown out of proportionwith all the new (necessary??) packages.


First IMHO a technical pb should not be solved with assumptions about user 
behaviours or usage of LEAF.
Second, the Packages size is *one* limiting factor, using long names (>8.3) is 
another one. And  I don't want be to restricted to DOS 8.3 naming
limitations on a project I do for fun and get rid of it since I left DOS in 
the eighties of the last century.

We do have a solution without restricting ourself to an ancient file system.

> > It's a flaw, we have to solve otherwise.
> > 
> > We solved that limitation in install.sh, though I don't know what happens
> > if a user installs from ISO image to a 1GB partition, with a command
> > setting root- dir-entries to 1024 - for FAT32 it's to 0/ignored.
> > 
> > Probably the solution should be to make ext2/3/4 the default instead of
> > VFAT...?
> 
> Maybe, but then it requires some *X system to build it. I am thinking in
> the other direction. I _believe_ we have many reduntant packages and
> quite a number could be dropped. This would even make the build process
> quite a bit faster.

I'm talking about install.sh to install LEAF from an LEAF  ISO image onto the 
storage media , where the process of installation is totally within a Linux 
environment and under our control.

kp


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] init problem sda1 still mounted

[kp kirchdoerfer]

Hi;

Am Samstag, 9. April 2016, 14:23:31 schrieb Erich Titl:
> Hi KP
> 
> Am 09.04.2016 10:44, schrieb kp kirchdoerfer:
> > Hi;
> > 
> > I've booted LEAF 6.0.0-alpha1 iso image in a vm with an attached (virtual)
> > hd. If the disk is partitioned and formatted it will be mounted during
> > boot, but never umounted.
> > 
> > mount shows
> > /dev/sda1 on /tmp/tmp.kci8fg type vfat etc
> > 
> > This shouldn't happen.
> > I suspect the problem is in linuxrc/init.
> 
> Yes I guess this is possible. Probably something that is not checked in
> the current linuxrc. I have never used a CD image so I would not know.
> 
> > Any ideas how to solve?
> 
> Need to look into linuxrc, where this should be umounted. As I forgot
> the charger for my other laptop, I have no access to the source code, sorry.

Are you away for a few days, or will it have to wait until end of summer?

> On the otherr tread about the amount of directory/FAT table entries.
> Nobody will ever need all the LEAF packages, so copying all of them is
> plain crazyness. Upgrade could provide a solution, elsse maybe the
> images should just hold the basic packages and we should point to a
> package repository. This would make thesee errors go away.

It will not help, if a user loads more packages than the ~80MB limit, or less 
if he'll add a unknown amount packages with long names(?), from a packages 
repository.

It's a flaw, we have to solve otherwise.

We solved that limitation in install.sh, though I don't know what happens if a 
user installs from ISO image to a 1GB partition, with a command setting root-
dir-entries to 1024 - for FAT32 it's to 0/ignored. 

Probably the solution should be to make ext2/3/4 the default instead of 
VFAT...?

kp

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Update(grade) to Bering 5.x

[kp kirchdoerfer]

Hi Bob;

Am Samstag, 9. April 2016, 14:40:06 schrieb Bob von Knobloch:
> On 09/04/16 11:51, kp kirchdoerfer wrote:
> > We have long filenames on the iso image (>8.3). In FAT16 the
> > root-dir-entries may run out of space because of that (root-dir-entries
> > are  also used to store long filenames) . That's why copying into /
> > stopped at 80MB
> 
> Err... not in my case. The same, formatted CF only copied to 80MB using
> Linux, BUT copied 256MB using Windows. So it's not the formatting.
> 
> Still, this isn't really a LEAF topic as such.

Hopefully not, but depends :)  
I tried to explain what I know about this issue and point to a workaround I 
used.

>  > I use ext4 on my routers instead.
> 
> Can you boot Ext4 disks on a WRAP OK? Using grub or lilo? I'd be quite
> interested.

I haven't had a WRAP box, but it works for Alix Geode, APU and APU2.

I still use syslinux (resp extlinux [1]).

kp

[1] http://www.syslinux.org/wiki/index.php?title=EXTLINUX


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[leaf-devel] init problem sda1 still mounted

[kp kirchdoerfer]

Hi;

I've booted LEAF 6.0.0-alpha1 iso image in a vm with an attached (virtual) hd.
If the disk is partitioned and formatted it will be mounted during boot, but 
never umounted.

mount shows 
/dev/sda1 on /tmp/tmp.kci8fg type vfat etc

This shouldn't happen.
I suspect the problem is in linuxrc/init.
Any ideas how to solve?

kp

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Update(grade) to Bering 5.x

[kp kirchdoerfer]

Am Freitag, 8. April 2016, 13:41:03 schrieb David M Brooke:
> Thanks kp.
> 
> Now I understand what Andrew meant!  -r refers to the number of directory
> entries permitted (like inodes, I guess). From the man page:
> 
> -r root-dir-entries
> Select the number of entries available in the root directory.
> The default is 112 or 224 for floppies and 512 for hard disks.
> 
> From memory I would have expected 512 to be sufficient, but maybe not…
> 
> davidMbrooke

Hi David;

My findings are:

mkfs.(v)fat automatically chooses the best FAT size (12/16/32) for the size of 
the partition.

A partition of 500MB is formatted as FAT16 with 512 root-dir-entries by 
default.

A 1Gb partition is forammted as FAT32 with no root-dir-entries (by design)

We have long filenames on the iso image (>8.3). In FAT16 the root-dir-entries 
may run out of space because of that (root-dir-entries are  also used to store 
long filenames) . That's why copying into / stopped at 80MB 

It is no problem to copy all the 230MB from iso image to /tmp.

It is also no problem to copy the 230MB into the 1GB FAT32 formatted root, 
because FAT32 has a different way to store long filenames.

So either choosing 1GB or enhancing root-dir -entries works...

mkfs.fat has an option to choose the fat_size when formatting a partition ("-F 
32" for FAT32 of course).

This does not work on LEAF for whatever reason, so here is the bug :)

But why do I invest time as Linux user to explain other Linux users ancient 
Windows filesystem limitations? I could have used Windows if I'm interested in 
such problems. I use ext4 on my routers instead.

kp

http://stackoverflow.com/questions/11928982/what-is-the-difference-between-vfat-and-fat32-file-systems

has more information about FAT et al.



> > On 8 Apr 2016, at 13:27, kp kirchdoerfer <kap...@users.sourceforge.net>
> > wrote:> 
> > Am Freitag, 8. April 2016, 14:17:42 schrieb Bob von Knobloch:
> >> On 08/04/16 13:27, David M Brooke wrote:
> >>> And I thought it was just me who had this problem with CF cards!:-)
> >>> 
> >>> Out of interest, how big is the disk partition & what proportion of that
> >>> does 80MB represent?
> >>> 
> >>> Last time I looked into this, I wondered if some aspect of Linux thinks
> >>> the disk is only 50% of the size it really is...
> >>> 
> >>> davidMbrooke
> >> 
> >> Hi David,
> >> It seems we are not alone.
> >> 
> >> My CF has one partition of '256MByte'* when I copy the leaf.lrp files to
> >> it, it bombs always at the same file (approx 80MByte)*. So, approx 1/3.
> >> I also thought it was some nice figure like 1/2, but seems not to be.
> >> 
> >> * I'll check exact figures tonight, I don't have the hardware here, at
> >> work.
> >> 
> >> Cheers,
> >> 
> >> Bob
> > 
> > As Andrew said try to increase root fs when formatting
> > 
> > mkfs.vfat -r 1024
> > 
> > this helped me.
> > 
> > kp
> > 
> > --
> > 
> 
> -- 
> leaf-user mailing list: leaf-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-user
> Support Request -- http://leaf-project.org/


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Update(grade) to Bering 5.x

[kp kirchdoerfer]

Am Freitag, 8. April 2016, 14:17:42 schrieb Bob von Knobloch:
> On 08/04/16 13:27, David M Brooke wrote:
> > And I thought it was just me who had this problem with CF cards!:-)
> > 
> > Out of interest, how big is the disk partition & what proportion of that
> > does 80MB represent?
> > 
> > Last time I looked into this, I wondered if some aspect of Linux thinks
> > the disk is only 50% of the size it really is...
> > 
> > davidMbrooke
> 
> Hi David,
> It seems we are not alone.
> 
> My CF has one partition of '256MByte'* when I copy the leaf.lrp files to
> it, it bombs always at the same file (approx 80MByte)*. So, approx 1/3.
> I also thought it was some nice figure like 1/2, but seems not to be.
> 
> * I'll check exact figures tonight, I don't have the hardware here, at work.
> 
> Cheers,
> 
> Bob

As Andrew said try to increase root fs when formatting

mkfs.vfat -r 1024

this helped me.

kp

--

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] more obscure menu items

[kp kirchdoerfer]

Hi Erich;

Am Samstag, 2. April 2016, 13:31:19 schrieb Erich Titl:
> Am 02.04.2016 um 12:00 schrieb Andrew:
> > 02.04.2016 10:48, Erich Titl пишет:
> ...
> 
> >> You are right, but this is mostly due to the fact that the webconf
> >> interface does not attract our developers. Maybe the fact that it is
> >> written in shell keeps them away. Even big Cisco and HP routers/switches
> >> have quite powerful web interfaces.
> > 
> > AFAIK Cisco 65xx/76xx/ASR/etc are configured just via CLI. For ex:
> > http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration
> > /xe-3s/asr1000/dhcp-xe-3s-asr1000-book/config-dhcp-server-xe.html
> Well, I used a number of them in the past and definitely there was a GUI
> 
> >> Yes and the menu entry is completely misleading.
> > 
> > It comes from 3.x (or older) version w/o changes.
> 
> I know and it has been misleading for ages.
> 
> > How it should be named for more clear understanding?
> 
> /etc/hosts

I think this will not help in terms of user friendliness...

> >>> If you want to see some diag info - IMHO it'll be good to add separate
> >>> section with diag commands (like 'ip a' or 'iptraf' if it's available).
> >>> but it's easier to enter these commands in shell.
> >> 
> >> That is what I normally do, because I am quite familiar with the shell.
> >> 
> >> - The menu entries are partially misleading and not always useful
> >> - I just hate the editor called in the menu, so I prefer to use vi, but
> >> that is a very personal choice.
> > 
> > you can configure which editor you want to use.
> 
> I probably could, but then I hardly ever use lrcfg. I would like the
> LEAF boxes to be more user friendly, not for myself but for others.
> Developers are notoriously bad at user friendlyness, because they don't
> need it.
> 
> So everything can remain as is, but that does not make the LEAF software
> any better. From my past experience in product management and support it
> is always worth to make software user friendly. If you think that the
> lrcfg menu is adapted to the year 2016, please rethink.

lrcfg is known to work as it has matured over years, on the other hand it 
shows it's age.

If something new and fancy is needed, it can be added as lrcfg-ng, but it 
should stay (mostly) as-is, until something better catches up with lrcfg and 
provide enhancements.

IMHO providing a good and  up-to-date documentation with how-to's one can 
follow step-by-step etc will help users more than anything else to get his 
tasks done.  

You see preferences, how to make LEAF user friendly, vary and seems to be  
bound to personal habits, how one tries to  solve a task/problem.

None of us is wrong or right though.

kp










--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] What about removing moddb?

[kp kirchdoerfer]

Hi Erich;

Am Donnerstag, 31. März 2016, 19:00:45 schrieb Erich Titl:
> Hi KP
> 
> Am 31.03.2016 um 17:31 schrieb kp kirchdoerfer:
> ...>
> 
> > The name "hwdetect" is misleading. The more interesting part of hwdetect
> > now is loading modules from /etc/modules rather than loading hardware.
> > This way I can add pppoe to /etc/modules, run hwdtect (of "f" from lrcfg
> > menu) and get pppoe and modules it depends on (ppp*) loaded without
> > reboot. This is allows quick testing etc..
> 
> I believe there is a simpler script in /usr/sbin to accomplish this.
> Look for install_modules.
> You need not modify /etc/modules.

Good suggestion - I believe it' too new.

A command line option for help could be useful though. (see below)

Other than that it works.

But the way it is, I doubt this does work from lrcfg menu? 

Now what about merging hwdetect (with the ability to read from /etc/modules) 
with install_modules (using just the CLI) ? 
This way we can test from CLI without /etc/modules and with changing 
/etc/modules and testing from lrcfg menu?


kp



/usr/sbin/install_modules -h
logger: invalid option -- h
BusyBox v1.24.0 (2016-03-25 10:35:04 CET) multi-call binary.

Usage: logger [OPTIONS] [MESSAGE]

Write MESSAGE (or stdin) to syslog

-s  Log to stderr as well as the system log
-t TAG  [ 1577.055461] EXT4-fs (sda2): couldn't mount as ext3 due to 
feature incompatibilities
Log using the sp[ 1577.064539] EXT4-fs (sda2): couldn't mount as ext2 due to 
feature incompatibilities
ecified tag (defaults to user name)
-p PRIO Priority (numeric or facility.level pair)
install_modules: installing -h
modprobe: invalid option -- h
BusyBox v1.24.0 (2016-03-25 10:35:04 CET) multi-call binary.

Usage: modprobe [-alrqvsDb] MODULE [SYMBOL=VALUE]...

-a  Load multiple MODULEs
-l  List (MODULE is a pattern)
-r  Remove MODULE (stacks) or do autoclean
-q  Quiet
-v  Verbose
-s  Log to syslog
-D  Show dependencies
-b  Apply blacklist to module names too






--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] What about removing moddb?

[kp kirchdoerfer]

Am Montag, 28. März 2016, 22:13:37 schrieb Erich Titl:
> Am 27.03.2016 um 18:26 schrieb kp kirchdoerfer:
> > Am Sonntag, 27. März 2016, 16:03:06 schrieb Erich Titl:
> >> Hi KP
> >> 
> >> Am 26.03.2016 um 16:55 schrieb kp kirchdoerfer:
> >>> H Gents;
> >> 
> >> ...
> >> 
> >>> At last I changed hwdetect to neglect moddb, and to do not use
> >>> /var/lib/lrpkg/*.depmod any  longer - there is no need to copy modules
> >>> to
> >>> /lib/modules any more.
> >> 
> >> IMHO we could also ditch hwdetect. There is hardly any difference in the
> >> code than in linuxrc. WE might need to add mount_modules to the hotplug
> >> script though.
> > 
> > hotplug seems not to be a replacement for hwdetect.
> > 
> > Yes the hwdetect code is in linuxrc, but as I said it could be convenient
> > to run hwdetect and load modules *without reboot*.
> 
> What for? It is highly unlikely the hardware configration changes on a
> running machine. The only place I could see this is with unknown usb
> hardware. But then hwdetect needs to mount modules.

The name "hwdetect" is misleading. The more interesting part of hwdetect now 
is loading modules from /etc/modules rather than loading hardware.
This way I can add pppoe to /etc/modules, run hwdtect (of "f" from lrcfg menu) 
and get pppoe and modules it depends on (ppp*) loaded without reboot.
This is allows quick testing etc..


> > Another issue iI found is we are  creation, deletion, link and unlink
> > /lib/modules/$KVER add various places, which ends up in a link to itself
> > 
> > # ls -al /lib/modules/
> > lrwxrwxrwx1 root root12 Mar 27 18:18 4.4.6-x86_64 ->
> > /lib/modules
> 
> This link should not exist anymore. It is a leftover from the old
> linuxrc which may have survived.

I've made my work on removing moddb traces available as remote repository 
(remove_moddb) - pls review before it will be merged!
Maybe the leftover is solved as well.

thx kp


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Fwd: Re: Can't reconfigure my LEAF-WRAP box

[kp kirchdoerfer]

HI Bob;

Am Montag, 28. März 2016, 14:15:44 schrieb Bob von Knobloch:
> On 28/03/16 10:17, kp kirchdoerfer wrote:
> > What Fritzbox do you use?
> > Have you activated pppoe passthrough so the FB is only used as modem?
> > 
> > kp
> 
> Hi KP,
> It's a Fritzbox 7272.
> 
> I don't yet have VOIP enable (by Telekom). I want the simplest possible
> configuration (i.e. just the Fritzbox) for the 'changeover' day (14th.
> April). Trying to explain LEAF to a Telekom "engineer" (ha-ha) is just
> wasting time. They do know what a Fritzbox is, so I just want that
> connected to the wires on 14 April. I like a simple life - rarely get
> it, though :=)
> 
> At the moment, all is working on the Fritzbox alone (except the built-in
> DHCP server doesn't do proper internal DDNS (like dnsmasq), so I've
> filled out the hosts file on every machine (I've about 15 PCs and
> devices to manage - more than I thought). It's all working - just not as
> I want it.
> 
> The 7272 doesn't mention PPPOE pass-through, but it does allow it's WAN
> port to do IP , so I could (later) put the Fritz behind the LEAF, acting
> solely as a VOIP interface.

Tis won't work, as you'll need a VDSL modem to connect your LEAF box via VDSL 
to WAN.

> OR (what I really want)
> is to put the LEAF as a purely IP router behind the Fritz, using this
> only as a split between 'Internet' and VOIP. I.e. the Fritz acts just as
> a Modem as far as the (non-VOIP) network is concerned.

There are pure VDSL modems as I mentioned some weeks ago, but it seems you 
have made your choice to still use ISDN instead pure VOIP and choosed the 
Fritzbox to solve the ISDN issue.

It seems quite nasty to get such a combination running with box like LEAF. 
I had exactly one ISDN phone, though a nice one I have to say in hindsight,  
and decided to go solely with VOIP phone(s). 

Maybe this page helps
https://www.administrator.de/frage/fritzbox-7490-vdsl-modem-sonicwall-tz205-m%C3%B6glich-274824.html



> This puts my network directly on the LEAF box, which I trust far more
> than I do Mr. Fritz (which also had WLAN of unknown security and various
> dangerous protocols, for example 'UPN' running).
> Still plugging at the interface. When connected to a switch, it shows
> manic activity, but when connected to a PC with a cross cable there are
> no packets. I'm starting to wonder if it is damaged. Maybe I'll
> reconfigure to use only 3 interfaces and try that.

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Fwd: Re: Can't reconfigure my LEAF-WRAP box

[kp kirchdoerfer]

Am Sonntag, 27. März 2016, 21:45:01 schrieb Bob von Knobloch:
> On 27/03/16 15:08, David M Brooke wrote:
> > Hi Bob,
> > 
> > Not sure if it’s enough to explain your symptoms, but I don’t think it’s
> > correct to have the Gateway set the same as your Address.
> > 
> > davidMbrooke
> 
> Thanks David,
> that was obviously wrong (why didn't I see that?) but correcting it
> hasn't changed anything. I'll try and dig out a hub from somewhere and
> attempt to analyse what the box is sending, maybe that will give me a hint.
> If that doesn't work , I'll look at installing the latest version of
> LEAF, I'm not sure how well the WRAP boxes will be compatible (they are
> quite old now), but I think maybe Erich has some idea?
> Cheers,
>

What Fritzbox do you use?
Have you activated pppoe passthrough so the FB is only used as modem?

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] What about removing moddb?

[kp kirchdoerfer]

Am Sonntag, 27. März 2016, 16:03:06 schrieb Erich Titl:
> Hi KP
> 
> Am 26.03.2016 um 16:55 schrieb kp kirchdoerfer:
> > H Gents;
> 
> ...
> 
> > At last I changed hwdetect to neglect moddb, and to do not use
> > /var/lib/lrpkg/*.depmod any  longer - there is no need to copy modules to
> > /lib/modules any more.
> 
> IMHO we could also ditch hwdetect. There is hardly any difference in the
> code than in linuxrc. WE might need to add mount_modules to the hotplug
> script though.

hotplug seems not to be a replacement for hwdetect.

Yes the hwdetect code is in linuxrc, but as I said it could be convenient to 
run hwdetect and load modules *without reboot*.

Another issue iI found is we are  creation, deletion, link and unlink 
/lib/modules/$KVER add various places, which ends up in a link to itself

# ls -al /lib/modules/
lrwxrwxrwx1 root root12 Mar 27 18:18 4.4.6-x86_64 -> 
/lib/modules

Is there any reason why we just don't let /lib/modules/$KVER stay after 
linuxrc ran and avoid to link/unlink/create/delete?

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] some problems with the upgrade script

[kp kirchdoerfer]

Hi Erich;

Am Sonntag, 27. März 2016, 16:17:52 schrieb Erich Titl:
> Hi Mark
> 
> Am 27.03.2016 um 06:13 schrieb Mark Berndt:
> > No luck with the web interface,
> > running ugrgrade from the command line shows:
> > 
> > firewall# upgrade -vvv -c
> > upgrade: opening ports 80 and 443 for upgrade
> > upgrade: Installed version is 5.2.5-rc2
> > upgrade: retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable[1] upgrade:
> > retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 upgrade: retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 upgrade: retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 upgrade: retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 upgrade: retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 aborting: retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 upgrade: abort retrieve
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable, wget
> > returned 1 upgrade: cleaning up
> > upgrade: restoring firewall
> > 
> > wget fails:
> > 
> > firewall# wget
> > http://sourceforge.net/p/leaf/packages/ci/master/tree/stable
> > Connecting to sourceforge.net (216.34.181.60:80)
> > wget: can't connect to remote host (216.34.181.60): Connection refused
> 
> This is due to firewall rules, within uprade, these should be modified.
> The failure stems probably from a wget version not supporting https.
> 
> > wget with https succeeds:
> > 
> > 
> > firewall# wget
> > https://sourceforge.net/p/leaf/packages/ci/master/tree/stable[2]
> > Connecting to sourceforge.net (216.34.181.60:443)
> > stable   100% |
> > **
> > **|
> > 19293   0:00:00 ETA
> > firewall#
> > 
> > changing the LEAFURL_STUB=https://sourceforge.net/p/leaf/packages/ci
> 
> > in /usr/sbin/upgrade solves the problem:
> It looks like sourceforg dropped the redirect support.

Not shure; as he said the script from the CLI works, as it does on my router.


+ wget --no-check-certificate -O /tmp/tmp.hXp6Fe 
http://sourceforge.net/p/leaf/packages/ci/5.2.4/tree/version?format=raw
+ cat /tmp/tmp.hXp6Fe
+ VERSION=5.2.4

Probably an error only with webconf?


> > firewall# upgrade -vvv -c
> > upgrade: opening ports 80 and 443 for upgrade
> > upgrade: Installed version is 5.2.5-rc2
> > upgrade: retrieve
> > https://sourceforge.net/p/leaf/packages/ci/master/tree/stable
> > upgrade: stable version is 5.2.4
> > upgrade: check_remote
> > https://sourceforge.net/p/leaf/packages/ci/5.2.4/tree/version[3]
> > upgrade: retrieve
> > https://sourceforge.net/p/leaf/packages/ci/5.2.4/tree/version
> > upgrade: stable version is 5.2.4
> > 5.2.4
> > upgrade: retrieve
> > https://sourceforge.net/p/leaf/packages/ci/5.2.4/tree/i386/sha1sum.list[4]
> > upgrade: fetched sha1sum.list from LEAF repository
> > upgrade: cleaning up
> > upgrade: restoring firewall
> > upgrade: upgrade terminated successfully
> 
> OK so the upgrade version in 5.2.5-rc2 handles the situation correctly.
> The situation with sourceforge is really annoying. I have not seen any
> announcement for the current behaviour. When I started to write upgrade
> everything worke fine using httdp then about five months ago I saw that
> some, not all, requests were redirected. Now it appears that http is not
> supported anymore.

kp


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Can't reconfigure my LEAF-WRAP box

[kp kirchdoerfer]

Hi Bob;

Am Samstag, 26. März 2016, 19:52:26 schrieb Bob von Knobloch:
> Hi,
> I'm sure its me missing something, but I'll ask anyway. My LEAF box is
> currently configured for PPPOE on its eth0. I don't want this any more
> (having to go to VOIP necessitates using a Fritz Box as my ISP interface
> (to get ISDN S0) and wish to reconfigure LEAF's eth0 for 'normal' IP
> (I'll put it behind the Fritz Box to do proper firewalling).
> 
> In the /etc/network/intefaces file, I've commented out :
> 
> #auto ppp0
> #iface ppp0 inet ppp
> #   pre-up ip link set eth0 up
> #   provider dsl-provider eth0
> 
> and uncommented:

looks like you have missd a line:

auto eth0
iface ...
> iface eth0 inet static
> 
>  address 192.168.142.1
>  netmask 255.255.255.0
>  broadcast 192.168.142.255
>  gateway 192.168.142.1
> 
> and I've remed the ppp packages from leaf.cfg
> But I cannot get my IP address to appear on eth0.
> I can add it manually with "ip addr add x.x.x.x/24 dev eth0"
> but not from the startup script.
> 
> What else should I disable?
> 
> Many thanks,
> 
> Bob

hth kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] some problems with the upgrade script

[kp kirchdoerfer]

Hi John;

Am Samstag, 26. März 2016, 15:30:21 schrieb John Sager:
> I am using the same version - 5.2.4 Rev 1. I loaded wget.lrp and resolved
> its dependencies manually (I don't normally use it), and it's not built with
> https support. Downloading the latest wget from sourceforge and resolving
> its extra dependencies manually (libcrypto & libssl), it now fails on the
> certificate check. wget needs the option
> --no-check-certificate. I hacked on /usr/sbin/upgrade to add
> 'alias wget="wget --no-check-certificate"' and  'upgrade -c' then works
> correctly.

You are right.

After 5.24. has been released Sourceforge deciced to replace http with https 
only. Therefor upgrade in version  5.2.4  seems to fail.
With 5.25-rc1 upgrade has been updated with the wget option you have mentioned 
above for a given reason...

In addition to wget we have had wget-ssl, since wget without ssl support has 
been a lot smaller for size-constraint environments.
We've removed wget w/o ssl in 5.2.5-rc1 for security reasons, believing that 
size isn't as important as in the old days of floppy uasage and to have *one* 
wget package that really works with upgrade.

So in short  - testing upgrade only makes sense, if one tries to upgrade from 
5.2.5-rc1.

> I guess the real solution is a version of busybox where its wget supports
> https. The latest busybox (1.24.2) does appear to support https but it does
> it either via openssl (very heavy on libraries) or via a small auxiliary
> program ssl_helper which is statically linked against a small SSL library.

even the busybox wget provided supports ssl, but it'll require openssl.
I wasn't aware of the auxillary ssl_helper, definitely worth to look at it.

thx for the detailed and valuable  feedback
kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

[leaf-devel] What about removing moddb?

[kp kirchdoerfer]

H Gents;

with the merge of newinitrd-6x into master we do have a simplified logic to 
load modules:

either during boot from modules.sqfs and /etc/modules or from an init script 
as shorewall does for example.

As long as I've not overlooked something important, I believe there is no need 
for moddb.lrp any longer.
So it's time to clean up the code.

So it's useless to load from moddb, save to moddb.lrp etc etc.

I've modified the configs to build an image to remove traces of moddb, the same 
for leaf.cfg and root.linuxrc. Also removed the the option to save to moddb 
from lrcfg, changed lrcfg.backup.

At last I changed hwdetect to neglect moddb, and to do not use 
/var/lib/lrpkg/*.depmod any  longer - there is no need to copy modules to 
/lib/modules any more.

Correct me if I'm wrong.

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[kp kirchdoerfer]

Am Dienstag, 15. März 2016, 19:58:46 schrieb Jorn Eriksen:
> ...there are more of us that are using WRAP/ALIX/Geode :-)
 
> Best regards
> Jorn

jorn,

the geode image with ALIX support won't be dropped, in question was if 30kb 
justify an extra image for ALIX in addition to the existing geode image, which 
IMHO does not.

Eventually  we'll add an image for WRAP.

kp

> 
> 
> On 15. mars 2016 18:03, Erich Titl wrote:
> > Am 15.03.2016 um 17:48 schrieb kp kirchdoerfer:
> > ...
> > 
> >>> That is fine. But then I _believe_ the geodes all use the same PATA
> >>> companion chips, so we might really restrict them there too. Seeing the
> >>> difference in size, it hardly matters. I just don't like to include dead
> >>> code.
> >> 
> >> Ok, your decision, which may be valid until proofed wrong; But why choose
> >> a
> >> naming after a specific device (Alix) instead of keeping a ore generic
> >> naming?> 
> > Actually looking at the small benefits, let's just let the ALIX and WRAP
> > sleep by disabling them in the compile settings. I will be fine
> > compiling one for me if I need to, but then it is hardly worth the
> > trouble.
> > 
> > ET
> > 
> > --
> >  Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> > 
> > ___
> > leaf-devel mailing list
> > leaf-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/leaf-devel
> 
> 
> -- Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
> 
> ___
> leaf-devel mailing list
> leaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/leaf-devel


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[kp kirchdoerfer]

Am Dienstag, 15. März 2016, 17:32:55 schrieb Erich Titl:
> Hi KP
> 
> Am 15.03.2016 um 17:28 schrieb kp kirchdoerfer:
> > Hi Erich;
> 
> ...
> 
> > Just to be clear I don't argue against a seperate WRAP image, until it's
> > proofed to be outdated by download stats.
> > But I'm questioning seperate images for ALIX and Geode.
> 
> That is fine. But then I _believe_ the geodes all use the same PATA
> companion chips, so we might really restrict them there too. Seeing the
> difference in size, it hardly matters. I just don't like to include dead
> code.

Ok, your decision, which may be valid until proofed wrong; But why choose a 
naming after a specific device (Alix) instead of keeping a ore generic naming?

I'd prefer to go with geode, though with a shrinked kernel config as you 
proposed, and if needed we can enhance...

kp 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[kp kirchdoerfer]

Hi Erich;

Am Dienstag, 15. März 2016, 16:38:15 schrieb Erich Titl:
> Hi KP
> 
> Am 15.03.2016 um 16:17 schrieb kp kirchdoerfer:
> ...
> 
> > Hi Erich;
> > 
> > what's the difference between the alix specific kernel and the geode
> > kernel?
> Tha ALIX kernel has just one single PATA adapter. All the other storage
> drivers are absent.
> 
> > Will the difference justify a seperate image?
> 
> Maybe not. I _believe_ that the majority of our users don't really rely
> on too much diversity in their hardware. In the past we used to have
> general purpose hardware, mostly obsolete PC's which would run a real
> zoo of different network cards. Nowadays we either have SoCs or SBCs
> with a limitied choice of add-ons. I don't know enough about our users,
> I would guess a big majority are using some ALIX and APU boards, some
> use sophisticated multy processor machines. I myself am still restricted
> to a few old WRAPs lying around, they are sufficient for my purposes. I
> would love to see some statistics.
> 
> So If you feel those two images are not worth the trouble, that is fine
> with me. It is more a proof of concept than anything else.

Just to be clear I don't argue against a seperate WRAP image, until it's 
proofed to be outdated by download stats.
But I'm questioning seperate images for ALIX and Geode.

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ALIX specific kernel

[kp kirchdoerfer]

Am Montag, 14. März 2016, 14:15:30 schrieb Erich Titl:
> Hi Folks
> 
> I am trying to build a specific kernel for the ALIX board, but I am
> failing configuring the CS553x ATA driver into the kernel, e.g. the
> driver can be enabled as a module but menuconfig does not allow it to be
> compiled into the kernel.
> 
> Am I missing some prerequisite here?

Hi Erich;

what's the difference between the alix specific kernel and the geode kernel?

Will the difference justify a seperate image?

kp



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] master vs. new-initrd-6.x

[kp kirchdoerfer]

Am Mittwoch, 9. März 2016, 12:38:05 schrieb Erich Titl:
> Hi Folks
> 
> I have successfully installed new-initrd-6.x on my WRAP testbed. This
> system does not have neither moddb nor initmod anymore.
> 
> Here a few numbers to compare it to the current master branch. Master is
> alpha1, new-initrd-6.x is alpha2 for comparison
> 
> 
> 
> SALT# cat /etc/motd
> LEAF Bering-uClibc 6.0.0-alpha1 Rev 1 uClibc 1.0.12  at SALT
> Linux 4.4.3-i486 #1 Mon Mar 7 14:26:11 CET 2016
> 
> SALT# df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> tmpfs25600 0 25600   0% /tmp
> tmpfs 819288  8104   1% /var/log
> root 40960 22284 18676  54% /
> 
> Total boot time 03:50
> 
> 
> 
> SALT# cat /etc/motd
> LEAF Bering-uClibc 6.0.0-alpha2 Rev 1 uClibc 1.0.12  at SALT
> Linux 4.4.3-i486 #1 Tue Mar 8 22:57:03 CET 2016
> 
> SALT# df
> Filesystem   1K-blocks  Used Available Use% Mounted on
> tmpfs2560064 25536   0% /tmp
> tmpfs 819292  8100   1% /var/log
> root 40960 19132 21828  47% /
> 
> Total boot time 03:30
> 
> 
> 
> So we are saving roughly 20 seconds boot time and use about 15% less memory

Not bad.

Does it really take 3 min to boot on Wrap?

How did you measure , so I can compare with recent boxes like the APU/APU2?

kp 


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] IPv6 - Can EUI64 be used to configure the interface?

[kp kirchdoerfer]

Hi Sven;

Am Dienstag, 8. März 2016, 21:22:55 schrieb Sven Kirmess:
> In EdgeOS I can configure an IPv6 interface like this:
> 
>  ipv6 {
>  address {
>  eui64 2001:db8::/64
>  }
>  }
> 
> This defines the network part, the interface part of the IP is generated
> from the MAC address. The result looks like this:
> 
> 14: eth2.60@eth2:  mtu 1500 qdisc noqueue
> state UP
> link/ether 04:18:d6:c3:88:a7 brd ff:ff:ff:ff:ff:ff
> inet6 2001:db8::618:d6ff:fec3:88a7/64 scope global
>valid_lft forever preferred_lft forever
> inet6 fe80::618:d6ff:fec3:88a7/64 scope link
>valid_lft forever preferred_lft forever
> 
> Can this be done with Bering-uClibc?

Can't get it work with a quick test and found nothing helpful while saerching 
the net.

So I'm afraid there is no quick solution yet - put on agenda.

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] git master

[kp kirchdoerfer]

Sorry, another response

Am Montag, 7. März 2016, 20:26:58 schrieb Andrew:
> Maybe we should just mount storage till hostapd will start?


And what happens if hostpad isn't loaded at all?

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] git master

[kp kirchdoerfer]

Am Montag, 7. März 2016, 20:26:58 schrieb Andrew:
> Maybe we should just mount storage till hostapd will start?

Will  hostapd  really load the modules without changes to the init process?
The later is something I try to avoid,cause it will make us to maintain a 
different init for hostapd.

Another drawback is the time it needs to load modules.sqfs.
If we choose to that for several packages it will raise startup times 
significantly.

> Also, maybe it'll be good to add delayed umount (for ex., 3-5 seconds)?
> 
> 07.03.2016 19:06, Erich Titl пишет:
> > Hi Folks
> > 
> > OK after some twiddling with buildtool.cfg in master I succeeded to
> > build a 486 version.
> > 
> > There are a few quirks in shorewall and specifically we need to add the
> > following to /etc/modules in case we want to connect to WPA2 protected
> > AP's
> > 
> > # appears to be needed for WPA/WPA2
> > ccm
> > ctr

Currently those modules are in initmod AFAIK.

Adding those to /etc/modules raises the question:
- shall they be enbaled by default?
- and if so, why don't we add them to the kernel config?

> > Now my WRAP based Wireless repeater runs
> > 
> > SALT# cat /etc/motd
> > LEAF Bering-uClibc 6.0.0-alpha1 Rev 1 uClibc 1.0.12  at SALT
> > Linux 4.4.3-i486 #1 Mon Mar 7 14:26:11 CET 2016

Congrats :)
kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] git master broken?

[kp kirchdoerfer]

Am Montag, 7. März 2016, 11:13:47 schrieb Erich Titl:
> Hi Folks
> 
> Is master supposed to compile completely? To me it looks broken.
> 
> mega@leafbuilder:~/leaf/devel/bering-6$ git branch
> * master
>   new-initrd-6.x
> mega@leafbuilder:~/leaf/devel/bering-6$ git pull
> remote: Counting objects: 31, done.
> remote: Compressing objects: 100% (16/16), done.
> remote: Total 16 (delta 13), reused 0 (delta 0)
> Unpacking objects: 100% (16/16), done.
> 
> >From ssh://git.code.sf.net/p/leaf/bering-uclibc
> 
>56707d7..c20e020  master -> origin/master
>3c8352d..22fb99f  new-initrd-6.x -> origin/new-initrd-6.x
> Updating 56707d7..c20e020
> Fast-forward
>  repo/clamav/buildtool.cfg|   2 +-
>  repo/clamav/{clamav-0.99.tar.gz => clamav-0.99.1.tar.gz} | Bin 15968038
> -> 15990867 bytes
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename repo/clamav/{clamav-0.99.tar.gz => clamav-0.99.1.tar.gz} (66%)
> mega@leafbuilder:~/leaf/devel/bering-6$ ./buildtool.pl build hdsupp
> make the list of required source packages:
> linux,kernel,util-linux,e2fsprogs,syslinux,hdsupp [0.K.]
> 
> source/package: linux
> 
> downloading: buildtool.cfg from server localrepo type filesymlnk [0.K.]
> downloading: kernel-mkmakefile.patch from server localrepo type
> filesymlnk [0.K.]
> downloading: linux-4.4.tar.xz from server localrepo type filesymlnk [0.K.]
> downloading: bitreverse.patch from server localrepo type filesymlnk [0.K.]
> downloading: patch-4.4.2.xz from server localrepo type filesymlnk
> download failed: file
> /home/mega/leaf/devel/bering-6/repo/linux/patch-4.4.2.xz does not exist
> 
> you might find useful information in log/buildtoollog
> 

Needs to be patch-4.4.3.xz in repo/linux/buildtool.cfg
Fixed in git.

kp

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] git master

[kp kirchdoerfer]

Hi Erich;

Am Freitag, 4. März 2016, 22:50:09 schrieb Erich Titl:
> Hi Folks
> 
> I am trying to rebase new-initrd to master and failing miserably due to
> weird (for me) conflicts. In order to make progress I would like to
> suggest to clean up master in a way to be at least consistent with the
> actual kernel release, e.g. the person responsable for the introduction
> of 4.4 should also wipe 4.1 files. It is quite difficult to navigate
> through the minefield of forgotten files otherwise.

They are not forgotten, they are still used for armv6 toolchain.
We need to update the raspberry kernel (armv6) to 4.4, until then both kernel 
versions configs are needed to keep the kernel for raspberry pi at 4.1, which 
is known to work.

kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Deutsche Telekom VOIP

[kp kirchdoerfer]

Hi Bob;

Am Sonntag, 28. Februar 2016, 15:30:28 schrieb Bob von Knobloch:
> On 22/02/16 17:38, kp kirchdoerfer wrote:
> > I successfully used PCEngines Alix, APU and APU2 in this setup for LEAF.
> > 
> > hth kp
> 
> Hallo KP,
> I've tried, without success, to find out what ports/protocols (shorewall
> rules) I need to add to LEAF for Telekom's VOIP. Seemingly there is no
> one at Deutche Telekom who knows this (or even what the question means).
> As you have successfully implemented it, I wonder if you would share
> this with me?

Of course :)

See

https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients?samChecked=true

to get a start.


Pls move to PM, if you'll need further help.

kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Deutsche Telekom VOIP

[kp kirchdoerfer]

Hi Bob;

Am Montag, 22. Februar 2016, 15:44:52 schrieb Bob von Knobloch:
> Hi,
> anyone had any experience of DT's VOIP?
> It seems that we are being forced to change.
> We have one house with ISDN, a splitter, modem and a LEAF-WRAP router.
> The other house has just ISDN (no internet).
> All conversations with DT lead to "You will need a new router" i.e. no
> technical contents whatsoever.
> I would appreciate any experiences.
> This is slightly off-topic, so if you want, you could PM me on
> "leafvknoblochde".
> Many thanks for any advice.

I'm running such a setup (incl. IPTV) with DSL50 (50MBit/s).

You need a new DSL modem, a phone adapater and a LEAF router to replace the 
one DT will sell you. As usual, it isn't as cheap as the all-in-one box, 
you'll be more flexible - guessing the reason you use LEAF.

I'm running a Sphairon Speedlink 1110 as modem (only up to 50Mbit), there are 
reports that Zyxel VMG1312 (also available from DT for professional 
customers), but I didn't get it to work as quick as the Sphairon, so I 
stoppped investigations until 100MBit/s are offered).

The phone adapter for VoIP is a Cisco SPA 112, easy to setup if you choose 
quick setup - beyond that I understood that telco is completly different world.
It's connected to the LAN and supports two phones.

I successfully used PCEngines Alix, APU and APU2 in this setup for LEAF.

hth kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] tc filter 'action connmark' doesn't work

[kp kirchdoerfer]

Am Montag, 15. Februar 2016, 14:31:15 schrieb John Sager:
> I needed to apply some shaping on incoming traffic to preserve bandwidth for
> streaming services. bering-uclibc version 5.2.4 appeared to offer the
> necessary facilities - linux 4.1.16 supports it and apparently tc supports
> it too but in actual fact, although tc accepts the 'action connmark' action
> in a tc filter command, it fails to talk correctly to the kernel.
> 
> Rooting around in github, it looks like the patch applied to tc, supposedly
> to support connmark, in fact does nothing and it also screws up the command
> sent on the netlink socket so the kernel rejects it.
> 
> In trying to resolve this, I downloaded the leaf-bering dev environment from
> github - all several gigabytes! However the instructions in the README bear
> little relation to the actual config required, and I never did work out how
> to build the environment successfully.
> 
> I solved it by using buildroot-2015.11 to build tc updated to version 4.4.0,
> against uclibc-0.9.33.2 and this works properly on my installation.
> 
> Can I suggest you take the m_connmark.c file from tc in the iproute2 version
> 4.4.0 package. This will correctly parse the connmark action in tc filter
> commands & generate the necessary commands on the netlink socket.

With Johns help we solved that issue for next version by updating iproute to 
4.4.0. Additionally 'sch_htb htb_rate_est=1' needs to be added in /etc/modules 
so the parameter gets set when the module is loaded.

kp



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] tc filter 'action connmark' doesn't work

[kp kirchdoerfer]

Am Montag, 15. Februar 2016, 14:31:15 schrieb John Sager:
> I needed to apply some shaping on incoming traffic to preserve bandwidth for
> streaming services. bering-uclibc version 5.2.4 appeared to offer the
> necessary facilities - linux 4.1.16 supports it and apparently tc supports
> it too but in actual fact, although tc accepts the 'action connmark' action
> in a tc filter command, it fails to talk correctly to the kernel.
> 
> Rooting around in github, it looks like the patch applied to tc, supposedly
> to support connmark, in fact does nothing and it also screws up the command
> sent on the netlink socket so the kernel rejects it.
> 
> In trying to resolve this, I downloaded the leaf-bering dev environment from
> github - all several gigabytes! However the instructions in the README bear
> little relation to the actual config required, and I never did work out how
> to build the environment successfully.
> 
> I solved it by using buildroot-2015.11 to build tc updated to version 4.4.0,
> against uclibc-0.9.33.2 and this works properly on my installation.
> 
> Can I suggest you take the m_connmark.c file from tc in the iproute2 version
> 4.4.0 package. This will correctly parse the connmark action in tc filter
> commands & generate the necessary commands on the netlink socket.
> 
> regards,
> 
> John Sager

Did take of this issue and sent a private email with upated tc.lrp 
(iproute4.4.0) for review to John.

just to be shure that we don't double work.

kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[kp kirchdoerfer]

Am Montag, 8. Februar 2016, 13:20:07 schrieb Erich Titl:
> Hi KP
> 
> Just to make it more clear
> 
> Am 07.02.2016 um 14:09 schrieb kp kirchdoerfer:
> > Hi;
> 
> ..
> 
> > I don't think we can't make this a valuable  decision.
> > 
> > Just adding more code and more options to load modules will increase
> > maintenance work and will be confusing in the future.
> > 
> > If we do not copy modules during boot, we have to make shure that for
> > example shorewalls init code calls the helper script  mount_module and
> > load modules from modules.sqfs. This is unneeded if we load the modules
> > during boot. If we now want to support both ways to load modules, we will
> > have all the modules right in place, but during shorewall start, it will
> > still mount modules.sqfs and and load modules... and this is true for
> > other packages as well (openvpn, ppp/pppoe and so on).
> 
> I analyzed the case of openvpn
> 
> All based on a standard 5.2.4 installation
> 
> SALT# cat /etc/motd
> LEAF Bering-uClibc 5.2.4 Rev 1 uClibc 0.9.33.2 at SALT
> Linux 4.1.16-i486 #1 Thu Feb 4 19:09:38 CET 2016
> 
> SALT# apkg -l | grep openvpn
> openvpnz 2.3.9 Rev 2 uClibc 0.9.33.2
> SALT# lsmod | grep tun
> 
> So openvpn is installed, but tun is _not_ loaded
> 
> SALT# ls /lib/modules/4.1.16-i486/tun*
> /lib/modules/4.1.16-i486/tunnel4.ko.gz
> /lib/modules/4.1.16-i486/tunnel6.ko.gz
> 
> Mhhh... the tun module is not even _copied_ to /lib/modules
> 
> SALT# ls -l /var/lib/lrpkg/openvpnz.depmod
> ls: /var/lib/lrpkg/openvpnz.depmod: No such file or directory
> 
> No surprise, there is no depmod file in openvpnz
> 
> 
> Package = libcrpto
> Package = libssl
> 
> 
> So current analysis shows that despite the pledge of DependsOn, it has
> not fully been implemented, even one of the most cited packages is not
> even supported.

Yes, but that we didn't take care to fully implement the mechanism is not an 
argument against, but shows just our limited time to keep up with changes.
And I for myself didn't take care, cause I knew that a decission with a 
possible rework about  loading modules was mentioned as task for 6.x

You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides the 
necesssry modules and therefor requires no user intervention to load the 
necessary modules.

> Please, what are we discussing about here?

We discuss a major change.

See ticket 73 from 2012

https://sourceforge.net/p/leaf/tickets/73/

where it all started. In the meantime, we could have closed that ticket, 
because Andrew provided the code to deal with modules dependencies..

Your proposal is to choose a different solution, which has his own merits.

But I do not see, how we can go both ways.
Therefor I'd like to get a consensus, about how to proceed.

kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[kp kirchdoerfer]

Am Montag, 8. Februar 2016, 18:32:07 schrieb Erich Titl:
> Hi KP
> 
> Am 08.02.2016 um 18:26 schrieb kp kirchdoerfer:
> ...
> 
> > You may analyze ppp/pppoe instead, where /var/lib/lrpkg/*.depmod provides
> > the necesssry modules and therefor requires no user intervention to load
> > the necessary modules.
> 
> OK, so who is loading the modules, please. LINUXRC does not.

Doublechecked,  you are right :) 
-  it seems not work as I expected, point taken.

Thx for your patience... :)

Now, what's your idea to deal with openvpn/ppp/pppoe?

/etc/modules could be a starting point?

Wherever possible using/changing init scripts?

kp


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] status of modules loading - old, proposed new and questions

[kp kirchdoerfer]

Hi;

Am Mittwoch, 3. Februar 2016, 20:03:19 schrieb Andrew:
> Hi.
> 
> 03.02.2016 17:44, kp kirchdoerfer пишет:
> > Hi all;
> > 
> > I'll try to summarize the current and proposed status of loading modules
> > as
> > this raises questions.
> > 
> > Pls correct me whereelse needed if I missed something or got it wrong.
> > 
> > This summary is based on 5.2.x, master and new-initrd-6x branch
> > 
> > 
> > A) The current status
> > 
> > At the time we do have three mechanisms to load modules, which itself is
> > is a state of transition.
> > 
> > 1) First one is to load all hardware related modules during boot in
> > linuxrc
> > 
> > 2) Next we load(copy??) all modules from /etc/modules - esp. added for
> > modules which are not hardware-related like tun.ko (openvpn), ppp*.ko
> > etc.
> > 
> > 3) A third mechanism has been introduced last year to add modules to
> > load(copy??) for a given Package in buildtool.cfg in the 
> > section of buildtool.cfg. This concurs with loading from /etc/modules and
> > is intented to replace the need to add a module for a Package to
> > /etc/modules and have loaded(copied??) instead "automagically" - like
> > other Packages a Package depends on.
> > Although 2) and 3) are similar loading(copying??) from /etc/modules is a
> > welcome fallback, in case we do miss a module when building a package in
> > buildtool.cfg.
> > 
> > As you can see above, I'm not shure if modules in step 2 and 3 are really
> > loaded or just copied to /lib/modules.
> > Anyway this works, if we later start packages that need modules, they
> > DependOn.
> 
> 2) - modules are loaded to kernel
> 3) - modules are just copied. they are loaded by software if needed (for
> ex., iptables modules)
> 
> > A major drawback is that this way we do have a lot modules just copied
> > into
> > the RAM (although compressed).
> > 
> > Did I get this correct so far?
> > 
> > B) Proposed status
> > 
> > Erich invested work to reduce the number of copied/loaded  modules in the
> > new- initrd branch to  minimize RAM usage.
> > He started to  build the essential modules from initmod.lrp into the
> > kernel - that way we can get rid off initmod.lrp at all. While it will
> > raise the kernel size, it is hoped that we can go wihout having modules
> > as compressed modules in /lib/modules as well as uncompressed loaded into
> > the RAM.
> > This effort will buy out even more if we want to support more specialized
> > architectures/images than today.
> > 
> > In a second step he replaced the current way to load/copy every module
> > into
> > /lib/modules with a mimic to work with modules.sqfs and to now
> > really load required modules into instead insted of copy the compressed
> > module and load afterwards.
> > 
> > new-initrd is able to load
> > a) hardware related modules during boot
> > b) load modules from /etc/modules
> > 
> > but does not work with modules defined in 
> > (/var/lib/lrpkg/*.depmod)
> > 
> > Instead it usees for shorewall the /etc/shorewall/modules* to oad all
> > modules required modules with a modification to shorewal[6]l's init files
> > (once again mount modules.sqfs, load modules and umount ).
> > 
> > While this works for shorewall[6] with a well-defined configuraton, which
> > modules to load, and therefor does not load any netfilter/xtables etc
> > module unndeeded, and keep the necessary size in RAM as small as
> > possible, it fails to load needed  modules of packages that assumes that
> > modules are available (like openvpn, arptables, ppp*).
> > 
> > Erich made the proposal to change the init scripts of such packages to
> > mount modules.sqfs and load whatever required.
> 
> Good solution.
> 
> But IMHO we should leave possibility to use old behavior on systems.
> 
> > Another option could be to modprobe all modules in question from
> > /var/lib/lrpkg/*depmod, but it will load more modules into than needed.
> > 
> > I've discussed this with Erich forth and back, each one with better or
> > worse arguments, but without a proper solution.
> > 
> > So we decided to move the discussion to leaf-devel (again) to find a
> > proper
> > solution and to have as much feedback as possible.
> > 
> > I may have been to short in describing what's possible with new-initrd,
> > and
> > also to describe the drawbacks - but I want to start a discussion how to
> > deal with
> > 
> > a) the current

[leaf-devel] status of modules loading - old, proposed new and questions

[kp kirchdoerfer]

Hi all;

I'll try to summarize the current and proposed status of loading modules as 
this raises questions.

Pls correct me whereelse needed if I missed something or got it wrong.

This summary is based on 5.2.x, master and new-initrd-6x branch 


A) The current status

At the time we do have three mechanisms to load modules, which itself is is a 
state of transition.

1) First one is to load all hardware related modules during boot in linuxrc

2) Next we load(copy??) all modules from /etc/modules - esp. added for modules 
which are not hardware-related like tun.ko (openvpn), ppp*.ko etc.

3) A third mechanism has been introduced last year to add modules to 
load(copy??) for a given Package in buildtool.cfg in the  section 
of buildtool.cfg. This concurs with loading from /etc/modules and is intented 
to replace the need to add a module for a Package to /etc/modules and have 
loaded(copied??) instead "automagically" - like other Packages a Package 
depends on. 
Although 2) and 3) are similar loading(copying??) from /etc/modules is a 
welcome fallback, in case we do miss a module when building a package in 
buildtool.cfg.

As you can see above, I'm not shure if modules in step 2 and 3 are really 
loaded or just copied to /lib/modules.
Anyway this works, if we later start packages that need modules, they 
DependOn.

A major drawback is that this way we do have a lot modules just copied into 
the RAM (although compressed).

Did I get this correct so far?

B) Proposed status

Erich invested work to reduce the number of copied/loaded  modules in the new-
initrd branch to  minimize RAM usage. 
He started to  build the essential modules from initmod.lrp into the kernel - 
that way we can get rid off initmod.lrp at all. While it will raise the kernel 
size, it is hoped that we can go wihout having modules as compressed modules 
in /lib/modules as well as uncompressed loaded into the RAM. 
This effort will buy out even more if we want to support more specialized 
architectures/images than today.

In a second step he replaced the current way to load/copy every module into 
/lib/modules with a mimic to work with modules.sqfs and to now 
really load required modules into instead insted of copy the compressed module 
and load afterwards.

new-initrd is able to load 
a) hardware related modules during boot
b) load modules from /etc/modules

but does not work with modules defined in  (/var/lib/lrpkg/*.depmod)

Instead it usees for shorewall the /etc/shorewall/modules* to oad all modules 
required modules with a modification to shorewal[6]l's init files (once again 
mount modules.sqfs, load modules and umount ).

While this works for shorewall[6] with a well-defined configuraton, which 
modules to load, and therefor does not load any netfilter/xtables etc module 
unndeeded, and keep the necessary size in RAM as small as possible, it fails 
to load needed  modules of packages that assumes that modules are available 
(like openvpn, arptables, ppp*).

Erich made the proposal to change the init scripts of such packages to mount 
modules.sqfs and load whatever required.

Another option could be to modprobe all modules in question from 
/var/lib/lrpkg/*depmod, but it will load more modules into than needed.

I've discussed this with Erich forth and back, each one with better or worse 
arguments, but without a proper solution.

So we decided to move the discussion to leaf-devel (again) to find a proper 
solution and to have as much feedback as possible.

I may have been to short in describing what's possible with new-initrd, and 
also to describe the drawbacks - but I want to start a discussion how to deal 
with 

a) the current situation to deal with modules

b) how to keep the advantages of new-initrd, while getting the best of the 
work we've done in the past

Any input/ideas is welcome.

thy kp  


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-user] Problems booting Bering-uClibc on APU2B4

[kp kirchdoerfer]

Am Donnerstag, 28. Januar 2016, 20:43:30 schrieb Sven Kirmess:
> I've created a fresh USB key from
> Bering-uClibc_5.2.4-rc1_x86_64_syslinux_serial115200.tar.gz and it boots
> without problem on my APU2B4.
> 
> Thanks!

Thanks for testing and feedback!

kp 


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Problems booting Bering-uClibc on APU2B4

[kp kirchdoerfer]

Hi Sven;

Am Sonntag, 17. Januar 2016, 20:50:04 schrieb Sven Kirmess:
> That worked. Thanks for your help. :-)

> I've added the following 4 modules to initmod.lrp:
> ehci-platform.ko.gz
> ohci-pci.ko.gz
> xhci-hcd.ko.gz
> xhci-pci.ko.gz

Thx for your help. 
The modules will be added into initmod.lrp for further releases.

kp

> And replaced the configdb.lrp with the one from
> Bering-uClibc_5.2.3_i686_syslinux_serial115200.tar.gz
> 
> 
> 
> firewall# lsmod
> Tainted: G
> nf_log_ipv4 4149 1 - Live 0xa0665000
> nf_log_common 2954 1 nf_log_ipv4, Live 0xa0661000
> xt_LOG 1359 1 - Live 0xa065d000
> ipt_MASQUERADE 1085 1 - Live 0xa0659000
> nf_nat_masquerade_ipv4 1897 1 ipt_MASQUERADE, Live 0xa0655000
> xt_recent 8134 1 - Live 0xa064f000
> xt_comment 939 26 - Live 0xa064b000
> iptable_nat 1831 1 - Live 0xa0647000
> nf_nat_ipv4 4923 1 iptable_nat, Live 0xa0642000
> nf_nat 12330 2 nf_nat_masquerade_ipv4,nf_nat_ipv4, Live 0xa0639000
> ipt_REJECT 1425 4 - Live 0xa0635000
> nf_reject_ipv4 2451 1 ipt_REJECT, Live 0xa0631000
> xt_addrtype 2765 4 - Live 0xa062d000
> xt_NFLOG 1134 6 - Live 0xa0629000
> xt_mark 1189 1 - Live 0xa0625000
> iptable_mangle 1528 1 - Live 0xa0621000
> nf_conntrack_irc 3755 2 - Live 0xa061d000
> nf_conntrack_sip 21125 2 - Live 0xa0613000
> nf_conntrack_h323 41970 4 - Live 0xa0601000
> nf_conntrack_tftp 3953 2 - Live 0xa05fd000
> nf_conntrack_sane 4220 2 - Live 0xa05f8000
> ts_kmp 1815 5 - Live 0xa05f4000
> nf_conntrack_amanda 2293 2 - Live 0xa05f
> nf_conntrack_ftp 6847 2 - Live 0xa05eb000
> nf_conntrack_netbios_ns 1053 2 - Live 0xa05e7000
> nf_conntrack_snmp 1187 2 - Live 0xa05e3000
> nf_conntrack_broadcast 1197 2 nf_conntrack_netbios_ns,nf_conntrack_snmp,
> Live 0xa05df000
> nf_conntrack_pptp 4274 2 - Live 0xa05da000
> nf_conntrack_proto_gre 4224 1 nf_conntrack_pptp, Live 0xa05d5000
> xt_tcpudp 2415 49 - Live 0xa05d1000
> xt_CT 4042 22 - Live 0xa05cd000
> iptable_raw 1356 1 - Live 0xa05c9000
> xt_multiport 1798 4 - Live 0xa05c5000
> nf_conntrack_ipv4 12920 35 - Live 0xa05bd000
> nf_defrag_ipv4 1507 1 nf_conntrack_ipv4, Live 0xa05b9000
> xt_conntrack 3081 12 - Live 0xa05b5000
> nf_conntrack 74514 18
> nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat,nf_conntrack_irc,nf_conntrack_sip,
> nf_conntrack_h323,nf_conntrack_tftp,nf_conntrack_sane,nf_conntrack_amanda,nf
> _conntrack_ftp,nf_conntrack_netbios_ns,nf_conntrack_snmp,nf_conntrack_broadc
> ast,nf_conntrack_pptp,nf_conntrack_proto_gre,xt_CT,nf_conntrack_ipv4,xt_conn
> track, Live 0xa0595000
> iptable_filter 1464 1 - Live 0xa0591000
> ip_tables 16195 4 iptable_nat,iptable_mangle,iptable_raw,iptable_filter,
> Live 0xa0589000
> x_tables 15952 16
> xt_LOG,ipt_MASQUERADE,xt_recent,xt_comment,ipt_REJECT,xt_addrtype,xt_NFLOG,x
> t_mark,iptable_mangle,xt_tcpudp,xt_CT,iptable_raw,xt_multiport,xt_conntrack,
> iptable_filter,ip_tables, Live 0xa057f000
> nfnetlink_log 8113 3 xt_NFLOG, Live 0xa0579000
> nfnetlink 5616 3 nfnetlink_log, Live 0xa0573000
> ipv6 344164 24 [permanent], Live 0xa0506000
> sch_sfq 10357 0 - Live 0xa04e4000
> sch_htb 14936 0 - Live 0xa04dc000
> cls_u32 8229 0 - Live 0xa04d6000
> sch_ingress 1997 0 - Live 0xa04d2000
> sch_prio 4588 0 - Live 0xa04cd000
> sch_tbf 5907 0 - Live 0xa04c8000
> cls_flow 7131 0 - Live 0xa04c3000
> cls_fw 4315 0 - Live 0xa04be000
> act_police 3741 0 - Live 0xa04ba000
> ifb 3773 0 - Live 0xa04b6000
> 8021q 20186 0 - Live 0xa04ac000
> mrp 7550 1 8021q, Live 0xa04a6000
> garp 5757 1 8021q, Live 0xa04a
> stp 1597 1 garp, Live 0xa049c000
> llc 3633 2 garp,stp, Live 0xa0497000
> softdog 2365 1 - Live 0xa0493000
> acpi_cpufreq 6946 0 - Live 0xa03c3000
> processor 22864 1 acpi_cpufreq, Live 0xa039d000
> thermal_sys 25341 1 processor, Live 0xa0383000
> igb 168593 0 - Live 0xa02ed000 (O)
> fam15h_power 2606 0 - Live 0xa02e9000
> k10temp 2900 0 - Live 0xa02e5000
> i2c_piix4 8736 0 - Live 0xa02d5000
> hwmon 3122 4 thermal_sys,igb,fam15h_power,k10temp, Live 0xa02c6000
> i2c_core 36487 1 i2c_piix4, Live 0xa02b4000
> dca 5056 1 igb, Live 0xa02a2000
> ptp 10524 1 igb, Live 0xa0287000
> pps_core 6721 1 ptp, Live 0xa027b000
> sd_mod 31037 0 - Live 0xa0265000
> usb_storage 48532 0 - Live 0xa024f000
> pcspkr 1939 0 - Live 0xa024b000
> ahci 24883 0 - Live 0xa023d000
> libahci 21719 1 ahci, Live 0xa0231000
> libata 189900 2 ahci,libahci, Live 0xa01ea000
> xhci_pci 3747 0 - Live 0xa01e6000
> xhci_hcd 106902 1 

Re: [leaf-user] Problems booting Bering-uClibc on APU2B4

[kp kirchdoerfer]

Am Sonntag, 17. Januar 2016, 18:44:08 schrieb Sven Kirmess:
> Where would I find the modules.tgz file with the additional modules? The
> documentation <
> http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_User_Guide_-_Advance
> d_Topics_-_Modifying_initrd.lrp> mentions
> 
> > modules.tgz (which can be found alongside initmod.lrp on any Bering-uClibc
> 
> 5.x  disk Image)
> 
> but I can't find a modules.tgz file, neither in the
> Bering-uClibc_5.2.3_x86_64_isolinux_vga.iso nor in the
> Bering-uClibc_5.2.3_x86_64_syslinux_vga.tar.gz distribution.

The modules tarball has been replaced with squashfs'd modules.

Look for modules(*).sqfs instead.

Mount with  

mount -t squashfs [path]modules-*.sqfs [tempdir]

The xhci drivers are in
[tmpdir]kernel/drivers/usb/host/


kp

> On Sun, Jan 17, 2016 at 6:28 PM, Andrew  wrote:
> > It seems like there's no USB 3.0 driver into initmod. Your board uses
> > usb 3.0 on front and also has usb 2.0 inside.
> > 
> > You may try to add XHCI driver to initmod (it's .cpio.gz package), or
> > try to connect flash to internal USB.
> > 
> > 17.01.2016 18:02, Sven Kirmess пишет:
> > > I've created a USB stick from
> > > Bering-uClibc_5.2.3_x86_64_syslinux_vga.tar.gz which boots fine on a
> > 
> > normal
> > 
> > > PC (after adding about 200 .c32 files :-). (Looks like I did create the
> > > sticks correctly.)
> > > 
> > > I then changed the syslinux.cfg to use the serial console on this stick
> > 
> > and
> > 
> > > booted it with my APU2B4. This time it does boot and I get the following
> > > error message:
> > > 
> > > modprobe: can't load module pata_legacy (pata_legacy.ko.gz): No such
> > 
> > device
> > 
> > > LINUXRC: PKGPATH is empty or unset. Can not install packages.
> > > LINUXRC: LRP= is empty or unset.  Can not install packages.
> > > Running stage2 depmod after loading: moddb
> > > LINUXRC: Running stage2 module loading
> > > LINUXRC: Loaded Packages
> > > can't run '/etc/init.d/rcS': No such file or directory
> > > 
> > > That looks very similar to e.g. this problem: <
> > 
> > http://sourceforge.net/p/leaf/mailman/leaf-user/thread/c69-54172880-51-36d
> > 68b00%405585321/#msg32833837> 
> > > There is no /dev/sda1 device after booting. The following modules are
> > > loaded:
> > > 
> > > / # lsmod
> > > 
> > >  Not tainted
> > > 
> > > ahci 24883 0 - Live 0xa01da000
> > > libahci 21719 1 ahci, Live 0xa01ce000
> > > pcspkr 1939 0 - Live 0xa01ca000
> > > ehci_pci 3839 0 - Live 0xa01c6000
> > > ehci_hcd 43239 1 ehci_pci, Live 0xa01b6000
> > > libata 189900 2 ahci,libahci, Live 0xa016f000
> > > scsi_mod 183845 1 libata, Live 0xa012e000
> > > usbcore 165765 2 ehci_pci,ehci_hcd, Live 0xa00f2000
> > > usb_common 1624 1 usbcore, Live 0xa00ee000
> > > ext4 502100 0 - Live 0xa004d000
> > > mbcache 7051 1 ext4, Live 0xa0047000
> > > jbd2 78193 1 ext4, Live 0xa0027000
> > > crc16 1335 1 ext4, Live 0xa0023000
> > > vfat 9967 0 - Live 0xa001d000
> > > fat 51912 1 vfat, Live 0xa000a000
> > > isofs 23779 0 - Live 0xa000
> > > / #


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-user] Problems booting Bering-uClibc on APU2B4

[kp kirchdoerfer]

Hi Sven;

I'll expect  an APU2 next week and will give it a try ASAP.

In the meantime I'll  take care to build a X86_64 serial image for upcoming 
versions.

The failure you see, looks like a missing module during boot...

hopefully I'll have more info once I'll have an APU2 myself

kp


Am Sonntag, 17. Januar 2016, 17:02:01 schrieb Sven Kirmess:
> I've created a USB stick from
> Bering-uClibc_5.2.3_x86_64_syslinux_vga.tar.gz which boots fine on a normal
> PC (after adding about 200 .c32 files :-). (Looks like I did create the
> sticks correctly.)
> 
> I then changed the syslinux.cfg to use the serial console on this stick and
> booted it with my APU2B4. This time it does boot and I get the following
> error message:
> 
> modprobe: can't load module pata_legacy (pata_legacy.ko.gz): No such device
> LINUXRC: PKGPATH is empty or unset. Can not install packages.
> LINUXRC: LRP= is empty or unset.  Can not install packages.
> Running stage2 depmod after loading: moddb
> LINUXRC: Running stage2 module loading
> LINUXRC: Loaded Packages
> can't run '/etc/init.d/rcS': No such file or directory
> 
> That looks very similar to e.g. this problem: <
> http://sourceforge.net/p/leaf/mailman/leaf-user/thread/c69-54172880-51-36d68
> b00%405585321/#msg32833837
> 
> 
> There is no /dev/sda1 device after booting. The following modules are
> loaded:
> 
> / # lsmod
> Not tainted
> ahci 24883 0 - Live 0xa01da000
> libahci 21719 1 ahci, Live 0xa01ce000
> pcspkr 1939 0 - Live 0xa01ca000
> ehci_pci 3839 0 - Live 0xa01c6000
> ehci_hcd 43239 1 ehci_pci, Live 0xa01b6000
> libata 189900 2 ahci,libahci, Live 0xa016f000
> scsi_mod 183845 1 libata, Live 0xa012e000
> usbcore 165765 2 ehci_pci,ehci_hcd, Live 0xa00f2000
> usb_common 1624 1 usbcore, Live 0xa00ee000
> ext4 502100 0 - Live 0xa004d000
> mbcache 7051 1 ext4, Live 0xa0047000
> jbd2 78193 1 ext4, Live 0xa0027000
> crc16 1335 1 ext4, Live 0xa0023000
> vfat 9967 0 - Live 0xa001d000
> fat 51912 1 vfat, Live 0xa000a000
> isofs 23779 0 - Live 0xa000
> / #


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

leaf-user mailing list: leaf-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/

Re: [leaf-devel] Leaf master branch

[kp kirchdoerfer]

Am Donnerstag, 14. Januar 2016, 09:49:05 schrieb Erich Titl:
> Hi Folks
> 
> In my effort to port new-initrd to master I looked at the linux directory
> 
> Why do we have config files for 4.1 and 4.4 plus the corresponding tarballs?
> Shouldn't we make the config files release agnostic?


It is useful/necessary to keep those files at least for a transition period 
until we support new kernel for every toolchain. Currently armv6 for the 
raspberry is a problem, so a 4.1 kernel will be kept.

kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] http server

[kp kirchdoerfer]

Hi Erich;

Am Sonntag, 10. Januar 2016, 11:18:09 schrieb Erich Titl:
> Hi KP
> 
> Am 10.01.2016 um 08:40 schrieb kp kirchdoerfer:
> > Am Samstag, 9. Januar 2016, 00:26:57 schrieb Erich Titl:
> >> Hi KP
> >> 
> >> ...
> >> * update lighttpd to 1.4.39
> >> 
> >> Is there a benefit in using lighthttpd over mini_httpd? If so, should we
> >> drop mini_httpd?
> > 
> > While it's still small it's more like a full-fledged webserver and more
> > configuration options.
> 
> What is the footprint, They pretend it is 'small'

About 100kb more than mini_httpd, depends also on included modules.

> > In the long-term we may replace mini-httpd, but this requires some qorjk
> > to
> > migrate webconf.
> 
> Details? If it supports some kind of CGI is should just work.

I believe we need to adjust install pathes and look into the configuration as 
well. Though I haven't looked into it seriously.

kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] upcoming LEAF Bering-uClibc version

[kp kirchdoerfer]

Hi all

just a short note that 6.0 is making progress.

Whilst I'm running the gcc 5.3.0, uClibc-ng 1.0.10 toolchain for about a week, 
this mail is send via a LEAF router with kernel version 4.4-rc8.

kp



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] http server

[kp kirchdoerfer]

Am Samstag, 9. Januar 2016, 00:26:57 schrieb Erich Titl:
> Hi KP
> 
> ...
> * update lighttpd to 1.4.39
> 
> Is there a benefit in using lighthttpd over mini_httpd? If so, should we
> drop mini_httpd?

While it's still small it's more like a full-fledged webserver and more 
configuration options.
In the long-term we may replace mini-httpd, but this requires some qorjk to 
migrate webconf.

kp

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] uclibc-ng build error

[kp kirchdoerfer]

Am Freitag, 1. Januar 2016, 23:18:01 schrieb Andrew:
> Hi.
> 
> It seems like there's troubles with parallel compilation. I thought that
> it was due to building all and utils in one make call. I've committed
> changes but forgot to push it. Try now. If it'll fail again (it may run
> OK but may fail), we'll need to remove $(MAKEOPTS) from make call.

Hi Andrew;

I've done a few rebuilds and it seems the pb is solved.

In fact, I'm running an updated version right now and have not any problem 
yet.

But I also saw the binaries/Packages compiled  with gcc 5.3 are a little 
bigger than before. Can we try to improve MAKEOPTS to shrink size? 

Anyway - a welcome improvement!

kp


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] findfs in linuxrc

[kp kirchdoerfer]

Happy New Year to all!


Am Donnerstag, 31. Dezember 2015, 12:23:39 schrieb Erich Titl:
> Hi KP
> 
> Am 30.12.2015 um 20:11 schrieb kp kirchdoerfer:
> > Erich;
> 
> ..
> 
> > Looking at the busybox documentation, it seems it does support handling of
> > LABEL and UUID.
> > 
> > We should give it a try.
> 
> I have built a initrd with findfs enabled in busybox and struggled for a
> few hours with linuxrc (which is not that seamlessly written in this
> aspect) to boot from a UUID specified partition.
> 
>  title LEAF Styx primary boot UUID
>   root (hd0,1)
>   kernel /linux1 \
>   console=ttyS0,38400 \
>   init=/linuxrc rw \
>   usb_wait=3 \
>   VERBOSE=1 \
>   intel_idle.max_cstate=0 \
>   processor.max_cstate=1 \
>   root=/dev/ram0 \
>   boot=UUID=C765-30E4:vfat \
>   reboot=bios \
>   zswap.enabled=1 \
>   zswap_size=128M \
>   initrd=initrd2.lrp \
>   libata.force=1.00:pio4 \
>   PKGPATH=UUID=C765-30E4:vfat \
>   LEAFCFG=UUID=C765-30E4:vfat
>   savedefault
> 
> initrd /initrd2.lrp
> 
> title LEAF Styx primary boot with label
>   root (hd0,1)
>   kernel /linux1 \
>   console=ttyS0,38400 \
>   init=/linuxrc rw \
>   usb_wait=3 \
>   VERBOSE=1 \
>   intel_idle.max_cstate=0 \
>   processor.max_cstate=1 \
>   root=/dev/ram0 \
>   boot=LABEL=PRIMARY:vfat \
>   reboot=bios \
>   zswap.enabled=1 \
>   zswap_size=128M \
>   initrd=initrd2.lrp \
>   libata.force=1.00:pio4 \
>   PKGPATH=LABEL=PRIMARY:vfat \
>   LEAFCFG=LABEL=PRIMARY:vfat
>   savedefault
> 
> initrd /initrd2.lrp
> 
> 
> 
> SALT# blkid
> /dev/zram0: UUID="341406ff-6ca6-4b89-bfc5-5c9020bb0cc6" TYPE="swap"
> /dev/sda1: SEC_TYPE="msdos" UUID="C72F-3FC7" TYPE="vfat"
> PARTUUID="d0302fd7-01"
> /dev/sda2: SEC_TYPE="msdos" LABEL="PRIMARY" UUID="C765-30E4" TYPE="vfat"
> PARTUUID="d0302fd7-02"
> /dev/sda3: SEC_TYPE="msdos" LABEL="SECONDARY" UUID="C784-A612"
> TYPE="vfat" PARTUUID="d0302fd7-03"
> /dev/sda5: SEC_TYPE="msdos" UUID="C7A6-1054" TYPE="vfat"
> PARTUUID="d0302fd7-05"
> 
> 
> 
> I have successfully booted using either UUID and LABEL or the classical
> /dev notation, which makes this initrd suitable for all our supported
> type of partition identification. This initrd has been weeded out quite
> a bit. It needs a kernel with compiled in storage drivers from previous
> tests and it does not copy modules which reduces the memory footprint of
> our system quite a bit.

Erich, sounds great!
 
> We can safely remove findfs from hdsupp now.
> 
> I will push the corresponding branch to the repository before midnight :-)

I looked into the source,  a few notes/questions.

If you remove moddb we need something else to save and load firmware - 
currently we use moddb.lrp.

Is configuring modules in /etc/modules still supported?
We still need this for modules that are not detectable by hwdetect (non-
hardware related modules)

While it looks ok, how shorewall uses modules.sqfs, it will needs to be added 
as patch - if at all. 
Another approach could be to add those modules to /etc/modules, as we did in 
the beginning with all modules more than a dozen years ago :)
This will load netfilter modules, even if one uses something else than 
shorewall to configure the firewall rules.

I'd like to see the kernel config changes in the 4.4 configs - I'm pretty shure 
we'll update the kernel for next major version, and I'm also shure that 
changing linuxrc/modules loading that much will be rather part of a new  major 
version, than an update in the maintenance version 5.2 with kernel 4.1.

Currently building and will do some testing...

kp 

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[leaf-devel] uclibc-ng build error

[kp kirchdoerfer]

Hi Andrew;

just tried to build toolchain with uclibc-ng, but ifailed the error

 AR cr libc/libc_so.a
  STRIP -x -R .note -R .comment libc/libc_so.a
  AR cr libc/libc_so.a
i486-unknown-linux-uclibc-ar: libc/libc_so.a: Error reading 
libc_multiple_threads.oS: File truncated


...?
kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] findfs in linuxrc

[kp kirchdoerfer]

Erich;

Am Dienstag, 29. Dezember 2015, 12:52:20 schrieb Erich Titl:
> Hi KP
> 
> Am 28.12.2015 um 21:12 schrieb kp kirchdoerfer:
> > Hi Erich;
> 
> ...>>
> 
> >> It requires a different busybox. The current one does not provide findfs.
> > 
> > It requires findfs in initrd, but not necessarily as busybox applet.
> 
> It does not make sense to me to require it to be pulled from hdsupp
> unless the busybox findfs applet is not handling LABEL and UUID.

Looking at the busybox documentation, it seems it does support handling of 
LABEL and UUID.
   
We should give it a try.

kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] findfs in linuxrc

[kp kirchdoerfer]

Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl:
> Hi Andrew
> 
> Am 23.12.2015 um 12:22 schrieb Andrew:
> > It seems like it was dropped by unknown reason, so it should be enabled.
> 
> Well, apparently nobody noticed, so I doubt it is used at all.
> 
> cheers
> 
> ET


Hi Erich

looking at 

http://bering-uclibc.zetam.org/wiki/Bering-uClibc_5.x_-_User_Guide_-_Basic_Configuration_-_LEAF_Packages#Configuring_syslinux.cfg_or_isolinux.cfg

I read

For advanced users there is an alternative syntax for LEAFCFG which can 
reference disks by a persistent block device name - either the file system 
LABEL or the UUID. This borrows the syntax from other Linux distributions. For 
example:

LEAFCFG=LABEL=LEAFBUC:vfat

would use the disk with the DOS filesystem label "LEAFBUC", or

LEAFCFG=UUID=3290c629-123e-4c44-b79b-1c71e312a079

(since the filesystem type is optional).

Note that this facility is not supported by default since the extra utilities 
needed to identify devices in this way are not included in the standard 
initrd.lrp files, and most users prefer a smaller initrd.lrp. However, it is 
possible to enable this behaviour by following the instructions for Modifying 
initrd.lrp and adding the following files from hdsupp.lrp:

/sbin/findfs
/lib/libblkid.so.1.1.0 and its symbolic links
/lib/libuuid.so.1.3.0 and its symbolic links


It is marked as an feature "for advanced users" and never has been enabled in 
busybox, but as part of hdsupp.lrp, which means not having findfs in busybox, 
does not allow a judgement if the code snippet in linuxrc is used or not.

I suggest to keep it, and probably to enhance our basic system to enable this 
feature by default.

kp


--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] findfs in linuxrc

[kp kirchdoerfer]

Hi Erich;

Am Montag, 28. Dezember 2015, 19:59:45 schrieb Erich Titl:
> Hi KP
> 
> Am 28.12.2015 um 17:23 schrieb kp kirchdoerfer:
> > Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl:
> >> Hi Andrew
> 
> ...
> 
> > /lib/libuuid.so.1.3.0 and its symbolic links
> > 
> > It is marked as an feature "for advanced users" and never has been enabled
> > in busybox, but as part of hdsupp.lrp, which means not having findfs in
> > busybox, does not allow a judgement if the code snippet in linuxrc is
> > used or not.
> If it is not included in busybox all this does not make much sense. It
> will just not work.

Yes it will not work out-of-the-box as outlined by David, but it works if one 
follows the wiki page- hopefully, I haven't checked myself...

> > I suggest to keep it, and probably to enhance our basic system to enable
> > this feature by default.
> 
> Now here is the question, 'what for'?
> 
> - Does LEAF work any better with it - NO
> - Does it make any handling easier - doubtful
> - Does it make LEAF faster - NO
> - Does it make LEAF more secure - NO
> 
> So why clutter linuxrc with old and broken code?

I do not consider it as broken code, until I'm proofed wrong.
David invested some work to find a solution for a specific setup/problem:

"On some systems with multiple disk devices it is not possible to guarantee 
the order in which these are identified at boot time. The disk which starts out 
as /dev/sda might become /dev/sdb after a reboot."

As-Is it requires the user to rebuild initrd, which is painful, but we may 
better improve this than to neglect a problem.

kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] findfs in linuxrc

[kp kirchdoerfer]

Hi Erich;

Am Montag, 28. Dezember 2015, 20:55:39 schrieb Erich Titl:
> Hi KP
> 
> Am 28.12.2015 um 20:43 schrieb kp kirchdoerfer:
> > Hi Erich;
> > 
> > Am Montag, 28. Dezember 2015, 19:59:45 schrieb Erich Titl:
> >> Hi KP
> >> 
> >> Am 28.12.2015 um 17:23 schrieb kp kirchdoerfer:
> >>> Am Mittwoch, 23. Dezember 2015, 15:30:53 schrieb Erich Titl:
> >>>> Hi Andrew
> >> 
> >> ...
> >> 
> >>> /lib/libuuid.so.1.3.0 and its symbolic links
> >>> 
> >>> It is marked as an feature "for advanced users" and never has been
> >>> enabled
> >>> in busybox, but as part of hdsupp.lrp, which means not having findfs in
> >>> busybox, does not allow a judgement if the code snippet in linuxrc is
> >>> used or not.
> >> 
> >> If it is not included in busybox all this does not make much sense. It
> >> will just not work.
> > 
> > Yes it will not work out-of-the-box as outlined by David, but it works if
> > one follows the wiki page- hopefully, I haven't checked myself...
> 
> It will not work at all unless you have findfs.

As described on the wiki page (pull from hdsupp, and rebuild initrd) 

> >> So why clutter linuxrc with old and broken code?
> > 
> > I do not consider it as broken code, until I'm proofed wrong.
> 
> Unless you have findfs it will not work.
> 
> > David invested some work to find a solution for a specific setup/problem:
> > 
> > 
> > "On some systems with multiple disk devices it is not possible to
> > guarantee
> > the order in which these are identified at boot time. The disk which
> > starts out as /dev/sda might become /dev/sdb after a reboot."
> 
> I _guess_ this is true if you add hardware. That would not surprise me.
> It might be true for USB based boot for different systems.
> 
> > As-Is it requires the user to rebuild initrd, which is painful, but we may
> > better improve this than to neglect a problem.
> 
> It requires a different busybox. The current one does not provide findfs.

It requires findfs in initrd, but not necessarily as busybox applet.

> It just puzzles me that nobody ever barfed about it. This makes me think
> it was never used.

Or users had read the wiki page and followed the instructions.
Then it "just works" - hopefully :)

kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] strongswan.lrp

[kp kirchdoerfer]

Hi Erich;

Am Montag, 14. Dezember 2015, 12:02:08 schrieb Erich Titl:
> Hi Folks
> 
> As the old ipsec.lrp has been changed to strongswan.lrp, did anyone
> follow up with checking and renaming ipsec.lwp? Remember my suggestion
> to include the webconf files in the packages :-)

No I didn't.

I don't know if ipsec.lwp (then named strongswan.lwp) will work for 
strongswan.

Your point adding lwp's to pacjages is not valid in this case  - ipsec.lwp 
would have been buried in ipsec.lrp; strongswan.lrp is a complete new package.

Probably you'll have some time, to check if ipsec.lwp can be adopted to be 
used with strongswan as well?

kp

--

___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel