Re: [leaf-devel] moving to Bering-uClibc 6.1.0-alpha2
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
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-devel] [leaf-user] ntpd segfaulting (copied to leaf-devel)
Hi all; this issue is solved and tested in 6.0.4-rc1. The proposed patch has also been accepted for uClibc-ng 1.0.25. kp Am Sonntag, 7. Mai 2017, 17:23:19 schrieb 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-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-devel] [leaf-user] ntpd segfaulting (copied to leaf-devel)
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-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 6.1 - troubles in syslinux
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
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-devel] kernel 4.9 in master
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
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-devel] kernel 4.9 in master
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
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
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-devel] 6.0.1 - shorewall init script
Hi;
Am Dienstag, 3. Januar 2017, 21:05:21 schrieb Martin Hejl:
> Hi Erich
>
> Am 03.01.2017 um 19:59 schrieb Erich Titl:
> > Am 03.01.2017 um 16:04 schrieb Martin Hejl:
> >> Hi all,
> >>
> >> the shorewall init script for 6.0.1 in /etc/init.d/shorewall currently
> >> reads (relevant part only):
> >>
> >> =
> >>
> >> start() {
> >>
> >> echo "Starting IPv4 shorewall rules..."
> >> wait_for_pppd
> >> [ -x /usr/sbin/mount_modules ] && /usr/sbin/mount_modules
> >> /sbin/shorewall $OPTIONS start $STARTOPTIONS
> >> [ -x /usr/sbin/umount_modules ] && /usr/sbin/umount_modules
> >>
> >> }
> >>
> >> stop() {
> >>
> >> echo "Stopping IPv4 shorewall rules..."
> >> /sbin/shorewall stop
> >>
> >> }
> >>
> >> refresh() {
> >>
> >> echo "Refreshing IPv4 shorewall rules..."
> >> /sbin/shorewall refresh $REFRESHOPTIONS
> >>
> >> }
> >>
> >>
> >> reload() {
> >>
> >> echo "Reloading IPv4 shorewall rules..."
> >> /sbin/shorewall reload $RELOADOPTIONS
> >>
> >> }
> >>
> >> restart() {
> >>
> >> echo "Restarting IPv4 shorewall rules..."
> >> /sbin/shorewall restart $RESTARTOPTIONS
> >>
> >> }
> >>
> >> =
> >>
> >> Shouldn't mount_modules and umount_modules also be called for
> >> "restart()" (possibly also for "refresh()" and "reload()") ?
> >
> > You are possibly right.
> >
> >> I've been trying to figure out why I couldn't get DNAT to work
> >> (shorewall always terminated with an error during "svi shorewall
> >> restart" after me updating /etc/shorewall/rules).
> >>
> >> By doing
> >>
> >> svi shorewall stop
> >> svi shorewall start
> >
> > So you changed the shorewall config and then used a re* call option to
> > bring the changes up. Well I never attempted this. I guess it would not
> > be too hard to mount/umount the modules filesystem for all re* calls.
>
> Is that an unusual approach? I guess I always assumed that
> $ svi serviceName restart
>
> would be equivalent to
> $ svi serviceName stop ; svi serviceName start
>
> > You could actually add this to your router and please provide a patch
> > to KP :-)
>
> I will :-) - I just wanted to make sure my understanding is correct, and
> that I didn't miss anything. It's been a while since I played with
> Bering uClibc, and things have moved on a bit since then.
Patching shorewall init is something that needs to be done, but I doubt it
will solve the issue of missing modules and will be more or less cosmetic.
We've had the issue with ipv6 module recently, and it occured it needs to be
added to /etc/modules to get it as painless as possible for users.
I'm curious if we have a similar pb here.
I'm currently rebuild to get a testbed and will investigate as time permits.
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.0.1 issue with dropbear
Hi Martin; Am Dienstag, 3. Januar 2017, 11:23:33 schrieb Martin Hejl: > Hi all, > > there seems to be an issue with dropbear on Bering uClibc 6.0.1 - trying > to connect to it with putty fails with the following error: > > "Couldn't agree a key exchange algorithm" > > It looks like the defines to enable Diffie Hellman key exchange > (DROPBEAR_DH_GROUP1 and DROPBEAR_DH_GROUP14) are missing in options.h > > The following patch fixes the issue for me > > diff --git a/repo/dropbear/options.h b/repo/dropbear/options.h > index 9e598ea..77e888a 100644 > --- a/repo/dropbear/options.h > +++ b/repo/dropbear/options.h > @@ -168,6 +168,11 @@ If you test it please contact the Dropbear author */ >* ECDSA above */ > #define DROPBEAR_ECDH > > +/* Group14 (2048 bit) is recommended. Group1 is less secure (1024 bit) > though > + is the only option for interoperability with some older SSH programs */ > +#define DROPBEAR_DH_GROUP1 1 > +#define DROPBEAR_DH_GROUP14 1 > + > /* Control the memory/performance/compression tradeoff for zlib. >* Set windowBits=8 for least memory usage, see your system's >* zlib.h for full details. Thx; fixed in git. kp > > Martin > > > -- 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
[leaf-devel] post_upgrade branch
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
[leaf-devel] Important: git package shrink
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-devel] leaf upgrade versioning
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
[leaf-devel] git branches refreshed
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
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
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
Re: [leaf-devel] intel network drivers
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+? If so, we'll need certainly need to fix the buildtoo setup, when moving to a newer kernel. 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 > > > -- 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
[leaf-devel] intel network drivers
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] linux-headers
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
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
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] kernel 4.4.14 and accel-ppp-1.10.2 patch fails
Hi Andrew; whilst trying to update the kernel to v 4.4.14 I run into an error with accel- ppp kernel-compat.patch perl -i -p -e 's,#include\s*\,,' /opt/buildtool- master/source/x86_64-unknown-linux-uclibc/accel-ppp/accel-ppp-1.10.2/accel- pppd/ctrl/pppoe/pppoe.c cat kernel-compat.patch | patch -p1 -d /opt/buildtool-master/source/x86_64- unknown-linux-uclibc/accel-ppp/accel-ppp-1.10.2 patching file drivers/ipoe/ipoe.c Hunk #1 FAILED at 512. Hunk #2 FAILED at 770. Hunk #3 FAILED at 884. Hunk #4 FAILED at 2116. 4 out of 4 hunks FAILED -- saving rejects to file drivers/ipoe/ipoe.c.rej Hope you'll be able to fix it. thx kp -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Something has changed with master
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
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-devel] init problem sda1 still mounted
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&iu=/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
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&iu=/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
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&iu=/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
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&iu=/ca-pub-7940484522588532 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] init problem sda1 still mounted
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&iu=/ca-pub-7940484522588532 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] What about removing moddb?
Am Donnerstag, 31. März 2016, 17:31:34 schrieb 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. Anyone looked into the branch, if the changes making sense or if I've made something wrong? I think using hwdetect or install_modules is a minor issue, finishing the general work Erich started with newinitrd seems more important to me, so we can move towards an alpha1 for 6.0.0. 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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] more obscure menu items
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] obscure menu items
Hi Erich; Am Donnerstag, 31. März 2016, 22:24:54 schrieb Erich Titl: > Hi KP > > just to reiterate the menu stuff > > I tried for the first time menu item c) > > On my slow and small router I lost patience before anything could be > displayed and went to start this mail > > And then this > > --- saved/root/.ash_history > +++ running/root/.ash_history > @@ -1143,3 +1143,657 @@ > wpa_cli > ip addr > lrcfg > +ls > +cd /(proc/sys > +cd /proc/sys > +ls > +cd kernel/ > +ls > +cat hotplug > +vi /sbin/hotplug.sh > +mount_modules > +cd /lib/Modules > +ls > +cd /lib/modules/ > +ls > +ls -l > +cd 4.4.3-wrap/ > +ls > +grep ic03 modules.alias > +mount > +vi /sbin/hotplug.sh > +exit > +exit > +exit > +cd /usr/sbin > +ls > +vi common_functions > +ls > +vi mount_modules > +exit > +cd /etc/network > +ls > +ls -l > +ifdown br0 > > For me this is completely useless, it just shows the shell history. > > Then I tried d) > > again agonizing slowness, no progress bar nothing > > *** /etc/modprobe.d is NEW empty directory > --- distribution/etc/default/hostapd > +++ running/etc/default/hostapd > @@ -4,11 +4,11 @@ > # WARNING! Depending on your configuration, > # you may lose access via your wireless interface. > # > -#RUN_DAEMON="yes" > +RUN_DAEMON="yes" > > # Additional daemon options > # -d show more debug messages (-dd for even more) > # -K include key data in debug messages > # -t include timestamps in some debug messages > # > -#DAEMON_OPTS="-dd" > +DAEMON_OPTS="" > --- distribution/etc/default/openvpn > +++ running/etc/default/openvpn > @@ -6,7 +6,7 @@ > # names of the VPNs. If empty, "all" is assumed. > # > #AUTOSTART="all" > -#AUTOSTART="none" > +AUTOSTART="none" > #AUTOSTART="client server" > # > > Mhhh.. I don't know, IMHO less is more It shows a lot more in my case; and while it might not useful for you, it came in quite handy from time to time, at least for me. Each of both a re two lines of code; a feedback for the user would be nice 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&iu=/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?
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&iu=/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?
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&iu=/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?
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] What about removing moddb?
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ALIX specific kernel
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&iu=/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&iu=/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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ALIX specific kernel
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ALIX specific kernel
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ALIX specific kernel
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&iu=/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
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] git master
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
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?
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
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-devel] status of modules loading - old, proposed new and questions
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&iu=/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
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&iu=/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
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 > >
[leaf-devel] status of modules loading - old, proposed new and questions
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Leaf master branch
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&iu=/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
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] http server
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&iu=/4140 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] http server
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&iu=/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
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
[leaf-devel] uclibc-ng build error
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
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
Re: [leaf-devel] findfs in linuxrc
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
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] findfs in linuxrc
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
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] strongswan.lrp
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
Re: [leaf-devel] /etc/module content in initrd
Am Mittwoch, 16. Dezember 2015, 18:28:18 schrieb Erich Titl: > Hi KP > > Am 16.12.2015 um 16:18 schrieb kp kirchdoerfer: > > Am Mittwoch, 16. Dezember 2015, 16:03:44 schrieb Erich Titl: > >> Hi Folks > >> > >> I believe this is inherently wrong > >> > >> ./iscsi/buildtool.mk > >> > >> echo $(ESCKEY) "isofs\nvfat" > > >> $(INITRD_TARGET_DIR)/boot/etc/modules > >> > >> echo $(ESCKEY) "ext4" >> $(INITRD_TARGET_DIR)/boot/etc/modules > >> > >> This gets those modules loaded even if there is no iscsi used to access > >> storage at boot. > > > > I only find these lines in repo/etc/initrd/buildtool.mk > > Look at my corrected mail, sorry > > I am looking at this code from the viewpoint of a new init setup. These > really useful settings refer to compiled in drivers there and are not > needed anymore. Understand, but I don't see that code in iscsi, only in initrd... kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] /etc/module content in initrd
Am Mittwoch, 16. Dezember 2015, 16:03:44 schrieb Erich Titl: > Hi Folks > > I believe this is inherently wrong > > ./iscsi/buildtool.mk > echo $(ESCKEY) "isofs\nvfat" > $(INITRD_TARGET_DIR)/boot/etc/modules > echo $(ESCKEY) "ext4" >> $(INITRD_TARGET_DIR)/boot/etc/modules > > This gets those modules loaded even if there is no iscsi used to access > storage at boot. I only find these lines in repo/etc/initrd/buildtool.mk They are needed to boot from isofs, vfat, ext2, ext3 and ext4 out of the box - which is extremely useful :) kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] libsmartcols.lrp
Am Montag, 14. Dezember 2015, 15:59:38 schrieb Erich Titl: > Hi Folks > > I am trying to understand a dependency of hdsupp to libsmartcols. I see > the libsmartcols package in the repository, but it does not appear to be > present in the sources. > > mega@leafbuilder:~/leaf/devel/bering-uclibc$ git branch > 5.2 > 5.2.1-bugfix > logrotate > * maint > master > new-init > mega@leafbuilder:~/leaf/devel/bering-uclibc$ git pull > Already up-to-date. > mega@leafbuilder:~/leaf/devel/bering-uclibc$ ./buildtool.pl build > libsmartcols > something is wrong in make_require_list, libsmartcols is not a package > nor a source at /home/mega/leaf/devel/bering-uclibc/buildtool/Make.pm > line 264. It is part of util-linux-ng kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] problems with upcoming kernel 4.4
Hi; I've made a full build with the upcoming kernel 4.4 and the "usual suspects" fail to build: ipt_netflow accel-ppp perf Maybe someone can have a look into those. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] iperf/iperf3
Andrew; any reason we still provide iperf(2) additionally to iperf3? kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] [leaf:bering-uclibc] New commit by kapeka
Am Samstag, 12. Dezember 2015, 12:06:26 schrieb Erich Titl: > Am 12.12.2015 um 01:59 schrieb kp kirchdoerfer: > > Am Samstag, 12. Dezember 2015, 01:17:30 schrieb Erich Titl: > >> Am 11.12.2015 um 21:16 schrieb Andrew: > >>> I'm not sure that configs are changed... > >> > >> Yes, I know, but the config headers for sure, if they were built with > >> 'make oldconfig'. And I don't know if there were any new options > >> introduced with 4.1.14, so safe thinking makes me assume this. > > > > Erich, > > there should be no new option, it would have been noticed during build, > > therefor the config files are just renamed ones. > > Ok, good to know. I prefer testing my settings on a known system and it > will take a while before everything works as expected, if at all. > > Could you please consider merging logrotate to maint? I have installed it and will testdrive a few days. I prefer master for this change... kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] [leaf:bering-uclibc] New commit by kapeka
Am Samstag, 12. Dezember 2015, 01:17:30 schrieb Erich Titl: > Am 11.12.2015 um 21:16 schrieb Andrew: > > I'm not sure that configs are changed... > > Yes, I know, but the config headers for sure, if they were built with > 'make oldconfig'. And I don't know if there were any new options > introduced with 4.1.14, so safe thinking makes me assume this. Erich, there should be no new option, it would have been noticed during build, therefor the config files are just renamed ones. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by kapeka
Am Sonntag, 22. November 2015, 13:37:37 schrieb Erich Titl: > Am 22.11.2015 um 13:30 schrieb kp kirchdoerfer: > > Am Sonntag, 22. November 2015, 13:11:59 schrieb Erich Titl: > >> Hi KP > >> > >> There must have been a few typos lately, cherry picking barfs here and > >> shows the problem > > > > versatile is unchanged, but shouldn't have been deleted, So I readded in > > the second commit. > > It is about the version number :-) I know, but his config hasn't been touched. The config files are a base for re-use if something went really or the kernel update requires a change; impportant is the version of the *.cdiff files. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by kapeka
Am Sonntag, 22. November 2015, 13:11:59 schrieb Erich Titl: > Hi KP > > There must have been a few typos lately, cherry picking barfs here and > shows the problem > versatile is unchanged, but shouldn't have been deleted, So I readded in the second commit. kp > umbenannt: repo/linux/Bering-4.1.3.config-i486 -> > repo/linux/Bering-4.1.13.config-i486 > geändert: repo/linux/Bering-4.1.13.config-i686.cdiff > umbenannt: repo/linux/Bering-4.1.3.config-x86_64 -> > repo/linux/Bering-4.1.13.config-x86_64 > geändert: repo/linux/Bering-4.1.13.config-x86_64.cdiff > gelöscht: repo/linux/Bering-4.1.3.config-versatile > > This is in maint > > -rw-rw-r-- 1 mega mega 106012 Nov 22 13:02 Bering-4.1.13.config > -rw-rw-r-- 1 mega mega 93714 Nov 22 13:02 Bering-4.1.13.config-bcmrpi > -rw-rw-r-- 1 mega mega 127078 Nov 22 13:02 Bering-4.1.13.config-bcmrpi.cdiff > -rw-rw-r-- 1 mega mega 102446 Nov 22 13:02 Bering-4.1.13.config-geode > -rw-rw-r-- 1 mega mega 1 Nov 22 13:02 Bering-4.1.13.config-geode.cdiff > -rw-rw-r-- 1 mega mega 106011 Nov 22 13:02 Bering-4.1.13.config-i486 > -rw-rw-r-- 1 mega mega 1 Nov 16 16:40 Bering-4.1.13.config-i486.cdiff > -rw-rw-r-- 1 mega mega 108134 Nov 22 13:02 Bering-4.1.13.config-i686 > -rw-rw-r-- 1 mega mega 22996 Nov 22 13:02 Bering-4.1.13.config-i686.cdiff > -rw-rw-r-- 1 mega mega 69618 Nov 16 16:40 > Bering-4.1.13.config-versatile.cdiff > -rw-rw-r-- 1 mega mega 107419 Nov 22 13:02 Bering-4.1.13.config-x86_64 > -rw-rw-r-- 1 mega mega 29605 Nov 22 13:02 Bering-4.1.13.config-x86_64.cdiff > > > > -rw-rw-r-- 1 mega mega 85980 Nov 22 13:02 Bering-4.1.3.config-versatile > > > > > This is in 5.2.1 > > -rw-rw-r-- 1 mega mega 108133 Nov 22 13:04 Bering-4.1.13.config > -rw-rw-r-- 1 mega mega 128250 Nov 22 13:04 > Bering-4.1.13.config-bcmrpi.cdiff > -rw-rw-r-- 1 mega mega29886 Nov 22 13:04 > Bering-4.1.13.config-geode.cdiff > -rw-rw-r-- 1 mega mega1 Nov 16 16:40 Bering-4.1.13.config-i486.cdiff > -rw-rw-r-- 1 mega mega1 Nov 22 13:04 > Bering-4.1.13.config-i686.cdiff -rw-rw-r-- 1 mega mega69618 Nov 16 > 16:40 > Bering-4.1.13.config-versatile.cdiff > -rw-rw-r-- 1 mega mega29865 Nov 22 13:04 > Bering-4.1.13.config-x86_64.cdiff > -rw-rw-r-- 1 mega mega 106030 Nov 22 13:04 Bering-4.1.3.config-i486 > -rw-rw-r-- 1 mega mega85980 Nov 22 13:02 Bering-4.1.3.config-versatile > -rw-rw-r-- 1 mega mega 107390 Nov 22 13:04 Bering-4.1.3.config-x86_64 > -rw-rw-r-- 1 mega mega93735 Nov 22 13:04 Bering-4.1.7.config-bcmrpi > -rw-rw-r-- 1 mega mega 102555 Nov 22 13:04 Bering-4.1.7.config-geode > -rw-rw-r-- 1 mega mega 108134 Nov 22 13:04 Bering-4.1.7.config-i686 > > I believe 5.2.1 has some left over files in repo/linux and maint may > have a typo in > > mega mega 85980 Nov 22 13:02 Bering-4.1.3.config-versatile > > cheers > > ET > > > > -- > > ___ > 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
Re: [leaf-devel] Fwd: [leaf:bering-uclibc] New commit by kapeka
Am Sonntag, 22. November 2015, 00:53:48 schrieb Erich Titl: > Hi KP > > Weitergeleitete Nachricht > Betreff: [leaf:bering-uclibc] New commit by kapeka > Datum:Sat, 21 Nov 2015 19:26:39 + > Von: LEAF Linux Embedded Appliance Framework Git repository > > Antwort an: LEAF Linux Embedded Appliance Framework Git repository > > An: LEAF Linux Embedded Appliance Framework Git repository > > > > > Branch: maint > > disable kernel debug settings which raises images by factor three. > > Could we use this single commit in 5.2.1-bugfix? You'll also need 283b486e54b773844b027357dfd60c210b89d7f4 and 3b889f506e488fff79baababe0685678f4b75d25 kp > cheers > > ET > > > > -- > > ___ > 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
Re: [leaf-devel] wpasupplicant
Hi Erich; Am Mittwoch, 28. Oktober 2015, 14:40:50 schrieb Erich Titl: > Hi KP > > You lifted wpasupplicant to 2.5 now it does not appear to compile. > > Could you tell me the rationale for > > .source: > - zcat $(SOURCE_TARBALL) | tar -xvf - > + $(BT_SETUP_BUILDDIR) -v $(SOURCE_TARBALL) > touch .source Standardization. > This does not work in my environment s Ok, if it doesn't work for wpasupplicnat, I'll revert this change. sorry kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] apkg -u, the deception?
Hi Erich; Am Donnerstag, 15. Oktober 2015, 23:52:31 schrieb Erich Titl: > Am 15.10.2015 um 20:17 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Donnerstag, 15. Oktober 2015, 19:16:19 schrieb Erich Titl: > >> Hi KP > >> > >> Am 15.10.2015 um 18:41 schrieb kp kirchdoerfer: > >>> Hi Erich; > >> > >> .. > >> > >>> No; we only need the new package with the AC1 and the AC', which is in > >>> configdb.lrp. > >>> If you call apkg -u it will detect the changed file and it will offer > >>> you > >>> to either Keep your version, Show differences, Edit a merge file or to > >>> go > >>> with the new version. > >> > >> How can you merge if you don't have a difference > >> > >>> I've checked that it even works, if you replace the original package > >>> with > >>> the new version on /mnt. > >> > >> Yes, that works and it corresponds to > >> > >> - AC, AC1 and AC' are available, because > >> from AC and AC' we can calculate D and apply it to AC1 > > > > In my tests D was calculated from AC1 and AC'. > > Have you tested or did I something wrong when testing? > > Yes, but this is not the changes the user made between AC and AC' > The changes between AC1 and AC' are not D. I think we don't need three-way diff. We are only interested by apkg -u in AC' and AC1. Why in a usual use case do you need the diff between AC and AC'? > >> In my previous mail there was a typo in the condition above > >> > >>> Pls test. > >>> > >>> So what upgrade can do is to copy the package to /mnt and run apkg -u > >>> afterwards from /mnt. If there are changes, the user can decide how to > >>> proceed. > >> > >> This was the first test I did and I did not like it. It is noisy like > >> hell. > > > > I'm running apkg -u very often and find it very convenient :) > > Most of the time it is and often AC == AC1, but that is not a safe > assumption, as could be seen in the ez-ipupd case. Applying apkg -u to > ez-ipupd.lrp would have led to something different. I believe this is a very special case, where the config mimic has been changed. > The correct sequence is to first calculate D and apply it to AC1. I am > about to test this in upgrade. The only problem I see is the existence > of local.lrp, which may contain just about anything, Yes, this is our last resort for everything else - and totally unpredictable. > >> And most importantly (at least to me) is _the user should not need > >> to intervene_. This is because the average user has either forgotten the > >> changes or applied them using a web interface of some sort. > >> > >> For example, if you use webconf to configure /etc/network/interfaces > >> then the generated file will look a lot different from the one included > >> in the distribution. The user may never have seen the original, how > >> could he make an intelligent choice? > > > > In that case webconf has to be fixed IMHO. > > Webconf creates a very clean interface file. This is normal because it > is machine generated and machines tend to do repetitive tasks better > than hman beings. The original interface file is is a pretty crufty hand > maintained file. If anything, then the initial interface file needs to > be cleaned. But I don't believe this is necessary, as it is possible to > correctly calculate the difference D. The cruft will be part of nearly every config file not build webconf, which is IMHO the default as long as we don't update each and every package to webconf. What you call a mess is IMHO helpful, because it contains user created notes etc.. I document changes and reasons in the config file (like /etc/network/interfaces), and won't miss this feature. > >> Blindly just use the old configuration has it's problems, as seen > >> before, even calculating the difference and applying it to the new > >> config file may be error prone, but probably a lot safer than human > >> intervention. > >> > >>> There has been introduced a safety feature, that every upgrade needs a > >>> response (y/n) , even it doesn't touch any config etc..., but if changes > >>> in the config are detected, you'll be offered with the menu to deal > >>> with > >>> the changes. > >> > >> I messed around with apkg -u and looked at the implementation of > >> apkg.mer
Re: [leaf-devel] ipt-ratelimit fails to build
Hi Andrew; your commit improved build, but still it fails i486-unknown-linux-uclibc-gcc -Os -march=i486 -mtune=pentiumpro - I/opt/buildtool-maint/staging/i486-unknown-linux-uclibc/usr/include - I/opt/buildtool-maint/build/i486-unknown-linux-uclibc/iptables/usr/include -O2 -Wall -Wunused -fPIC -o libxt_ratelimit_sh.o -c libxt_ratelimit.c i486-unknown-linux-uclibc-gcc -Os -march=i486 -mtune=pentiumpro - I/opt/buildtool-maint/staging/i486-unknown-linux-uclibc/usr/include - I/opt/buildtool-maint/build/i486-unknown-linux-uclibc/iptables/usr/include - shared -o libxt_ratelimit.so libxt_ratelimit_sh.o install -D libxt_ratelimit.so /libxt_ratelimit.so install: file /libxt_ratelimit.so" cannot be created No Permisson make[1]: *** [linstall] Error 1 The install target (/) is wrong. kp Am Mittwoch, 14. Oktober 2015, 21:56:24 schrieb Andrew: > Hi. > > Hm, strange. Ok, I'll re-check it. > > 14.10.2015 21:02, kp kirchdoerfer пишет: > > Hi Andrew; > > > > rebuilding from scratch fails with an error > > > > libxt_ratelimit.c:28:21: fatal error: xtables.h: file not found > > > > #include > > > > A problem in kernel configs? > > > > Can you pls doublecheck? > > > > ths kp > > > > -- > > > > > > ___ > > 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
Re: [leaf-devel] apkg -u, the deception?
Hi Erich; Am Donnerstag, 15. Oktober 2015, 19:16:19 schrieb Erich Titl: > Hi KP > > Am 15.10.2015 um 18:41 schrieb kp kirchdoerfer: > > Hi Erich; > > .. > > > No; we only need the new package with the AC1 and the AC', which is in > > configdb.lrp. > > If you call apkg -u it will detect the changed file and it will offer you > > to either Keep your version, Show differences, Edit a merge file or to go > > with the new version. > > How can you merge if you don't have a difference > > I've checked that it even works, if you replace the original package with > > the new version on /mnt. > > Yes, that works and it corresponds to > > - AC, AC1 and AC' are available, because > from AC and AC' we can calculate D and apply it to AC1 In my tests D was calculated from AC1 and AC'. Have you tested or did I something wrong when testing? > In my previous mail there was a typo in the condition above > > > Pls test. > > > > So what upgrade can do is to copy the package to /mnt and run apkg -u > > afterwards from /mnt. If there are changes, the user can decide how to > > proceed. > > This was the first test I did and I did not like it. It is noisy like > hell. I'm running apkg -u very often and find it very convenient :) > And most importantly (at least to me) is _the user should not need > to intervene_. This is because the average user has either forgotten the > changes or applied them using a web interface of some sort. > > For example, if you use webconf to configure /etc/network/interfaces > then the generated file will look a lot different from the one included > in the distribution. The user may never have seen the original, how > could he make an intelligent choice? In that case webconf has to be fixed IMHO. > Blindly just use the old configuration has it's problems, as seen > before, even calculating the difference and applying it to the new > config file may be error prone, but probably a lot safer than human > intervention. > > > There has been introduced a safety feature, that every upgrade needs a > > response (y/n) , even it doesn't touch any config etc..., but if changes > > in the config are detected, you'll be offered with the menu to deal with > > the changes. > I messed around with apkg -u and looked at the implementation of > apkg.merge and apkg.mergefile. These two scripts do nothing more than > what 'diff -r' and 'patch' would do, probably just a lot slower. > > I would like to enable these two applets in busybox and I have done so > in my local branch. Tests are encouraging. It could make the scripts a > lot easier and more consistent than an implementation in bash. Any > objections to enhance busybox? Ok; this is an IMHO a somewhat different/additional issue. You may either merge maint into next or pu (proposed updates) and add your changes there so we can test. Or you make a new (remote) branch with your changes so we can test. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] apkg -u, the deception?
Hi Erich; Am Donnerstag, 15. Oktober 2015, 08:27:56 schrieb Erich Titl: > Hi KP > > > I also _believe_ , that integration of apkg -u into the upgrade script > > will be easier to accomplish the then smaller changes and more helpful, > > than reinvent apkg and configdb. > > I have been thinking hard about this and I believe you are wrong in this > aspect. > Let me state why I think this is so > > - we have a package A of version 1.0 which we just call A > - we have a config file AC belonging to package A , call this AC > - we have an installed package A with a modified config file AC, call > this AC' > - we can detect the difference between AC and AC', lets call this D > - we have a package A of version 1.1, lets call this A1 > - we have a config file AC belonging to package A1, lets call this AC1 > - let us assume that AC <> AC1 > - we want an installed package A1 with the adjusted config file AC1' > > therefore we need a transformation from AC' to AC1' > > - there is no direct transformation from AC' to AC1' > - we can build AC1' by applying D to AC1 > > Right now we do not save D, but we save AC' > > If we replace AC by AC1 (by replacing the corresponding package A by A1) > then we lose the capability to generate the difference D and as a > consequence we loose the transformation from AC1 to AC1' > > This leads me to the conclussion that the transformation of AC' to AC1' > cannot only work if either > > - D is saved, because then we can apply D to AC1 > - AC, AC1 and AC1' are available, because then we can calculate D > > So a tool like apkg -u cannot work unless it is applied from a location > different from the original boot location, because once the package A > has been overwritten by A1 the reference to AC is lost. No; we only need the new package with the AC1 and the AC', which is in configdb.lrp. If you call apkg -u it will detect the changed file and it will offer you to either Keep your version, Show differences, Edit a merge file or to go with the new version. I've checked that it even works, if you replace the original package with the new version on /mnt. Pls test. So what upgrade can do is to copy the package to /mnt and run apkg -u afterwards from /mnt. If there are changes, the user can decide how to proceed. There has been introduced a safety feature, that every upgrade needs a response (y/n) , even it doesn't touch any config etc..., but if changes in the config are detected, you'll be offered with the menu to deal with the changes. > Is there a description how apkg -u is to be used? Only the source code... kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] ipt-ratelimit fails to build
Hi Andrew; rebuilding from scratch fails with an error libxt_ratelimit.c:28:21: fatal error: xtables.h: file not found #include A problem in kernel configs? Can you pls doublecheck? ths kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 5.2 & ezipupd will not work with legacy config file
Am Dienstag, 13. Oktober 2015, 16:49:04 schrieb Erich Titl: > Am 13.10.2015 um 16:25 schrieb kp kirchdoerfer: > > Hi Erich; > > ... > > > So it has been stable from 2002 until 2012, and again three years since > > last change. Or it has there has been only one change in 13 years - I > > think this could be called stable. Go back to your backups from 2002 and > > have a look what system you have had that time on your desktop and how > > much changes have been made since then :) > > ;-) > Yes, my previous system was 4.1 , well maybe older than 2012 and ezipupd > was running fine until I upgraded. I was pretty lucky to find the issue > before I got a new IP from my provider. I _believe_ though that many > LEAF systems are just sitting quietly in a corner and are basically > unmaintained (like mine). Mine would not have changed would it not have > been for a field test for upgrade. > > > Well the reason for this change can be called either an improvement or a > > fix for not well written Package in 2002. > > > > Sometime between 2002 and today dyndns, supported by ezipupdate and reason > > for me to have used it, changed their business model to move away from > > free dns services to something else- which bothered me more than a change > > in our Package. > > Right, I recall there was an issue, fortunately I never used dyndns but > zoneedit and they are stil running mostly the same business plan or at > least kept their legacy customers. > > I am wondering if I would have had no issues at all by upgrading step by > step. I probably would have had less at one time. I also _believe_ that your assumption about "quietly working and almost unmaintained" LEAF boxes is correct, which is a security issue and drawback of providing stable software. I also _believe_, that you might have had less issues at one time if you have had upgraded in smaller steps - or have had a test system to (dual boot) and time to test one of the numerous alpha/beta/rc versions. And it is still my hope that your work on upgrade script will engage users to update more often than we do now, even if we try to release often and therefor to keep changes between releases as small as possible. I also _believe_ , that integration of apkg -u into the upgrade script will be easier to accomplish the then smaller changes and more helpful, than reinvent apkg and configdb. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 5.2 & ezipupd will not work with legacy config file
Hi Erich; Am Dienstag, 13. Oktober 2015, 14:26:14 schrieb Erich Titl: > Hi Folks > > What is the reason for the introduction of the /etc/ez-ipupd directory? The change has been made in 2012 (somewhere in 4.3.x AFAIK) and for the purpose to "allow ezipupd to manage multiple configurations in parallel" (according to git log). > AFAIK ez-ipupd has not been enhanced/changed since 2002, so I cannot see > a reason for this change. Also it appears that now the daemon keyword is > required in the config file, again this was not necessary before, so why > now? Why do we touch working configuration files? This is not useful for > establishing a stable platform. So it has been stable from 2002 until 2012, and again three years since last change. Or it has there has been only one change in 13 years - I think this could be called stable. Go back to your backups from 2002 and have a look what system you have had that time on your desktop and how much changes have been made since then :) Well the reason for this change can be called either an improvement or a fix for not well written Package in 2002. Sometime between 2002 and today dyndns, supported by ezipupdate and reason for me to have used it, changed their business model to move away from free dns services to something else- which bothered me more than a change in our Package. ymmv kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] pty allocation failure (solved)
HI Erich; Am Samstag, 10. Oktober 2015, 13:08:17 schrieb Erich Titl: > Hi KP > > Am 10.10.2015 um 03:20 schrieb kp kirchdoerfer: > > Hi Erich; > > ... > > > This does not happen, if one adds a new etc.lrp with "apkg -u", where > > changes between confg files are noticed to the user, who can then decide > > to Keep the old file, to Replace it with the new version, to Show > > differences or to Edit a merge file. > > > > Can your upgrade script handle this better (does it run apkg -u for > > Packages?), than the sole replacement of the Package file?? > > > > This would be a welcome improvement. > > This is a good point, but it may break upgrade as right now there is no > user interaction, whereas apkg -u always has user interaction and this > IMHO would be a major drawback. Why would this be a major drawback? It is my understanding that the upgrade script downloads the files to your mountpoint/local storage. But that way you'll run into problems like you have seen with fstab. Maybe you can enhance upgrade to also upgrade the running system with apkg -u, as second step, you'll get all the benefits of the upgrade logic of apkg. Yes this requires user action, but without you either miss new config settings or you lose your changes to the config files. The last step would be to svae the changes to configdb. As I said this would be a huge improvement compared to the current upgrade process. > I don't know if there is an option to apkg which makes it silent and > just use the new file, but that could probably be added. Nevertheless, > if apkg could overwrie the package then we still would have to save > configdb, but that is not so bad. Unfortunately, there could be a loss > of valuable information in configdb. > Maybe it would be enough to inform the user of the differences in > important config files. Also had I read the Release Notes I might have > had less guesswork :-( > > >> Had I upgraded the router previously to 5.x this would probably have > >> occurred earlier, it is a 4.x to 5.x issue. I suggest to document this > >> in some gotcha section of an upgrade guide. > > > > Yes; I'll try to take care of this tomorrow. > > Thank you, I am sure there will be more. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] pty allocation failure (solved)
Hi Erich; Am Mittwoch, 7. Oktober 2015, 17:05:09 schrieb Erich Titl: > Hi > > Bad Karma, but I found the reason myself :-( Sorry for late response, have been on holidays last week :) > Am 07.10.2015 um 15:01 schrieb Erich Titl: > > Hi KP > > > > you apparently had the same failure about 2 years ago. I could not find > > the solution in the archives though. > > > > debug1: Allocating pty. > > openpty: No space left on device > > session_pty_req: session 0 alloc failed > > My previous version was 4.1 and there was no entry in fstab for devpts. > I added stuff to /etc/fstab locally, actually completely legal and saved > the changes to configdb, thus the fstab was overwritten and lacked the > entries for the newly created mount points in 5.x. You are right, if you have saved previously changes in fstab to configdb.lrp and just *replace* etc.lrp, providing an updated fstab, your saved fstab will overwrite the new one - and consequently you'll be missing the changes. This does not happen, if one adds a new etc.lrp with "apkg -u", where changes between confg files are noticed to the user, who can then decide to Keep the old file, to Replace it with the new version, to Show differences or to Edit a merge file. Can your upgrade script handle this better (does it run apkg -u for Packages?), than the sole replacement of the Package file?? This would be a welcome improvement. > Had I upgraded the router previously to 5.x this would probably have > occurred earlier, it is a 4.x to 5.x issue. I suggest to document this > in some gotcha section of an upgrade guide. Yes; I'll try to take care of this tomorrow. thx for catching it kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] maint
Hi Erich; Am Sonntag, 4. Oktober 2015, 22:23:12 schrieb Erich Titl: > Hi Folks > > I am a bit puzzled how I should proceed with stuff I am doing in maint. > I would like to have my contributions going into it, but I am constantly > being thrown out of sync by what I would call intrusive changes in that > branch. I consider kernel changes intrusive, as it makes recompilation > and tests impossible when the underlying kernel changes often. I could, > of course, branch off and be done with it, but then my changes would not > be available to others to test. You definition of "intrusive" is from the view of the build environment. From the view of a production environment kernel updates are just more or less important bugfixes and security fixes. Note that usually such kernel updates are introduced this way: "I'm announcing the release of the 4.1.10 kernel. All users of the 4.1 kernel series must upgrade" by the maintainer. So it's inline with our goals for branch maint. > I believe the current setting needs some refinement. I have quite some > experience with linear code management systems, but git is a completely > different beast. > > Here just my experience with 5.2 > > I needed to recompile some kernel code but without me noticing kernel > has moved from 4.1.7 to 4.1.8 and 4.1.9. I consider these changes quite > intrusive as it makes it very hard to work on single, possibly kernel > version related issues when the kernel version changes constantly under > your feet. Basically this means I cannot work on maint and I have to > branch off but then I am cut off the new stuff happening on maint. I > don't see the way out of this impasse but stopping to call things maint > when in fact this is just ongoing work on a future environment. > > Let me know how to overcome this. As you said yourself: Create a branch locally, work on your changes and merge back into maint if done. If you think your work needs more testing by others make your branch available remotely. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] regdb patch for atheros
Am Mittwoch, 30. September 2015, 17:32:40 schrieb Erich Titl: > Hi KP > > Am 30.09.2015 um 16:40 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Dienstag, 29. September 2015, 20:30:42 schrieb Erich Titl: > >> Hi Folks > >> > >> I looked at ma newly installed system and it looks like the patch I > >> wrote to fully enable atheros wireless chips was not applied to the > >> kernel modules. > >> > >> Please advise > > > > Lokks like it has been lost during kernel update, re-added in my build > > environment, rebuild and will test. > > Good, we need to make sure to not shoot each others foot when pushing to > orig. > Committed to branch maint; tested and it works for me. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] regdb patch for atheros
Am Mittwoch, 30. September 2015, 18:56:15 schrieb Erich Titl: > Am 30.09.2015 um 18:30 schrieb kp kirchdoerfer: > > Am Mittwoch, 30. September 2015, 17:32:40 schrieb Erich Titl: > >> Hi KP > >> > >> Am 30.09.2015 um 16:40 schrieb kp kirchdoerfer: > >>> Hi Erich; > >>> > >>> Am Dienstag, 29. September 2015, 20:30:42 schrieb Erich Titl: > >>>> Hi Folks > >>>> > >>>> I looked at ma newly installed system and it looks like the patch I > >>>> wrote to fully enable atheros wireless chips was not applied to the > >>>> kernel modules. > >>>> > >>>> Please advise > >>> > >>> Lokks like it has been lost during kernel update, re-added in my build > >>> environment, rebuild and will test. > >> > >> Good, we need to make sure to not shoot each others foot when pushing to > >> orig. > > > > To orig? > > orig/master :-( > > > Either of us can commit to git repo branch maint as soon, as it's > > build/tested and looks fine. > > Yes, but pulling with rebase is a PITA (/and alledgedly not recommended > as the default action. I still do not understand. I'm rebuilding branch maint with the patch applied and will test on my machine. If that goes well, I'll commit to branch maint, where we collect non-intrusive updates and fixes for 5.2. This branch will be tagged 5.2.1 sometime in the future and a release of 5.2.1 will be done from this branch. Doing a rebase on branch maint etc. is usually no problem and takes a few seconds or minutes, depends how often you rebase it. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] regdb patch for atheros
Am Mittwoch, 30. September 2015, 17:32:40 schrieb Erich Titl: > Hi KP > > Am 30.09.2015 um 16:40 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Dienstag, 29. September 2015, 20:30:42 schrieb Erich Titl: > >> Hi Folks > >> > >> I looked at ma newly installed system and it looks like the patch I > >> wrote to fully enable atheros wireless chips was not applied to the > >> kernel modules. > >> > >> Please advise > > > > Lokks like it has been lost during kernel update, re-added in my build > > environment, rebuild and will test. > > Good, we need to make sure to not shoot each others foot when pushing to > orig. To orig? Either of us can commit to git repo branch maint as soon, as it's build/tested and looks fine. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] shorewall
Am Mittwoch, 30. September 2015, 08:58:17 schrieb Erich Titl: > Hi Tom > > Am 30.09.2015 um 03:36 schrieb Tom Eastep: > > On 9/29/2015 3:59 PM, Erich Titl wrote: > >> Hi Tom > >> > >> Am 30.09.2015 um 00:34 schrieb Tom Eastep: > >> ... > >> > >>> AUTOHELPERS=Yes doesn't cause helpers to be loaded automatically, unless > >>> module autoloading is enabled. It rather associates each helper with its > >>> standard protocols and ports -- see the /etc/shorewall/conntrack file. > >>> The standard /usr/share/shorewall/helpers file should cause them to be > >>> loaded however, provided that the setting of MODULE_SUFFIX in > >>> shorewall.conf is correct. > >> > >> Things look correct AFAIK, is there a way to test helper loading or see > >> if they got loaded. > > > > sh -x /usr/share/shorewall/firewall restart > trace 2>&1 Try sh -x /var/lib/firewall restart > trace 2>&1 kp > Weird, I have no /usr/share/shorewall/firewall file, I looked in the > package and there is no such file neither. > > Ever more, I looked at the previous version 4.6.11, which is working, > and there is no /usr/share/shorewall/firewall file neither. > > Thanks > > Erich > > > > > -- > > ___ > 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
Re: [leaf-devel] Fwd: [leaf:packages] New commit by kapeka
Am Montag, 28. September 2015, 19:08:32 schrieb Erich Titl: > Am 28.09.2015 um 17:48 schrieb kp kirchdoerfer: > > Hello Erich; > > > > Am Sonntag, 27. September 2015, 13:55:34 schrieb Erich Titl: > >> Hi KP > >> I checked the contents of the 5_2 directory this morning using > >> build_upgrade > >> > >> running build_upgrade with parameters 5.2.x 5_2 > > > > while this is fine for testing, we'll need more work for a comprehensive > > solution within the build process. > > As I said before, some of the packages are committed from packages > > directory, the kernel from build dir and some finally from the images. > > This requires a lot of manual intervention and should be improved. > > Ideas welcome. > > Well, I did not want to interfere with the current set up although I > _believe_ it is incoprehensibly complicated. That is why I wrote a tool > to juggle the content to match a more conventional aproach. It does not work that way with the tools we have. > I am not familiar with the tools you use to build the images but stuff > like that should be completely automatic. I would use a makefile, but > then I am old fashioned. One thing I would _not_ do is write my own file > management. The I use are: buildpacket.pl buildimages.pl as documented in the Developer Guide. > - After a full build and packages build all the packages for each > release should be in the packages directory and can just be copied Not all, there is some mangling in buildimages... > - The kernel and associated modules and initrd files can simply be > copied to the respective directories. see above > - The firmware tarball can just be copied, right now I am unpacking it > in build_upgrade, but this could be done before. Why should we start to unpack files, we've packaged before? I'd like to see this handled by upgrade script on the router. kp > Building the installation images is a slightly more complex process and > I have no information on how it is done, but then I did not read the > complete developers manual. > > > ... > > > Currently the firmware.tgz needs user intervention. > > One can unpack firmware and copy required files to /lib/firmware and then > > they'll saved with lrcfg... > > I will keep firmware.tgz as is for now but unpacking it to a directory > above to be able to build a current moddb. That is the way upgrade was > designed. > > > To support more automagic integration AFAIK we need either to enhance > > modules or to come up with a new config file. Or something else. > > > >> Also I believe we can remove the stable-test directory and, to be > >> honest, I am not sure we need to conserve 3_1 and 4_0. > > > > stabble-test has been what it says - a branch you've created for testing. > > OK, I get rid of it > > > I agree we don't need 3_1 and 4_0 any longer, but IMHO it doesn't hurt to > > keep as-is. > > No sweat, just a question of storage. > > cheers > > ET > > > > > -- > > ___ > 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
Re: [leaf-devel] regdb patch for atheros
Hi Erich; Am Dienstag, 29. September 2015, 20:30:42 schrieb Erich Titl: > Hi Folks > > I looked at ma newly installed system and it looks like the patch I > wrote to fully enable atheros wireless chips was not applied to the > kernel modules. > > Please advise Lokks like it has been lost during kernel update, re-added in my build environment, rebuild and will test. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] save modules despite module.sqfs
Hi Erich; Am Dienstag, 29. September 2015, 17:21:12 schrieb Erich Titl: > Hi Andrew > > How do I override the module save lock in 5.2. This is just a bloody PIA Should be default, but could be that you have some leftover from beta versions...?? You may add to leaf.cfg # SaveModules # If set to true modules will be saved to moddb.lrp and it will be safe to #remove modules.sqfs # from your boot image to save space and speed further boots. # If set to false modules won't be saved. Any modules needed on your system, #as defined in modules.lrp # or autodetected will be loaded automatically during boot from modules.sqfs. # Accepted values are: # 1/true/yes/y # respectively # 0/false/no/n UPDATE_MODDB=true If that doesn't work, try to delete /var/lib/lrpkg/sqfs.modules I assume you've *upgraded*, did you have replaced initrd.lrp? kp > Thanks > > Erich > > > -- > > ___ > 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
Re: [leaf-devel] Notes after 5.2 release
Hi Erich; Am Montag, 28. September 2015, 18:51:33 schrieb Erich Titl: > Hi KP > > Am 28.09.2015 um 16:16 schrieb kp kirchdoerfer: > > HI Erich; > > ... > > > Yes; files are identical with he released images as you requested. > > Please do. > > > >> What would you call the first release of 5_2? 5.2.0 or 5.2.1 ? > > > > 5.2.1 > > I expect we'll do 5.2.1 within a month. > > To me, the above is contradictory :-) Indeed :) I should have read your question more carefully. In terms for "upgrade" the first relase will of course be 5.2.0 > > Please improve/cleanup(?) also the sparse usage message in upgrade if you > > touch it. > > Mhhh.. I tried to keep usage as close to *X standards as possible, there > is no man page for it, so it is probably best to do something in the > wiki. I must admit though I am a complete noob when it cones to wikis, > as I loathe this format. > > I can provide some text, maybe structured like so I do like stuff below and it's waht should be added to the wiki. But what I've meant, was only some more verbose help in repo/config/upgrade itself (as given in the Invocation section below) But I see the gotcha, recover etc stuff is something needing documentation beyond the mere usage help. > -- > > Intro > > Upgrade is a new way of keeping your LEAF router up to date with current > releases. > > -- > What is upgrade > > Upgrade is just a small script which tries its best to analyze your > current LEAF version and settings, connects to the LEAF package > repository on sourceforge and replaces your installed LEAF software with > a new release. > -- > Invocation > > Just invoke upgrade from your terninal window. If you want to be fancy > about it, read the parameters section > > Usage and parameters > > Usage: upgrade [-v | --verbose] [--stable | --latest | --release x.y.z] > [--squashfs | --unpacked] > > -v | verbose be chatty (default is off) > > --stable upgrade to current stable release as defined on > the packages repository (the default setting) > > -- latest upgrade to bleeding edge latest release on the > packages repository > > --version x.y.z upgrade to specific version x.y.z on the packages > repository > > --squashfs use squashfs module repository (the default) > > --unpacked use unpacked module directory (only used at development and > debugging) > > Without parameters upgrade will default to > > upgrade --stable --squashfs > > - > Gotchas > > Obviously you need internet connectivity to run upgrade. Then if you > decide to be fancy about releases, be sure they exist at all. The same > goes for --unpacked, there may not be such a repository. > > > Recommendations > > I am running my LEAF system with a double boot system loader, so I > always have a backup should I foul up my installation. The same goes for > upgrade. Make sure you have a backup of your running LEAF installation > before running upgrade. Better to be safe than sorry. > > > We may need to give an example on how to backup and restore the LEAF > installation. > > Honestly I don't know how to restore a LEAF router which does not either > have a PXE capable BIOS or a double boot loader. Then I think PXE is too > hard for the average bloke. > > I am using grub as my bootloader with three partitions on the media, the > first just holding the bootloader, the second my primary LEAF image and > the third a clone of the primary. I can select which system to boot by > using a console. > > > You need a stable internet connection to run upgrade, It takes a while > to download all the new stuff, so please be patient > > Please let us know of all the gotchas you encounter > > > > A remaining question is, if we should remove updater.lrp? I believe it > > does > > nearly the same but I never tested it and don't know if it still works as > > expected??? > > I have never used nor seen it. Sounds like it is not maintained and I > have never seen it announced and then why make it a separate package? > Upgrading a system should be an integral part. AFAIK Andrew did updater.lrp, let's see what he thinks about removing/replacing it. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Fwd: [leaf:packages] New commit by kapeka
Hello Erich; Am Sonntag, 27. September 2015, 13:55:34 schrieb Erich Titl: > Hi KP > I checked the contents of the 5_2 directory this morning using > build_upgrade > > running build_upgrade with parameters 5.2.x 5_2 while this is fine for testing, we'll need more work for a comprehensive solution within the build process. As I said before, some of the packages are committed from packages directory, the kernel from build dir and some finally from the images. This requires a lot of manual intervention and should be improved. Ideas welcome. > > I checked as far as I could, now starting to build the upgrade branch > Gewechselt zu einem neuen Branch '5.2.x' > delete 3_1 > delete 4_0 > delete 4_3 > delete 5_0 > delete 5_1 > skip 5_2 it is in the delete_mask > delete latest > delete stable > delete stable-test > skip tools it is in the delete_mask > > If you continue here the changes made by build_upgrade will be committed > to branch 5.2.x. > Do you wish to continue? Y/N (N) > > It appears that no missing files were detected. However build_upgrade > does not handle firmware yet and thus master is not yet ready to be > tagged. I will extend build_upgrade to include handling of the firmware > tarball too. > > Andrew incuded modules.sqfs to be unpacked and used at system boot, but > how is the firmware tarball to be used? I am not sure the firmware > tarball is used anywhere but in the upgrade tool. Here the use of a > squash file system would be reasonable too. Currently the firmware.tgz needs user intervention. One can unpack firmware and copy required files to /lib/firmware and then they'll saved with lrcfg... To support more automagic integration AFAIK we need either to enhance modules or to come up with a new config file. Or something else. > Also I believe we can remove the stable-test directory and, to be > honest, I am not sure we need to conserve 3_1 and 4_0. stabble-test has been what it says - a branch you've created for testing. I agree we don't need 3_1 and 4_0 any longer, but IMHO it doesn't hurt to keep as-is. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Notes after 5.2 release
HI Erich; Am Montag, 28. September 2015, 11:21:10 schrieb Erich Titl: > Hi KP > > Am 26.09.2015 um 18:57 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Samstag, 26. September 2015, 17:05:56 schrieb Erich Titl: > >> Hi KP > >> > >> Am 26.09.2015 um 16:30 schrieb kp kirchdoerfer: > >>> Hi Erich; > >>> > >>> Am Donnerstag, 24. September 2015, 13:08:14 schrieb Erich Titl: > >>>> Hi KP > >>>> > >>>> Am 22.09.2015 um 18:27 schrieb kp kirchdoerfer: > >>>>> In 5.2 a major target will be to finally get Erich's update mimic up > >>>>> and > > Some more questions > > 5_2 appears to be fully populated for upgrade, should we make a tag to > mark this state? Yes; files are identical with he released images as you requested. Please do. > What would you call the first release of 5_2? 5.2.0 or 5.2.1 ? 5.2.1 > Definitely upgrade still has a bug in whatever is 5_2 right now, so the > config.lrp package needs to be updated. I guess this already calls for a > new bugfix release :-( No problem. I've already committed two updates and still have two in the queue waiting as well as new package for lighttpd. And upgrade hasn't officially announced and documented yet. I expect we'll do 5.2.1 within a month. Please improve/cleanup(?) also the sparse usage message in upgrade if you touch it. A remaining question is, if we should remove updater.lrp? I believe it does nearly the same but I never tested it and don't know if it still works as expected??? kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Notes after 5.2 release
Hi Erich; Am Samstag, 26. September 2015, 17:05:56 schrieb Erich Titl: > Hi KP > > Am 26.09.2015 um 16:30 schrieb kp kirchdoerfer: > > Hi Erich; > > > > Am Donnerstag, 24. September 2015, 13:08:14 schrieb Erich Titl: > >> Hi KP > >> > >> Am 22.09.2015 um 18:27 schrieb kp kirchdoerfer: > >>> In 5.2 a major target will be to finally get Erich's update mimic up > >>> and > >>> running > >> > >> A few questions > >> > >> - What is the 5_2 directory in the packages repository? 5.2.0? > > > > No. These are older packages provided for you during testing of upgrade. > > I need to rebuild the packages so it will take time to update the files in > > 5_2 > Why do you need to rebuild the packages? They should all be in the files > directory. To be shure the Packages, kernel etc are inline with the release. I didn't commit before I started to make updates. As I tried to point before, requirements for upgrade doesn't fit well ino the build process. Most of the stuff could be done from the packages directories, but few files need to be collected from the builded images. This should be improved in the future - at least, once the upgrade process is fixed. > I believe we need one single central repository for the > released packages and IMHO the package repository would be a fine place > to keep them. Agree. > > ... > > > > I hoped you have an idea, depending on your knowledge of the upgrade > > script > > and your tests... > > Well, my idea was (and will remain) to fork off whatever into a 5.2.0 > branch and delete everything there which does not belong to 5.2.0, then > for 5.2.1 fork off 5.2.0 to just replace the specific files for 5.2.1 > and so on. Ok; definitely worth a try. > > I doubt you can work with git tags. > > So do I, they do not appear on the web interface, but branching off is > just as well for the packages. > > So I have a very good target for the upgrade script, 5.2-beta1. As soon > we can build a definite 5_2 in the packages repository I will branch > 5.2.0 off for upgrade. I believe we will see the that branching here is > a good way to keep the repository clean, as long as we keep up the > discipline to just replace the affected files in the packages repository > for a new release branch. This means we need to make sure the compiled > files are reproducible for a defined release, not just functionally > equivalent. There is normally no need to fix things in the package > directory, as there would be new branch for fixes in the x.y.z release > like x.y.z+1 Hmm; I usually copy every builded package to packages/5_x; do you want me to keep track of the changed Packages? This should be solved by git. And it is when committing to a given repository. > I am subscribed to commits, but often the information there is terse at > best (like 'merged master to maint' but why??? ) and somehow I expected > that with the release of 5.2 the packages repository would be updated at > the same time, at least to the existing structure. kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 5_2 stable??
Am Samstag, 26. September 2015, 16:31:21 schrieb kp kirchdoerfer: > Am Samstag, 26. September 2015, 16:23:12 schrieb Erich Titl: > > Hi KP > > > I installed a system with the files published at 5_2, here a few things: > Too bad, mails crossed BTW: Do you have subscribed to leaf-commits list? You could have seen that there has been no commits made to 5_2 for weeks. Would have saved you the time to test an older version. sorry for the inconvenience kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 5_2 stable??
Am Samstag, 26. September 2015, 16:23:12 schrieb Erich Titl: > Hi KP > > I installed a system with the files published at 5_2, here a few things: Too bad, mails crossed kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Notes after 5.2 release
Hi Erich; Am Donnerstag, 24. September 2015, 13:08:14 schrieb Erich Titl: > Hi KP > > Am 22.09.2015 um 18:27 schrieb kp kirchdoerfer: > > In 5.2 a major target will be to finally get Erich's update mimic up and > > running > > A few questions > > - What is the 5_2 directory in the packages repository? 5.2.0? No. These are older packages provided for you during testing of upgrade. I need to rebuild the packages so it will take time to update the files in 5_2 > - Is this a 'stable' release? 5.2 yes, the current packages 5_2 branch not (see above). I've moved git branch maint to maint-5.1 and branch master (based on 5.2) to maint in the meantime. So I expect 5.2 will stay around for a long time. > - How will we distinguish between the 5_2 releases in the package > repository? I hoped you have an idea, depending on your knowledge of the upgrade script and your tests... I doubt you can work with git tags. > - Why is there no firmware in the 5_2 directory? Again see above. kp > cheers > > ET > > > > -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > > ___ > 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] Notes after 5.2 release
Hi all; as you may have seen, after a year of development LEAF Bering-uClibc has been released these days. Congrats and thanks to all who make it happen! It looks like a pretty stable and mature version, and a good base to maintain for the forthcoming future. I'd like to have moved current branch maint to maint-5.1 and current master to maint - as usual when doin a new major release. But I haven't done that before, so I could need help. If someone (Yves?) will do it, it would be great! A short howto will be helpful in the future. Current plan is to eventually make a final release for 5.1 with an updated kernel and strongswan support, and to move on with 5.2.x. In 5.2 a major target will be to finally get Erich's update mimic up and running For upcoming master it's a good time now to collect ideas. Just a few that comes in my mind : gcc update, update uclibc to ulibc-ng or musl, improve building for different architectures by decoupling kernel versions, improvments for build enviroment (e.g. a command like cleanall.sh but without deleting the build of repo/toolchain) kp -- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
