astlinux-devel — The AstLinux development environment, compilation, etc

Re: [Astlinux-devel] Astlinux base system

[Michael K. <li...@mk...>]

> Am 07.04.2020 um 14:47 schrieb David Kerr <da...@ke...>:
> 
> My interest was triggered recently when I came across NanoPi R2S (http://wiki.friendlyarm.com/wiki/index.php/NanoPi_R2S and https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=282) $25 with case, 2x Gbps 1GB RAM.  Of course no sooner had word got out than they sold out.  I almost did an impulse buy but hesitated.  I think you can get from China for a little more money through AliExpress.  You can also google for "<pick a fruit> pi dual ethernet". Try orange or banana :-)
> 
> David

OK, this is interesting. It looks similar to the GL.inet Mango :-).
https://www.gl-inet.com/products/gl-mt300n-v2/

The Mango has only 100MBit/s Ethernet, but supports OpenVPN + WireGuard client and server out of the box!
I installed one of the Creta boxes as WireGuard server shortly:
https://www.gl-inet.com/products/gl-ar750/
 
> On Tue, Apr 7, 2020 at 5:44 AM Michael Keuter <li...@mk...> wrote:
> 
> 
> > Am 06.04.2020 um 21:57 schrieb David Kerr <da...@ke...>:
> > 
> > Kernel 4.19 has been selected by the linux foundation for Super LTS which means that it should have some support structure for many many years.  I'll back off my previous proposal to adopt an off-the-shelf underlying platform... the points about piecemeal package updates potentially causing stability issues is valid.
> > 
> > I'll add one more potentially controversial suggestion... in addition to x86_64 how about ARM64 as well?
> 
> Hi David,
> do you have any specific ARM64 device with multiple gigabit NICs in mind?
> I couldn't find boards either from Ubiquiti (MIPS) or Mikrotik (MIPS + ARM32).
> If you find some that are significantly cheaper than a Qotom or APU2 then please report.
> 
> > For the build system/tools I think we should update to the current buildroot.  While we have been keeping individual package versions up-to-date, we have not been keeping the build system up-to-date (crosstools, config files, etc.)  And it is this that is causing problems when underlying build hosts are updated.  And I am NOT in favor of mandating and/or supporting only one host OS for the build system, be it CentOS, Ubuntu, whatever.
> > 
> > David.
> > 
> > 
> > 
> > On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <li...@lo...> wrote:
> > Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully Ben Hutchings, but unknown as of yet.
> > 
> > Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
> > 
> > Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two before that kernel is tested enough for production.
> > 
> > CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project ... until 2029 !
> > 
> > Lonnie
> > 
> > 
> > 
> > > On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...> wrote:
> > > 
> > > Only the latest 4.x + 5 kernels are supported.
> > > So 4.14 is out.
> > > 
> > > http://aufs.sourceforge.net/
> > > 
> > > Sent from a mobile device.
> > > 
> > > Michael Keuter
> > > 
> > > Anfang der weitergeleiteten Nachricht:
> > > 
> > >> Von: Lonnie Abelbeck <li...@lo...>
> > >> Datum: 2. April 2020 um 17:40:23 MESZ
> > >> An: AstLinux Developers Mailing List <ast...@li...>
> > >> Betreff: Aw:  [Astlinux-devel] Astlinux base system
> > >> Antwort an: AstLinux Developers Mailing List <ast...@li...>
> > >> 
> > >> My short list for AstLinux 1.4.x would be:
> > >> 
> > >> - Kernel bump to 4.x
> > >> - Switch from unionfs to Aufs
> > >> - Support x86_64 only
> > >> - Update the toolchain using a newer gcc and glibc
> > >> - RUNNIX runnix-0.6.0 would be x86_64 only
> > >> 
> > >> As for Buildroot, our version is quite up to date for x86_64 and the packages we use.  We have packages and fixes that are not upstream.
> > >> 
> > >> As for Linux build systems, I would prefer to pick a common basic distro version, CentOS or Debian, and instruct users to only use that version in a VM for building AstLinux.  This would add a level of consistency for the HOST and simplicity for the documentation.  There is no extra-credit for making our build system work with any distro.
> > >> 
> > >> As for toolchains, it would be ideal to find a supported, trusted, x86_64 pre-built toolchain we could use (like a package) with the kernel version we decide to use.  Crosstool-NG is also an option, which if we use a common build HOST we could possibly create our own x86_64 pre-built toolchain which could be downloaded instead of rebuilt for every build system install.
> > >> 
> > >> Finally, the simultaneous equations that need to be solved are, Kernel LTS version where Aufs is actively supported and works with a toolchain we like.
> > >> 
> > >> Lonnie
> > >> 
> > >> 
> > >> 
> > >>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> > >>> 
> > >>> Changed subject to be more relevant to the discussion.
> > >>> 
> > >>> I thought more about this and realized that my itch is not really that we should use a standard distribution, but that we should be thinking about bringing AstLinux more up-to-date and discussing how to go about it.  Yes the kernel 3.16.x works fine and will do for some time.  But the day will come when we must move.  In addition our base system is built from a very old version of buildroot, toolchains, libraries, etc. and we run into issues as underlying hosts change... mostly simple things like version checks failing and we have been able to work around them.  But it is getting harder... the most recent one being when I tried the ZFS file system on Ubuntu 19.10.
> > >>> 
> > >>> Maybe if we changed how we build AstLinux to start from a standard/stable version of buildroot (rather than essentially copying all of buildroot into our own source tree).  I'm not even sure what I mean by that, but I think we should look for a way to stay closer aligned and be able to easily update with Buildroot versions.
> > >>> 
> > >>> David.
> > >>> 
> > >>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <mic...@ip...> wrote:
> > >>> After using  OpenWRT for a little while, I decided to abandon its use for two reasons, 1) Wifi driver support but also 2) packages. It was so difficult to maintain a standard image across all my routers and I never knew what package was going to affect what and what would break when I upgraded and then how I would revert. Although I hate Mikrotik's UI and command structure, I decided to suck it up and move to them because of a single firmware image amongst other things.
> > >>> 
> > >>> Although I am not that knowledgeable in the area, I believe the stability of Astlinux is because of the minimalist approach taken to what is included and enabled. 
> > >>> I therefore really like the current approach and certainly would not want to move to 'a series of entangled package upgrades'.
> > >>> 
> > >>> Thanks David for asking these questions as its really important that we understand what we are doing and why. 
> > >>> 
> > >>> Regards
> > >>> Michael Knill
> > >>> 
> > >>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> > >>> 
> > >>>    Hi David, et.al,
> > >>> 
> > >>>    Brainstorming ideas are always appreciated.
> > >>> 
> > >>>    Though I think our "AstLinux Principles" still apply today, as much as ever:
> > >>> 
> > >>>    AstLinux Principles:
> > >>>    https://www.astlinux-project.org/about.html
> > >>> 
> > >>>    Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> > >>> 
> > >>>    Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.
> > >>> 
> > >>>    Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.
> > >>> 
> > >>>    Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.
> > >>> 
> > >>>    Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.
> > >>> 
> > >>>    Please discuss ...
> > >>> 
> > >>>    Lonnie
> > >>> 
> > >>>    [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> > >>> 
> > >>> 
> > >>> 
> > >>> 
> > >>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> > >>>> 
> > >>>> Moving to devel list.
> > >>>> 
> > >>>> This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
> > >>>> 
> > >>>> Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
> > >>>> 
> > >>>> Just thought I would throw this out there and see what people think.
> > >>>> 
> > >>>> David.
> > >>>> 
> > >>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
> > >>>> Greetings,
> > >>>> 
> > >>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
> > >>>> 
> > >>>> My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
> > >>>> 
> > >>>> For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
> > >>>> 
> > >>>> Lonnie
> > >>>> 
> > >>>> 
> > >>>> ================
> > >>>> Begin forwarded message:
> > >>>> 
> > >>>> From: "Jason A. Donenfeld" <Ja...@zx...>
> > >>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> > >>>> Date: March 29, 2020 at 9:16:43 PM CDT
> > >>>> To: WireGuard mailing list <wir...@li...>
> > >>>> 
> > >>>> Hi folks,
> > >>>> 
> > >>>> Earlier this evening, Linus released [1] Linus 5.6, which contains our
> > >>>> first release of WireGuard. This is quite exciting. It means that
> > >>>> kernels from here on out will have WireGuard built-in by default. And
> > >>>> for those of you who were scared away prior by the "dOnT uSe tHiS
> > >>>> k0de!!1!" warnings everywhere, you now have something more stable to
> > >>>> work with.
> > >>>> 
> > >>>> The last several weeks of 5.6 development and stabilization have been
> > >>>> exciting, with our codebase undergoing a quick security audit [3], and
> > >>>> some real headway in terms of getting into distributions.
> > >>>> 
> > >>>> We'll also continue to maintain our wireguard-linux-compat [2]
> > >>>> backports repo for older kernels. On the backports front, WireGuard
> > >>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> > >>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
> > >>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> > >>>> and we'll see where those wind up; 5.4.y is an LTS release.
> > >>>> 
> > >>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> > >>>> Fedora 32 will be getting WireGuard automatically by virtue of having
> > >>>> 5.6, and I expect these to increase in number over time.
> > >>>> 
> > >>>> Enjoy!
> > >>>> Jason
> > >>>> 
> > >>>> 
> > >>>> [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> > >>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
> > >>>> [3] https://lore.kernel.org/netdev/202...@zx.../
> > >>>> [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> > >>>> [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> > >>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> > >>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> Michael
> 
> http://www.mksolutions.info

Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Astlinux base system

[David K. <da...@ke...>]

My interest was triggered recently when I came across NanoPi R2S (
http://wiki.friendlyarm.com/wiki/index.php/NanoPi_R2S and
https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=282)
$25 with case, 2x Gbps 1GB RAM.  Of course no sooner had word got out than
they sold out.  I almost did an impulse buy but hesitated.  I think you can
get from China for a little more money through AliExpress.  You can also
google for "<pick a fruit> pi dual ethernet". Try orange or banana :-)

David

On Tue, Apr 7, 2020 at 5:44 AM Michael Keuter <li...@mk...>
wrote:

>
>
> > Am 06.04.2020 um 21:57 schrieb David Kerr <da...@ke...>:
> >
> > Kernel 4.19 has been selected by the linux foundation for Super LTS
> which means that it should have some support structure for many many
> years.  I'll back off my previous proposal to adopt an off-the-shelf
> underlying platform... the points about piecemeal package updates
> potentially causing stability issues is valid.
> >
> > I'll add one more potentially controversial suggestion... in addition to
> x86_64 how about ARM64 as well?
>
> Hi David,
> do you have any specific ARM64 device with multiple gigabit NICs in mind?
> I couldn't find boards either from Ubiquiti (MIPS) or Mikrotik (MIPS +
> ARM32).
> If you find some that are significantly cheaper than a Qotom or APU2 then
> please report.
>
> > For the build system/tools I think we should update to the current
> buildroot.  While we have been keeping individual package versions
> up-to-date, we have not been keeping the build system up-to-date
> (crosstools, config files, etc.)  And it is this that is causing problems
> when underlying build hosts are updated.  And I am NOT in favor of
> mandating and/or supporting only one host OS for the build system, be it
> CentOS, Ubuntu, whatever.
> >
> > David.
> >
> >
> >
> > On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> > Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully
> Ben Hutchings, but unknown as of yet.
> >
> > Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
> >
> > Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two
> before that kernel is tested enough for production.
> >
> > CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project
> ... until 2029 !
> >
> > Lonnie
> >
> >
> >
> > > On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...>
> wrote:
> > >
> > > Only the latest 4.x + 5 kernels are supported.
> > > So 4.14 is out.
> > >
> > > http://aufs.sourceforge.net/
> > >
> > > Sent from a mobile device.
> > >
> > > Michael Keuter
> > >
> > > Anfang der weitergeleiteten Nachricht:
> > >
> > >> Von: Lonnie Abelbeck <li...@lo...>
> > >> Datum: 2. April 2020 um 17:40:23 MESZ
> > >> An: AstLinux Developers Mailing List <
> ast...@li...>
> > >> Betreff: Aw:  [Astlinux-devel] Astlinux base system
> > >> Antwort an: AstLinux Developers Mailing List <
> ast...@li...>
> > >>
> > >> My short list for AstLinux 1.4.x would be:
> > >>
> > >> - Kernel bump to 4.x
> > >> - Switch from unionfs to Aufs
> > >> - Support x86_64 only
> > >> - Update the toolchain using a newer gcc and glibc
> > >> - RUNNIX runnix-0.6.0 would be x86_64 only
> > >>
> > >> As for Buildroot, our version is quite up to date for x86_64 and the
> packages we use.  We have packages and fixes that are not upstream.
> > >>
> > >> As for Linux build systems, I would prefer to pick a common basic
> distro version, CentOS or Debian, and instruct users to only use that
> version in a VM for building AstLinux.  This would add a level of
> consistency for the HOST and simplicity for the documentation.  There is no
> extra-credit for making our build system work with any distro.
> > >>
> > >> As for toolchains, it would be ideal to find a supported, trusted,
> x86_64 pre-built toolchain we could use (like a package) with the kernel
> version we decide to use.  Crosstool-NG is also an option, which if we use
> a common build HOST we could possibly create our own x86_64 pre-built
> toolchain which could be downloaded instead of rebuilt for every build
> system install.
> > >>
> > >> Finally, the simultaneous equations that need to be solved are,
> Kernel LTS version where Aufs is actively supported and works with a
> toolchain we like.
> > >>
> > >> Lonnie
> > >>
> > >>
> > >>
> > >>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> > >>>
> > >>> Changed subject to be more relevant to the discussion.
> > >>>
> > >>> I thought more about this and realized that my itch is not really
> that we should use a standard distribution, but that we should be thinking
> about bringing AstLinux more up-to-date and discussing how to go about it.
> Yes the kernel 3.16.x works fine and will do for some time.  But the day
> will come when we must move.  In addition our base system is built from a
> very old version of buildroot, toolchains, libraries, etc. and we run into
> issues as underlying hosts change... mostly simple things like version
> checks failing and we have been able to work around them.  But it is
> getting harder... the most recent one being when I tried the ZFS file
> system on Ubuntu 19.10.
> > >>>
> > >>> Maybe if we changed how we build AstLinux to start from a
> standard/stable version of buildroot (rather than essentially copying all
> of buildroot into our own source tree).  I'm not even sure what I mean by
> that, but I think we should look for a way to stay closer aligned and be
> able to easily update with Buildroot versions.
> > >>>
> > >>> David.
> > >>>
> > >>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <
> mic...@ip...> wrote:
> > >>> After using  OpenWRT for a little while, I decided to abandon its
> use for two reasons, 1) Wifi driver support but also 2) packages. It was so
> difficult to maintain a standard image across all my routers and I never
> knew what package was going to affect what and what would break when I
> upgraded and then how I would revert. Although I hate Mikrotik's UI and
> command structure, I decided to suck it up and move to them because of a
> single firmware image amongst other things.
> > >>>
> > >>> Although I am not that knowledgeable in the area, I believe the
> stability of Astlinux is because of the minimalist approach taken to what
> is included and enabled.
> > >>> I therefore really like the current approach and certainly would not
> want to move to 'a series of entangled package upgrades'.
> > >>>
> > >>> Thanks David for asking these questions as its really important that
> we understand what we are doing and why.
> > >>>
> > >>> Regards
> > >>> Michael Knill
> > >>>
> > >>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> > >>>
> > >>>    Hi David, et.al,
> > >>>
> > >>>    Brainstorming ideas are always appreciated.
> > >>>
> > >>>    Though I think our "AstLinux Principles" still apply today, as
> much as ever:
> > >>>
> > >>>    AstLinux Principles:
> > >>>    https://www.astlinux-project.org/about.html
> > >>>
> > >>>    Our current 3.16.x kernel has been getting backported fixes from
> upstream [1] for quite some time by Ben Hutchings ... some would argue that
> the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> > >>>
> > >>>    Correct me if you disagree, but since we use i586/x86_64
> architecture much of the newer kernel hardware support does not apply to
> us.  This is even more true for AstLinux running as VM Guests.
> > >>>
> > >>>    Additionally, a big sticking point upgrading beyond the 3.16.x
> kernel is our current unionfs kernel patches are no longer supported in
> 4.x.  Looks like we will need to switch to Aufs, which we have been giving
> some thought, making it backward compatible is a concern.
> > >>>
> > >>>    Some might argue we should stick with a rock-solid 3.16.x kernel
> for another year or so, others might suggest 4.x (unclear which is best) is
> warranted.  I think 5.x is too new to consider IMO, not enough testing.
> > >>>
> > >>>    Finally, packages vs. firmware-image.  I'm convinced the
> firmware-image approach is ideal for an appliance like AstLinux.  I've
> played with OpenWrt on an EdgeRouter-X, and found the package upgrade
> approach leaves much to be desired compared with a firmware-image approach.
> > >>>
> > >>>    Please discuss ...
> > >>>
> > >>>    Lonnie
> > >>>
> > >>>    [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> > >>>>
> > >>>> Moving to devel list.
> > >>>>
> > >>>> This once again prompts the question as to what to do about
> AstLinux kernel version.  It feels that we are getting further and further
> behind and should maybe even skip 4.x and go straight to a 5.x.
> > >>>>
> > >>>> Or... get out of the business of providing the low level OS
> components and develop on top of a standard "lightweight" distribution.
> When AstLinux started up there was a need for a tight, small, integrated
> system that would work on typical network gateway hardware of the time.
> But today's typical network gateway hardware is very capable of running a
> standard linux distribution.  And if we moved all the AstLinux-unique
> features over to installable packages I think we would benefit greatly.
> > >>>>
> > >>>> Just thought I would throw this out there and see what people think.
> > >>>>
> > >>>> David.
> > >>>>
> > >>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <
> li...@lo...> wrote:
> > >>>> Greetings,
> > >>>>
> > >>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
> > >>>>
> > >>>> My favorite VPN type (as well as many of you reading this) has
> achieved a major milestone.  Additionally, an outside security audit of
> WireGuard has been performed.
> > >>>>
> > >>>> For those previously concerned about the non-official status of
> WireGuard, those concerns should now be minimized.
> > >>>>
> > >>>> Lonnie
> > >>>>
> > >>>>
> > >>>> ================
> > >>>> Begin forwarded message:
> > >>>>
> > >>>> From: "Jason A. Donenfeld" <Ja...@zx...>
> > >>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> > >>>> Date: March 29, 2020 at 9:16:43 PM CDT
> > >>>> To: WireGuard mailing list <wir...@li...>
> > >>>>
> > >>>> Hi folks,
> > >>>>
> > >>>> Earlier this evening, Linus released [1] Linus 5.6, which contains
> our
> > >>>> first release of WireGuard. This is quite exciting. It means that
> > >>>> kernels from here on out will have WireGuard built-in by default.
> And
> > >>>> for those of you who were scared away prior by the "dOnT uSe tHiS
> > >>>> k0de!!1!" warnings everywhere, you now have something more stable to
> > >>>> work with.
> > >>>>
> > >>>> The last several weeks of 5.6 development and stabilization have
> been
> > >>>> exciting, with our codebase undergoing a quick security audit [3],
> and
> > >>>> some real headway in terms of getting into distributions.
> > >>>>
> > >>>> We'll also continue to maintain our wireguard-linux-compat [2]
> > >>>> backports repo for older kernels. On the backports front, WireGuard
> > >>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> > >>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also
> maintaining
> > >>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y
> [7],
> > >>>> and we'll see where those wind up; 5.4.y is an LTS release.
> > >>>>
> > >>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> > >>>> Fedora 32 will be getting WireGuard automatically by virtue of
> having
> > >>>> 5.6, and I expect these to increase in number over time.
> > >>>>
> > >>>> Enjoy!
> > >>>> Jason
> > >>>>
> > >>>>
> > >>>> [1]
> https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> > >>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
> > >>>> [3]
> https://lore.kernel.org/netdev/202...@zx.../
> > >>>> [4]
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> > >>>> [5]
> https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> > >>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> > >>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> > >>>>
> > >>>>
> > >>>> _______________________________________________
> > >>>> Astlinux-users mailing list
> > >>>> Ast...@li...
> > >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> > >>>>
> > >>>> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> > >>>> _______________________________________________
> > >>>> Astlinux-devel mailing list
> > >>>> Ast...@li...
> > >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>>
> > >>>
> > >>>
> > >>>    _______________________________________________
> > >>>    Astlinux-devel mailing list
> > >>>    Ast...@li...
> > >>>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Astlinux-devel mailing list
> > >>> Ast...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>> _______________________________________________
> > >>> Astlinux-devel mailing list
> > >>> Ast...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Astlinux-devel mailing list
> > >> Ast...@li...
> > >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> >
> >
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

Re: [Astlinux-devel] Astlinux base system

[Michael K. <li...@mk...>]

> Am 06.04.2020 um 21:57 schrieb David Kerr <da...@ke...>:
> 
> Kernel 4.19 has been selected by the linux foundation for Super LTS which means that it should have some support structure for many many years.  I'll back off my previous proposal to adopt an off-the-shelf underlying platform... the points about piecemeal package updates potentially causing stability issues is valid.
> 
> I'll add one more potentially controversial suggestion... in addition to x86_64 how about ARM64 as well?

Hi David,
do you have any specific ARM64 device with multiple gigabit NICs in mind?
I couldn't find boards either from Ubiquiti (MIPS) or Mikrotik (MIPS + ARM32).
If you find some that are significantly cheaper than a Qotom or APU2 then please report.

> For the build system/tools I think we should update to the current buildroot.  While we have been keeping individual package versions up-to-date, we have not been keeping the build system up-to-date (crosstools, config files, etc.)  And it is this that is causing problems when underlying build hosts are updated.  And I am NOT in favor of mandating and/or supporting only one host OS for the build system, be it CentOS, Ubuntu, whatever.
> 
> David.
> 
> 
> 
> On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <li...@lo...> wrote:
> Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully Ben Hutchings, but unknown as of yet.
> 
> Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
> 
> Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two before that kernel is tested enough for production.
> 
> CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project ... until 2029 !
> 
> Lonnie
> 
> 
> 
> > On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...> wrote:
> > 
> > Only the latest 4.x + 5 kernels are supported.
> > So 4.14 is out.
> > 
> > http://aufs.sourceforge.net/
> > 
> > Sent from a mobile device.
> > 
> > Michael Keuter
> > 
> > Anfang der weitergeleiteten Nachricht:
> > 
> >> Von: Lonnie Abelbeck <li...@lo...>
> >> Datum: 2. April 2020 um 17:40:23 MESZ
> >> An: AstLinux Developers Mailing List <ast...@li...>
> >> Betreff: Aw:  [Astlinux-devel] Astlinux base system
> >> Antwort an: AstLinux Developers Mailing List <ast...@li...>
> >> 
> >> My short list for AstLinux 1.4.x would be:
> >> 
> >> - Kernel bump to 4.x
> >> - Switch from unionfs to Aufs
> >> - Support x86_64 only
> >> - Update the toolchain using a newer gcc and glibc
> >> - RUNNIX runnix-0.6.0 would be x86_64 only
> >> 
> >> As for Buildroot, our version is quite up to date for x86_64 and the packages we use.  We have packages and fixes that are not upstream.
> >> 
> >> As for Linux build systems, I would prefer to pick a common basic distro version, CentOS or Debian, and instruct users to only use that version in a VM for building AstLinux.  This would add a level of consistency for the HOST and simplicity for the documentation.  There is no extra-credit for making our build system work with any distro.
> >> 
> >> As for toolchains, it would be ideal to find a supported, trusted, x86_64 pre-built toolchain we could use (like a package) with the kernel version we decide to use.  Crosstool-NG is also an option, which if we use a common build HOST we could possibly create our own x86_64 pre-built toolchain which could be downloaded instead of rebuilt for every build system install.
> >> 
> >> Finally, the simultaneous equations that need to be solved are, Kernel LTS version where Aufs is actively supported and works with a toolchain we like.
> >> 
> >> Lonnie
> >> 
> >> 
> >> 
> >>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> >>> 
> >>> Changed subject to be more relevant to the discussion.
> >>> 
> >>> I thought more about this and realized that my itch is not really that we should use a standard distribution, but that we should be thinking about bringing AstLinux more up-to-date and discussing how to go about it.  Yes the kernel 3.16.x works fine and will do for some time.  But the day will come when we must move.  In addition our base system is built from a very old version of buildroot, toolchains, libraries, etc. and we run into issues as underlying hosts change... mostly simple things like version checks failing and we have been able to work around them.  But it is getting harder... the most recent one being when I tried the ZFS file system on Ubuntu 19.10.
> >>> 
> >>> Maybe if we changed how we build AstLinux to start from a standard/stable version of buildroot (rather than essentially copying all of buildroot into our own source tree).  I'm not even sure what I mean by that, but I think we should look for a way to stay closer aligned and be able to easily update with Buildroot versions.
> >>> 
> >>> David.
> >>> 
> >>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <mic...@ip...> wrote:
> >>> After using  OpenWRT for a little while, I decided to abandon its use for two reasons, 1) Wifi driver support but also 2) packages. It was so difficult to maintain a standard image across all my routers and I never knew what package was going to affect what and what would break when I upgraded and then how I would revert. Although I hate Mikrotik's UI and command structure, I decided to suck it up and move to them because of a single firmware image amongst other things.
> >>> 
> >>> Although I am not that knowledgeable in the area, I believe the stability of Astlinux is because of the minimalist approach taken to what is included and enabled. 
> >>> I therefore really like the current approach and certainly would not want to move to 'a series of entangled package upgrades'.
> >>> 
> >>> Thanks David for asking these questions as its really important that we understand what we are doing and why. 
> >>> 
> >>> Regards
> >>> Michael Knill
> >>> 
> >>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> >>> 
> >>>    Hi David, et.al,
> >>> 
> >>>    Brainstorming ideas are always appreciated.
> >>> 
> >>>    Though I think our "AstLinux Principles" still apply today, as much as ever:
> >>> 
> >>>    AstLinux Principles:
> >>>    https://www.astlinux-project.org/about.html
> >>> 
> >>>    Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> >>> 
> >>>    Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.
> >>> 
> >>>    Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.
> >>> 
> >>>    Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.
> >>> 
> >>>    Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.
> >>> 
> >>>    Please discuss ...
> >>> 
> >>>    Lonnie
> >>> 
> >>>    [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> >>> 
> >>> 
> >>> 
> >>> 
> >>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> >>>> 
> >>>> Moving to devel list.
> >>>> 
> >>>> This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
> >>>> 
> >>>> Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
> >>>> 
> >>>> Just thought I would throw this out there and see what people think.
> >>>> 
> >>>> David.
> >>>> 
> >>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
> >>>> Greetings,
> >>>> 
> >>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
> >>>> 
> >>>> My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
> >>>> 
> >>>> For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
> >>>> 
> >>>> Lonnie
> >>>> 
> >>>> 
> >>>> ================
> >>>> Begin forwarded message:
> >>>> 
> >>>> From: "Jason A. Donenfeld" <Ja...@zx...>
> >>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> >>>> Date: March 29, 2020 at 9:16:43 PM CDT
> >>>> To: WireGuard mailing list <wir...@li...>
> >>>> 
> >>>> Hi folks,
> >>>> 
> >>>> Earlier this evening, Linus released [1] Linus 5.6, which contains our
> >>>> first release of WireGuard. This is quite exciting. It means that
> >>>> kernels from here on out will have WireGuard built-in by default. And
> >>>> for those of you who were scared away prior by the "dOnT uSe tHiS
> >>>> k0de!!1!" warnings everywhere, you now have something more stable to
> >>>> work with.
> >>>> 
> >>>> The last several weeks of 5.6 development and stabilization have been
> >>>> exciting, with our codebase undergoing a quick security audit [3], and
> >>>> some real headway in terms of getting into distributions.
> >>>> 
> >>>> We'll also continue to maintain our wireguard-linux-compat [2]
> >>>> backports repo for older kernels. On the backports front, WireGuard
> >>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> >>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
> >>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> >>>> and we'll see where those wind up; 5.4.y is an LTS release.
> >>>> 
> >>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> >>>> Fedora 32 will be getting WireGuard automatically by virtue of having
> >>>> 5.6, and I expect these to increase in number over time.
> >>>> 
> >>>> Enjoy!
> >>>> Jason
> >>>> 
> >>>> 
> >>>> [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> >>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
> >>>> [3] https://lore.kernel.org/netdev/202...@zx.../
> >>>> [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> >>>> [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> >>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> >>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> Astlinux-users mailing list
> >>>> Ast...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >>>> 
> >>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> >>>> _______________________________________________
> >>>> Astlinux-devel mailing list
> >>>> Ast...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>> 
> >>> 
> >>> 
> >>>    _______________________________________________
> >>>    Astlinux-devel mailing list
> >>>    Ast...@li...
> >>>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Astlinux-devel mailing list
> >>> Ast...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>> _______________________________________________
> >>> Astlinux-devel mailing list
> >>> Ast...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Astlinux-devel mailing list
> >> Ast...@li...
> >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel


Michael

http://www.mksolutions.info

Re: [Astlinux-devel] Astlinux base system

[David K. <da...@ke...>]

Here is the SLTS announcement....
https://www.linuxfoundation.org/press-release/2019/02/civil-infrastructure-platform-announces-new-super-long-term-support-kernel-that-advances-automation-machine-learning-and-artificial-intelligence/

David.

On Mon, Apr 6, 2020 at 4:45 PM Lonnie Abelbeck <li...@lo...>
wrote:

> Hi David, (inline comments)
>
> > On Apr 6, 2020, at 2:57 PM, David Kerr <Da...@Ke...> wrote:
> >
> > Kernel 4.19 has been selected by the linux foundation for Super LTS
> which means that it should have some support structure for many many years.
>
> That is great news, but where did you see that announcement ?
>
> This has not been updated yet:
> https://www.kernel.org/category/releases.html
>
>
> > I'll back off my previous proposal to adopt an off-the-shelf underlying
> platform... the points about piecemeal package updates potentially causing
> stability issues is valid.
> >
> > I'll add one more potentially controversial suggestion... in addition to
> x86_64 how about ARM64 as well?
>
> ARM64 is a whole different critter, no PCI bus to make things interconnect
> in a standard way, but as I understand it, things need to be tweaked for
> each specific board with ARM.
>
>
> > For the build system/tools I think we should update to the current
> buildroot.  While we have been keeping individual package versions
> up-to-date, we have not been keeping the build system up-to-date
> (crosstools, config files, etc.)
>
> We should definitely upgrade crosstool-NG, but starting over with the
> latest Buildroot is non-trivial and error prone.
>
>
> > And it is this that is causing problems when underlying build hosts are
> updated.  And I am NOT in favor of mandating and/or supporting only one
> host OS for the build system, be it CentOS, Ubuntu, whatever.
>
> Can you explain why you are not in favor of a "standard" build host ?  I
> would expect everyone would use a VM these days, the build host choice
> seems moot.
>
>
> BTW, I have been playing with Debian 10 within VMware Fusion.  This seems
> like a good choice. (640MB download)
>
>
> https://cdimage.debian.org/debian-cd/10.3.0/amd64/iso-cd/debian-10.3.0-amd64-xfce-CD-1.iso
>
> I'm playing with crosstool-NG 1.24.0 ... my first try was:
> --
> gcc: 8.3.0
> glibc: 2.28
> binutils 2.31.1
> --
> That caused weird problems building udev (albeit udev is somewhat old)
>
> I'm now trying a more compatible toolchain choice:
> --
> gcc: 6.4.0
> glibc: 2.26
> binutils 2.29.1
> --
>
> A point of reference, the latest Synology DSM 6.2.2 is:
> --
> gcc: 4.9.3
> glibc: 2.20
>
> Linux: 3.10.105
> --
>
>
> Lonnie
>
>
>
> >
> > David.
> >
> >
> >
> > On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <
> li...@lo...> wrote:
> > Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully
> Ben Hutchings, but unknown as of yet.
> >
> > Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
> >
> > Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two
> before that kernel is tested enough for production.
> >
> > CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project
> ... until 2029 !
> >
> > Lonnie
> >
> >
> >
> >> On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...>
> wrote:
> >>
> >> Only the latest 4.x + 5 kernels are supported.
> >> So 4.14 is out.
> >>
> >> http://aufs.sourceforge.net/
> >>
> >> Sent from a mobile device.
> >>
> >> Michael Keuter
> >>
> >> Anfang der weitergeleiteten Nachricht:
> >>
> >>> Von: Lonnie Abelbeck <li...@lo...>
> >>> Datum: 2. April 2020 um 17:40:23 MESZ
> >>> An: AstLinux Developers Mailing List <
> ast...@li...>
> >>> Betreff: Aw:  [Astlinux-devel] Astlinux base system
> >>> Antwort an: AstLinux Developers Mailing List <
> ast...@li...>
> >>>
> >>> My short list for AstLinux 1.4.x would be:
> >>>
> >>> - Kernel bump to 4.x
> >>> - Switch from unionfs to Aufs
> >>> - Support x86_64 only
> >>> - Update the toolchain using a newer gcc and glibc
> >>> - RUNNIX runnix-0.6.0 would be x86_64 only
> >>>
> >>> As for Buildroot, our version is quite up to date for x86_64 and the
> packages we use.  We have packages and fixes that are not upstream.
> >>>
> >>> As for Linux build systems, I would prefer to pick a common basic
> distro version, CentOS or Debian, and instruct users to only use that
> version in a VM for building AstLinux.  This would add a level of
> consistency for the HOST and simplicity for the documentation.  There is no
> extra-credit for making our build system work with any distro.
> >>>
> >>> As for toolchains, it would be ideal to find a supported, trusted,
> x86_64 pre-built toolchain we could use (like a package) with the kernel
> version we decide to use.  Crosstool-NG is also an option, which if we use
> a common build HOST we could possibly create our own x86_64 pre-built
> toolchain which could be downloaded instead of rebuilt for every build
> system install.
> >>>
> >>> Finally, the simultaneous equations that need to be solved are, Kernel
> LTS version where Aufs is actively supported and works with a toolchain we
> like.
> >>>
> >>> Lonnie
> >>>
> >>>
> >>>
> >>>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> >>>>
> >>>> Changed subject to be more relevant to the discussion.
> >>>>
> >>>> I thought more about this and realized that my itch is not really
> that we should use a standard distribution, but that we should be thinking
> about bringing AstLinux more up-to-date and discussing how to go about it.
> Yes the kernel 3.16.x works fine and will do for some time.  But the day
> will come when we must move.  In addition our base system is built from a
> very old version of buildroot, toolchains, libraries, etc. and we run into
> issues as underlying hosts change... mostly simple things like version
> checks failing and we have been able to work around them.  But it is
> getting harder... the most recent one being when I tried the ZFS file
> system on Ubuntu 19.10.
> >>>>
> >>>> Maybe if we changed how we build AstLinux to start from a
> standard/stable version of buildroot (rather than essentially copying all
> of buildroot into our own source tree).  I'm not even sure what I mean by
> that, but I think we should look for a way to stay closer aligned and be
> able to easily update with Buildroot versions.
> >>>>
> >>>> David.
> >>>>
> >>>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <
> mic...@ip...> wrote:
> >>>> After using  OpenWRT for a little while, I decided to abandon its use
> for two reasons, 1) Wifi driver support but also 2) packages. It was so
> difficult to maintain a standard image across all my routers and I never
> knew what package was going to affect what and what would break when I
> upgraded and then how I would revert. Although I hate Mikrotik's UI and
> command structure, I decided to suck it up and move to them because of a
> single firmware image amongst other things.
> >>>>
> >>>> Although I am not that knowledgeable in the area, I believe the
> stability of Astlinux is because of the minimalist approach taken to what
> is included and enabled.
> >>>> I therefore really like the current approach and certainly would not
> want to move to 'a series of entangled package upgrades'.
> >>>>
> >>>> Thanks David for asking these questions as its really important that
> we understand what we are doing and why.
> >>>>
> >>>> Regards
> >>>> Michael Knill
> >>>>
> >>>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >>>>
> >>>>   Hi David, et.al,
> >>>>
> >>>>   Brainstorming ideas are always appreciated.
> >>>>
> >>>>   Though I think our "AstLinux Principles" still apply today, as much
> as ever:
> >>>>
> >>>>   AstLinux Principles:
> >>>>   https://www.astlinux-project.org/about.html
> >>>>
> >>>>   Our current 3.16.x kernel has been getting backported fixes from
> upstream [1] for quite some time by Ben Hutchings ... some would argue that
> the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> >>>>
> >>>>   Correct me if you disagree, but since we use i586/x86_64
> architecture much of the newer kernel hardware support does not apply to
> us.  This is even more true for AstLinux running as VM Guests.
> >>>>
> >>>>   Additionally, a big sticking point upgrading beyond the 3.16.x
> kernel is our current unionfs kernel patches are no longer supported in
> 4.x.  Looks like we will need to switch to Aufs, which we have been giving
> some thought, making it backward compatible is a concern.
> >>>>
> >>>>   Some might argue we should stick with a rock-solid 3.16.x kernel
> for another year or so, others might suggest 4.x (unclear which is best) is
> warranted.  I think 5.x is too new to consider IMO, not enough testing.
> >>>>
> >>>>   Finally, packages vs. firmware-image.  I'm convinced the
> firmware-image approach is ideal for an appliance like AstLinux.  I've
> played with OpenWrt on an EdgeRouter-X, and found the package upgrade
> approach leaves much to be desired compared with a firmware-image approach.
> >>>>
> >>>>   Please discuss ...
> >>>>
> >>>>   Lonnie
> >>>>
> >>>>   [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> >>>>>
> >>>>> Moving to devel list.
> >>>>>
> >>>>> This once again prompts the question as to what to do about AstLinux
> kernel version.  It feels that we are getting further and further behind
> and should maybe even skip 4.x and go straight to a 5.x.
> >>>>>
> >>>>> Or... get out of the business of providing the low level OS
> components and develop on top of a standard "lightweight" distribution.
> When AstLinux started up there was a need for a tight, small, integrated
> system that would work on typical network gateway hardware of the time.
> But today's typical network gateway hardware is very capable of running a
> standard linux distribution.  And if we moved all the AstLinux-unique
> features over to installable packages I think we would benefit greatly.
> >>>>>
> >>>>> Just thought I would throw this out there and see what people think.
> >>>>>
> >>>>> David.
> >>>>>
> >>>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <
> li...@lo...> wrote:
> >>>>> Greetings,
> >>>>>
> >>>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
> >>>>>
> >>>>> My favorite VPN type (as well as many of you reading this) has
> achieved a major milestone.  Additionally, an outside security audit of
> WireGuard has been performed.
> >>>>>
> >>>>> For those previously concerned about the non-official status of
> WireGuard, those concerns should now be minimized.
> >>>>>
> >>>>> Lonnie
> >>>>>
> >>>>>
> >>>>> ================
> >>>>> Begin forwarded message:
> >>>>>
> >>>>> From: "Jason A. Donenfeld" <Ja...@zx...>
> >>>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> >>>>> Date: March 29, 2020 at 9:16:43 PM CDT
> >>>>> To: WireGuard mailing list <wir...@li...>
> >>>>>
> >>>>> Hi folks,
> >>>>>
> >>>>> Earlier this evening, Linus released [1] Linus 5.6, which contains
> our
> >>>>> first release of WireGuard. This is quite exciting. It means that
> >>>>> kernels from here on out will have WireGuard built-in by default. And
> >>>>> for those of you who were scared away prior by the "dOnT uSe tHiS
> >>>>> k0de!!1!" warnings everywhere, you now have something more stable to
> >>>>> work with.
> >>>>>
> >>>>> The last several weeks of 5.6 development and stabilization have been
> >>>>> exciting, with our codebase undergoing a quick security audit [3],
> and
> >>>>> some real headway in terms of getting into distributions.
> >>>>>
> >>>>> We'll also continue to maintain our wireguard-linux-compat [2]
> >>>>> backports repo for older kernels. On the backports front, WireGuard
> >>>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> >>>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also
> maintaining
> >>>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> >>>>> and we'll see where those wind up; 5.4.y is an LTS release.
> >>>>>
> >>>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> >>>>> Fedora 32 will be getting WireGuard automatically by virtue of having
> >>>>> 5.6, and I expect these to increase in number over time.
> >>>>>
> >>>>> Enjoy!
> >>>>> Jason
> >>>>>
> >>>>>
> >>>>> [1]
> https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> >>>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
> >>>>> [3]
> https://lore.kernel.org/netdev/202...@zx.../
> >>>>> [4]
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> >>>>> [5]
> https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> >>>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> >>>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Astlinux-users mailing list
> >>>>> Ast...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >>>>>
> >>>>> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >>>>> _______________________________________________
> >>>>> Astlinux-devel mailing list
> >>>>> Ast...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>>>
> >>>>
> >>>>
> >>>>   _______________________________________________
> >>>>   Astlinux-devel mailing list
> >>>>   Ast...@li...
> >>>>   https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Astlinux-devel mailing list
> >>>> Ast...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>>> _______________________________________________
> >>>> Astlinux-devel mailing list
> >>>> Ast...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Astlinux-devel mailing list
> >>> Ast...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >
> >
> >
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> > _______________________________________________
> > Astlinux-devel mailing list
> > Ast...@li...
> > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

Re: [Astlinux-devel] Astlinux base system

[Lonnie A. <li...@lo...>]

Hi David, (inline comments)

> On Apr 6, 2020, at 2:57 PM, David Kerr <Da...@Ke...> wrote:
> 
> Kernel 4.19 has been selected by the linux foundation for Super LTS which means that it should have some support structure for many many years.

That is great news, but where did you see that announcement ?

This has not been updated yet:
https://www.kernel.org/category/releases.html


> I'll back off my previous proposal to adopt an off-the-shelf underlying platform... the points about piecemeal package updates potentially causing stability issues is valid.
> 
> I'll add one more potentially controversial suggestion... in addition to x86_64 how about ARM64 as well?

ARM64 is a whole different critter, no PCI bus to make things interconnect in a standard way, but as I understand it, things need to be tweaked for each specific board with ARM.


> For the build system/tools I think we should update to the current buildroot.  While we have been keeping individual package versions up-to-date, we have not been keeping the build system up-to-date (crosstools, config files, etc.)

We should definitely upgrade crosstool-NG, but starting over with the latest Buildroot is non-trivial and error prone.


> And it is this that is causing problems when underlying build hosts are updated.  And I am NOT in favor of mandating and/or supporting only one host OS for the build system, be it CentOS, Ubuntu, whatever.

Can you explain why you are not in favor of a "standard" build host ?  I would expect everyone would use a VM these days, the build host choice seems moot.


BTW, I have been playing with Debian 10 within VMware Fusion.  This seems like a good choice. (640MB download)

https://cdimage.debian.org/debian-cd/10.3.0/amd64/iso-cd/debian-10.3.0-amd64-xfce-CD-1.iso

I'm playing with crosstool-NG 1.24.0 ... my first try was:
--
gcc: 8.3.0
glibc: 2.28
binutils 2.31.1
--
That caused weird problems building udev (albeit udev is somewhat old)

I'm now trying a more compatible toolchain choice:
--
gcc: 6.4.0
glibc: 2.26
binutils 2.29.1
--

A point of reference, the latest Synology DSM 6.2.2 is:
--
gcc: 4.9.3
glibc: 2.20

Linux: 3.10.105
--


Lonnie



> 
> David.
> 
> 
> 
> On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <li...@lo...> wrote:
> Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully Ben Hutchings, but unknown as of yet.
> 
> Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
> 
> Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two before that kernel is tested enough for production.
> 
> CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project ... until 2029 !
> 
> Lonnie
> 
> 
> 
>> On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...> wrote:
>> 
>> Only the latest 4.x + 5 kernels are supported.
>> So 4.14 is out.
>> 
>> http://aufs.sourceforge.net/
>> 
>> Sent from a mobile device.
>> 
>> Michael Keuter
>> 
>> Anfang der weitergeleiteten Nachricht:
>> 
>>> Von: Lonnie Abelbeck <li...@lo...>
>>> Datum: 2. April 2020 um 17:40:23 MESZ
>>> An: AstLinux Developers Mailing List <ast...@li...>
>>> Betreff: Aw:  [Astlinux-devel] Astlinux base system
>>> Antwort an: AstLinux Developers Mailing List <ast...@li...>
>>> 
>>> My short list for AstLinux 1.4.x would be:
>>> 
>>> - Kernel bump to 4.x
>>> - Switch from unionfs to Aufs
>>> - Support x86_64 only
>>> - Update the toolchain using a newer gcc and glibc
>>> - RUNNIX runnix-0.6.0 would be x86_64 only
>>> 
>>> As for Buildroot, our version is quite up to date for x86_64 and the packages we use.  We have packages and fixes that are not upstream.
>>> 
>>> As for Linux build systems, I would prefer to pick a common basic distro version, CentOS or Debian, and instruct users to only use that version in a VM for building AstLinux.  This would add a level of consistency for the HOST and simplicity for the documentation.  There is no extra-credit for making our build system work with any distro.
>>> 
>>> As for toolchains, it would be ideal to find a supported, trusted, x86_64 pre-built toolchain we could use (like a package) with the kernel version we decide to use.  Crosstool-NG is also an option, which if we use a common build HOST we could possibly create our own x86_64 pre-built toolchain which could be downloaded instead of rebuilt for every build system install.
>>> 
>>> Finally, the simultaneous equations that need to be solved are, Kernel LTS version where Aufs is actively supported and works with a toolchain we like.
>>> 
>>> Lonnie
>>> 
>>> 
>>> 
>>>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
>>>> 
>>>> Changed subject to be more relevant to the discussion.
>>>> 
>>>> I thought more about this and realized that my itch is not really that we should use a standard distribution, but that we should be thinking about bringing AstLinux more up-to-date and discussing how to go about it.  Yes the kernel 3.16.x works fine and will do for some time.  But the day will come when we must move.  In addition our base system is built from a very old version of buildroot, toolchains, libraries, etc. and we run into issues as underlying hosts change... mostly simple things like version checks failing and we have been able to work around them.  But it is getting harder... the most recent one being when I tried the ZFS file system on Ubuntu 19.10.
>>>> 
>>>> Maybe if we changed how we build AstLinux to start from a standard/stable version of buildroot (rather than essentially copying all of buildroot into our own source tree).  I'm not even sure what I mean by that, but I think we should look for a way to stay closer aligned and be able to easily update with Buildroot versions.
>>>> 
>>>> David.
>>>> 
>>>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <mic...@ip...> wrote:
>>>> After using  OpenWRT for a little while, I decided to abandon its use for two reasons, 1) Wifi driver support but also 2) packages. It was so difficult to maintain a standard image across all my routers and I never knew what package was going to affect what and what would break when I upgraded and then how I would revert. Although I hate Mikrotik's UI and command structure, I decided to suck it up and move to them because of a single firmware image amongst other things.
>>>> 
>>>> Although I am not that knowledgeable in the area, I believe the stability of Astlinux is because of the minimalist approach taken to what is included and enabled. 
>>>> I therefore really like the current approach and certainly would not want to move to 'a series of entangled package upgrades'.
>>>> 
>>>> Thanks David for asking these questions as its really important that we understand what we are doing and why. 
>>>> 
>>>> Regards
>>>> Michael Knill
>>>> 
>>>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>>> 
>>>>   Hi David, et.al,
>>>> 
>>>>   Brainstorming ideas are always appreciated.
>>>> 
>>>>   Though I think our "AstLinux Principles" still apply today, as much as ever:
>>>> 
>>>>   AstLinux Principles:
>>>>   https://www.astlinux-project.org/about.html
>>>> 
>>>>   Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
>>>> 
>>>>   Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.
>>>> 
>>>>   Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.
>>>> 
>>>>   Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.
>>>> 
>>>>   Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.
>>>> 
>>>>   Please discuss ...
>>>> 
>>>>   Lonnie
>>>> 
>>>>   [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
>>>>> 
>>>>> Moving to devel list.
>>>>> 
>>>>> This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
>>>>> 
>>>>> Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
>>>>> 
>>>>> Just thought I would throw this out there and see what people think.
>>>>> 
>>>>> David.
>>>>> 
>>>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
>>>>> Greetings,
>>>>> 
>>>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
>>>>> 
>>>>> My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
>>>>> 
>>>>> For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
>>>>> 
>>>>> Lonnie
>>>>> 
>>>>> 
>>>>> ================
>>>>> Begin forwarded message:
>>>>> 
>>>>> From: "Jason A. Donenfeld" <Ja...@zx...>
>>>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
>>>>> Date: March 29, 2020 at 9:16:43 PM CDT
>>>>> To: WireGuard mailing list <wir...@li...>
>>>>> 
>>>>> Hi folks,
>>>>> 
>>>>> Earlier this evening, Linus released [1] Linus 5.6, which contains our
>>>>> first release of WireGuard. This is quite exciting. It means that
>>>>> kernels from here on out will have WireGuard built-in by default. And
>>>>> for those of you who were scared away prior by the "dOnT uSe tHiS
>>>>> k0de!!1!" warnings everywhere, you now have something more stable to
>>>>> work with.
>>>>> 
>>>>> The last several weeks of 5.6 development and stabilization have been
>>>>> exciting, with our codebase undergoing a quick security audit [3], and
>>>>> some real headway in terms of getting into distributions.
>>>>> 
>>>>> We'll also continue to maintain our wireguard-linux-compat [2]
>>>>> backports repo for older kernels. On the backports front, WireGuard
>>>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
>>>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
>>>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
>>>>> and we'll see where those wind up; 5.4.y is an LTS release.
>>>>> 
>>>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
>>>>> Fedora 32 will be getting WireGuard automatically by virtue of having
>>>>> 5.6, and I expect these to increase in number over time.
>>>>> 
>>>>> Enjoy!
>>>>> Jason
>>>>> 
>>>>> 
>>>>> [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
>>>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
>>>>> [3] https://lore.kernel.org/netdev/202...@zx.../
>>>>> [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
>>>>> [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
>>>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
>>>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Astlinux-users mailing list
>>>>> Ast...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>>> 
>>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>>> _______________________________________________
>>>>> Astlinux-devel mailing list
>>>>> Ast...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>> 
>>>> 
>>>> 
>>>>   _______________________________________________
>>>>   Astlinux-devel mailing list
>>>>   Ast...@li...
>>>>   https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Astlinux base system

[David K. <da...@ke...>]

Kernel 4.19 has been selected by the linux foundation for Super LTS which
means that it should have some support structure for many many years.  I'll
back off my previous proposal to adopt an off-the-shelf underlying
platform... the points about piecemeal package updates potentially causing
stability issues is valid.

I'll add one more potentially controversial suggestion... in addition to
x86_64 how about ARM64 as well?

For the build system/tools I think we should update to the current
buildroot.  While we have been keeping individual package versions
up-to-date, we have not been keeping the build system up-to-date
(crosstools, config files, etc.)  And it is this that is causing problems
when underlying build hosts are updated.  And I am NOT in favor of
mandating and/or supporting only one host OS for the build system, be it
CentOS, Ubuntu, whatever.

David.



On Thu, Apr 2, 2020 at 2:16 PM Lonnie Abelbeck <li...@lo...>
wrote:

> Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully
> Ben Hutchings, but unknown as of yet.
>
> Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.
>
> Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two
> before that kernel is tested enough for production.
>
> CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project
> ... until 2029 !
>
> Lonnie
>
>
>
> > On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...>
> wrote:
> >
> > Only the latest 4.x + 5 kernels are supported.
> > So 4.14 is out.
> >
> > http://aufs.sourceforge.net/
> >
> > Sent from a mobile device.
> >
> > Michael Keuter
> >
> > Anfang der weitergeleiteten Nachricht:
> >
> >> Von: Lonnie Abelbeck <li...@lo...>
> >> Datum: 2. April 2020 um 17:40:23 MESZ
> >> An: AstLinux Developers Mailing List <
> ast...@li...>
> >> Betreff: Aw:  [Astlinux-devel] Astlinux base system
> >> Antwort an: AstLinux Developers Mailing List <
> ast...@li...>
> >>
> >> My short list for AstLinux 1.4.x would be:
> >>
> >> - Kernel bump to 4.x
> >> - Switch from unionfs to Aufs
> >> - Support x86_64 only
> >> - Update the toolchain using a newer gcc and glibc
> >> - RUNNIX runnix-0.6.0 would be x86_64 only
> >>
> >> As for Buildroot, our version is quite up to date for x86_64 and the
> packages we use.  We have packages and fixes that are not upstream.
> >>
> >> As for Linux build systems, I would prefer to pick a common basic
> distro version, CentOS or Debian, and instruct users to only use that
> version in a VM for building AstLinux.  This would add a level of
> consistency for the HOST and simplicity for the documentation.  There is no
> extra-credit for making our build system work with any distro.
> >>
> >> As for toolchains, it would be ideal to find a supported, trusted,
> x86_64 pre-built toolchain we could use (like a package) with the kernel
> version we decide to use.  Crosstool-NG is also an option, which if we use
> a common build HOST we could possibly create our own x86_64 pre-built
> toolchain which could be downloaded instead of rebuilt for every build
> system install.
> >>
> >> Finally, the simultaneous equations that need to be solved are, Kernel
> LTS version where Aufs is actively supported and works with a toolchain we
> like.
> >>
> >> Lonnie
> >>
> >>
> >>
> >>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> >>>
> >>> Changed subject to be more relevant to the discussion.
> >>>
> >>> I thought more about this and realized that my itch is not really that
> we should use a standard distribution, but that we should be thinking about
> bringing AstLinux more up-to-date and discussing how to go about it.  Yes
> the kernel 3.16.x works fine and will do for some time.  But the day will
> come when we must move.  In addition our base system is built from a very
> old version of buildroot, toolchains, libraries, etc. and we run into
> issues as underlying hosts change... mostly simple things like version
> checks failing and we have been able to work around them.  But it is
> getting harder... the most recent one being when I tried the ZFS file
> system on Ubuntu 19.10.
> >>>
> >>> Maybe if we changed how we build AstLinux to start from a
> standard/stable version of buildroot (rather than essentially copying all
> of buildroot into our own source tree).  I'm not even sure what I mean by
> that, but I think we should look for a way to stay closer aligned and be
> able to easily update with Buildroot versions.
> >>>
> >>> David.
> >>>
> >>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <
> mic...@ip...> wrote:
> >>> After using  OpenWRT for a little while, I decided to abandon its use
> for two reasons, 1) Wifi driver support but also 2) packages. It was so
> difficult to maintain a standard image across all my routers and I never
> knew what package was going to affect what and what would break when I
> upgraded and then how I would revert. Although I hate Mikrotik's UI and
> command structure, I decided to suck it up and move to them because of a
> single firmware image amongst other things.
> >>>
> >>> Although I am not that knowledgeable in the area, I believe the
> stability of Astlinux is because of the minimalist approach taken to what
> is included and enabled.
> >>> I therefore really like the current approach and certainly would not
> want to move to 'a series of entangled package upgrades'.
> >>>
> >>> Thanks David for asking these questions as its really important that
> we understand what we are doing and why.
> >>>
> >>> Regards
> >>> Michael Knill
> >>>
> >>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...>
> wrote:
> >>>
> >>>    Hi David, et.al,
> >>>
> >>>    Brainstorming ideas are always appreciated.
> >>>
> >>>    Though I think our "AstLinux Principles" still apply today, as much
> as ever:
> >>>
> >>>    AstLinux Principles:
> >>>    https://www.astlinux-project.org/about.html
> >>>
> >>>    Our current 3.16.x kernel has been getting backported fixes from
> upstream [1] for quite some time by Ben Hutchings ... some would argue that
> the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> >>>
> >>>    Correct me if you disagree, but since we use i586/x86_64
> architecture much of the newer kernel hardware support does not apply to
> us.  This is even more true for AstLinux running as VM Guests.
> >>>
> >>>    Additionally, a big sticking point upgrading beyond the 3.16.x
> kernel is our current unionfs kernel patches are no longer supported in
> 4.x.  Looks like we will need to switch to Aufs, which we have been giving
> some thought, making it backward compatible is a concern.
> >>>
> >>>    Some might argue we should stick with a rock-solid 3.16.x kernel
> for another year or so, others might suggest 4.x (unclear which is best) is
> warranted.  I think 5.x is too new to consider IMO, not enough testing.
> >>>
> >>>    Finally, packages vs. firmware-image.  I'm convinced the
> firmware-image approach is ideal for an appliance like AstLinux.  I've
> played with OpenWrt on an EdgeRouter-X, and found the package upgrade
> approach leaves much to be desired compared with a firmware-image approach.
> >>>
> >>>    Please discuss ...
> >>>
> >>>    Lonnie
> >>>
> >>>    [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> >>>
> >>>
> >>>
> >>>
> >>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> >>>>
> >>>> Moving to devel list.
> >>>>
> >>>> This once again prompts the question as to what to do about AstLinux
> kernel version.  It feels that we are getting further and further behind
> and should maybe even skip 4.x and go straight to a 5.x.
> >>>>
> >>>> Or... get out of the business of providing the low level OS
> components and develop on top of a standard "lightweight" distribution.
> When AstLinux started up there was a need for a tight, small, integrated
> system that would work on typical network gateway hardware of the time.
> But today's typical network gateway hardware is very capable of running a
> standard linux distribution.  And if we moved all the AstLinux-unique
> features over to installable packages I think we would benefit greatly.
> >>>>
> >>>> Just thought I would throw this out there and see what people think.
> >>>>
> >>>> David.
> >>>>
> >>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <
> li...@lo...> wrote:
> >>>> Greetings,
> >>>>
> >>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
> >>>>
> >>>> My favorite VPN type (as well as many of you reading this) has
> achieved a major milestone.  Additionally, an outside security audit of
> WireGuard has been performed.
> >>>>
> >>>> For those previously concerned about the non-official status of
> WireGuard, those concerns should now be minimized.
> >>>>
> >>>> Lonnie
> >>>>
> >>>>
> >>>> ================
> >>>> Begin forwarded message:
> >>>>
> >>>> From: "Jason A. Donenfeld" <Ja...@zx...>
> >>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> >>>> Date: March 29, 2020 at 9:16:43 PM CDT
> >>>> To: WireGuard mailing list <wir...@li...>
> >>>>
> >>>> Hi folks,
> >>>>
> >>>> Earlier this evening, Linus released [1] Linus 5.6, which contains our
> >>>> first release of WireGuard. This is quite exciting. It means that
> >>>> kernels from here on out will have WireGuard built-in by default. And
> >>>> for those of you who were scared away prior by the "dOnT uSe tHiS
> >>>> k0de!!1!" warnings everywhere, you now have something more stable to
> >>>> work with.
> >>>>
> >>>> The last several weeks of 5.6 development and stabilization have been
> >>>> exciting, with our codebase undergoing a quick security audit [3], and
> >>>> some real headway in terms of getting into distributions.
> >>>>
> >>>> We'll also continue to maintain our wireguard-linux-compat [2]
> >>>> backports repo for older kernels. On the backports front, WireGuard
> >>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> >>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
> >>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> >>>> and we'll see where those wind up; 5.4.y is an LTS release.
> >>>>
> >>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> >>>> Fedora 32 will be getting WireGuard automatically by virtue of having
> >>>> 5.6, and I expect these to increase in number over time.
> >>>>
> >>>> Enjoy!
> >>>> Jason
> >>>>
> >>>>
> >>>> [1]
> https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> >>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
> >>>> [3]
> https://lore.kernel.org/netdev/202...@zx.../
> >>>> [4]
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> >>>> [5]
> https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> >>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> >>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Astlinux-users mailing list
> >>>> Ast...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >>>>
> >>>> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
> >>>> _______________________________________________
> >>>> Astlinux-devel mailing list
> >>>> Ast...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>>
> >>>
> >>>
> >>>    _______________________________________________
> >>>    Astlinux-devel mailing list
> >>>    Ast...@li...
> >>>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Astlinux-devel mailing list
> >>> Ast...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>> _______________________________________________
> >>> Astlinux-devel mailing list
> >>> Ast...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> >>
> >>
> >>
> >> _______________________________________________
> >> Astlinux-devel mailing list
> >> Ast...@li...
> >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

[Astlinux-devel] Announcing AstLinux Release: 1.3.8

[Lonnie A. <li...@lo...>]

Announcing AstLinux Release: 1.3.8

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.3.8 Highlights:
* Asterisk Versions: 13.23.1, 13.31.0, 16.8.0
* Upgrade to Linux Kernel 3.16.82, including the RUNNIX bootloader, security and bug fixes
* OpenSSL, version bump to 1.1.1f
* pppd, version bump to 2.4.8, security fix: CVE-2020-8597
* WireGuard VPN, first official release 1.0.20200330, backport of its incorporation into the Linux Kernel 5.6
* OpenVPN, version bump to 2.4.8
* chrony, version bump to 4.0-pre1, adds 'maxsamples 1' and 'chronyc -N sources' support
* acme-client, version bump to 2.8.5
* arp-scan, version bump to 1.9.7, fixed with libpcap version 1.9.1
* ncurses, version bump to 6.2
* ne, version bump to 3.3.0
* Asterisk '13se' (stable edition) version 13.23.1 is older than latest Asterisk 13.x version but more tested, built --without-pjproject
* Package upgrades providing important security and bug fixes

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.8/docs/ChangeLog.txt

All users are encouraged to upgrade.

Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal.

AstLinux Team

Re: [Astlinux-devel] Astlinux base system

[Lonnie A. <li...@lo...>]

Yes, but Kernel 4.19.x does not yet have a LTS maintainer ... hopefully Ben Hutchings, but unknown as of yet.

Debian 10 uses Kernel 4.19.x and has a LTS 2024 date.

Debian 11 will use Kernel 5.4.x, but we would need to wait a year or two before that kernel is tested enough for production.

CentOS 8 uses 4.18.x, which is maintained within the RHEL/CentOS project ... until 2029 !

Lonnie



> On Apr 2, 2020, at 12:01 PM, Michael Keuter <li...@mk...> wrote:
> 
> Only the latest 4.x + 5 kernels are supported.
> So 4.14 is out.
> 
> http://aufs.sourceforge.net/
> 
> Sent from a mobile device.
> 
> Michael Keuter
> 
> Anfang der weitergeleiteten Nachricht:
> 
>> Von: Lonnie Abelbeck <li...@lo...>
>> Datum: 2. April 2020 um 17:40:23 MESZ
>> An: AstLinux Developers Mailing List <ast...@li...>
>> Betreff: Aw:  [Astlinux-devel] Astlinux base system
>> Antwort an: AstLinux Developers Mailing List <ast...@li...>
>> 
>> My short list for AstLinux 1.4.x would be:
>> 
>> - Kernel bump to 4.x
>> - Switch from unionfs to Aufs
>> - Support x86_64 only
>> - Update the toolchain using a newer gcc and glibc
>> - RUNNIX runnix-0.6.0 would be x86_64 only
>> 
>> As for Buildroot, our version is quite up to date for x86_64 and the packages we use.  We have packages and fixes that are not upstream.
>> 
>> As for Linux build systems, I would prefer to pick a common basic distro version, CentOS or Debian, and instruct users to only use that version in a VM for building AstLinux.  This would add a level of consistency for the HOST and simplicity for the documentation.  There is no extra-credit for making our build system work with any distro.
>> 
>> As for toolchains, it would be ideal to find a supported, trusted, x86_64 pre-built toolchain we could use (like a package) with the kernel version we decide to use.  Crosstool-NG is also an option, which if we use a common build HOST we could possibly create our own x86_64 pre-built toolchain which could be downloaded instead of rebuilt for every build system install.
>> 
>> Finally, the simultaneous equations that need to be solved are, Kernel LTS version where Aufs is actively supported and works with a toolchain we like.
>> 
>> Lonnie
>> 
>> 
>> 
>>> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
>>> 
>>> Changed subject to be more relevant to the discussion.
>>> 
>>> I thought more about this and realized that my itch is not really that we should use a standard distribution, but that we should be thinking about bringing AstLinux more up-to-date and discussing how to go about it.  Yes the kernel 3.16.x works fine and will do for some time.  But the day will come when we must move.  In addition our base system is built from a very old version of buildroot, toolchains, libraries, etc. and we run into issues as underlying hosts change... mostly simple things like version checks failing and we have been able to work around them.  But it is getting harder... the most recent one being when I tried the ZFS file system on Ubuntu 19.10.
>>> 
>>> Maybe if we changed how we build AstLinux to start from a standard/stable version of buildroot (rather than essentially copying all of buildroot into our own source tree).  I'm not even sure what I mean by that, but I think we should look for a way to stay closer aligned and be able to easily update with Buildroot versions.
>>> 
>>> David.
>>> 
>>> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <mic...@ip...> wrote:
>>> After using  OpenWRT for a little while, I decided to abandon its use for two reasons, 1) Wifi driver support but also 2) packages. It was so difficult to maintain a standard image across all my routers and I never knew what package was going to affect what and what would break when I upgraded and then how I would revert. Although I hate Mikrotik's UI and command structure, I decided to suck it up and move to them because of a single firmware image amongst other things.
>>> 
>>> Although I am not that knowledgeable in the area, I believe the stability of Astlinux is because of the minimalist approach taken to what is included and enabled. 
>>> I therefore really like the current approach and certainly would not want to move to 'a series of entangled package upgrades'.
>>> 
>>> Thanks David for asking these questions as its really important that we understand what we are doing and why. 
>>> 
>>> Regards
>>> Michael Knill
>>> 
>>> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>>> 
>>>    Hi David, et.al,
>>> 
>>>    Brainstorming ideas are always appreciated.
>>> 
>>>    Though I think our "AstLinux Principles" still apply today, as much as ever:
>>> 
>>>    AstLinux Principles:
>>>    https://www.astlinux-project.org/about.html
>>> 
>>>    Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
>>> 
>>>    Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.
>>> 
>>>    Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.
>>> 
>>>    Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.
>>> 
>>>    Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.
>>> 
>>>    Please discuss ...
>>> 
>>>    Lonnie
>>> 
>>>    [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
>>> 
>>> 
>>> 
>>> 
>>>> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
>>>> 
>>>> Moving to devel list.
>>>> 
>>>> This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
>>>> 
>>>> Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
>>>> 
>>>> Just thought I would throw this out there and see what people think.
>>>> 
>>>> David.
>>>> 
>>>> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
>>>> Greetings,
>>>> 
>>>> FYI, I forwarded (below) a note from the WireGuard mailing list.
>>>> 
>>>> My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
>>>> 
>>>> For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
>>>> 
>>>> Lonnie
>>>> 
>>>> 
>>>> ================
>>>> Begin forwarded message:
>>>> 
>>>> From: "Jason A. Donenfeld" <Ja...@zx...>
>>>> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
>>>> Date: March 29, 2020 at 9:16:43 PM CDT
>>>> To: WireGuard mailing list <wir...@li...>
>>>> 
>>>> Hi folks,
>>>> 
>>>> Earlier this evening, Linus released [1] Linus 5.6, which contains our
>>>> first release of WireGuard. This is quite exciting. It means that
>>>> kernels from here on out will have WireGuard built-in by default. And
>>>> for those of you who were scared away prior by the "dOnT uSe tHiS
>>>> k0de!!1!" warnings everywhere, you now have something more stable to
>>>> work with.
>>>> 
>>>> The last several weeks of 5.6 development and stabilization have been
>>>> exciting, with our codebase undergoing a quick security audit [3], and
>>>> some real headway in terms of getting into distributions.
>>>> 
>>>> We'll also continue to maintain our wireguard-linux-compat [2]
>>>> backports repo for older kernels. On the backports front, WireGuard
>>>> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
>>>> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
>>>> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
>>>> and we'll see where those wind up; 5.4.y is an LTS release.
>>>> 
>>>> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
>>>> Fedora 32 will be getting WireGuard automatically by virtue of having
>>>> 5.6, and I expect these to increase in number over time.
>>>> 
>>>> Enjoy!
>>>> Jason
>>>> 
>>>> 
>>>> [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
>>>> [2] https://git.zx2c4.com/wireguard-linux-compat/
>>>> [3] https://lore.kernel.org/netdev/202...@zx.../
>>>> [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
>>>> [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
>>>> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
>>>> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Astlinux-users mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>>>> 
>>>> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>>>> _______________________________________________
>>>> Astlinux-devel mailing list
>>>> Ast...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> 
>>> 
>>> 
>>>    _______________________________________________
>>>    Astlinux-devel mailing list
>>>    Ast...@li...
>>>    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>>> _______________________________________________
>>> Astlinux-devel mailing list
>>> Ast...@li...
>>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>> 
>> 
>> 
>> _______________________________________________
>> Astlinux-devel mailing list
>> Ast...@li...
>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Astlinux base system

[Lonnie A. <li...@lo...>]

My short list for AstLinux 1.4.x would be:

- Kernel bump to 4.x
- Switch from unionfs to Aufs
- Support x86_64 only
- Update the toolchain using a newer gcc and glibc
- RUNNIX runnix-0.6.0 would be x86_64 only

As for Buildroot, our version is quite up to date for x86_64 and the packages we use.  We have packages and fixes that are not upstream.

As for Linux build systems, I would prefer to pick a common basic distro version, CentOS or Debian, and instruct users to only use that version in a VM for building AstLinux.  This would add a level of consistency for the HOST and simplicity for the documentation.  There is no extra-credit for making our build system work with any distro.

As for toolchains, it would be ideal to find a supported, trusted, x86_64 pre-built toolchain we could use (like a package) with the kernel version we decide to use.  Crosstool-NG is also an option, which if we use a common build HOST we could possibly create our own x86_64 pre-built toolchain which could be downloaded instead of rebuilt for every build system install.

Finally, the simultaneous equations that need to be solved are, Kernel LTS version where Aufs is actively supported and works with a toolchain we like.

Lonnie



> On Apr 2, 2020, at 8:46 AM, David Kerr <Da...@Ke...> wrote:
> 
> Changed subject to be more relevant to the discussion.
> 
> I thought more about this and realized that my itch is not really that we should use a standard distribution, but that we should be thinking about bringing AstLinux more up-to-date and discussing how to go about it.  Yes the kernel 3.16.x works fine and will do for some time.  But the day will come when we must move.  In addition our base system is built from a very old version of buildroot, toolchains, libraries, etc. and we run into issues as underlying hosts change... mostly simple things like version checks failing and we have been able to work around them.  But it is getting harder... the most recent one being when I tried the ZFS file system on Ubuntu 19.10.
> 
> Maybe if we changed how we build AstLinux to start from a standard/stable version of buildroot (rather than essentially copying all of buildroot into our own source tree).  I'm not even sure what I mean by that, but I think we should look for a way to stay closer aligned and be able to easily update with Buildroot versions.
> 
> David.
> 
> On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <mic...@ip...> wrote:
> After using  OpenWRT for a little while, I decided to abandon its use for two reasons, 1) Wifi driver support but also 2) packages. It was so difficult to maintain a standard image across all my routers and I never knew what package was going to affect what and what would break when I upgraded and then how I would revert. Although I hate Mikrotik's UI and command structure, I decided to suck it up and move to them because of a single firmware image amongst other things.
> 
> Although I am not that knowledgeable in the area, I believe the stability of Astlinux is because of the minimalist approach taken to what is included and enabled. 
> I therefore really like the current approach and certainly would not want to move to 'a series of entangled package upgrades'.
> 
> Thanks David for asking these questions as its really important that we understand what we are doing and why. 
> 
> Regards
> Michael Knill
> 
> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
> 
>     Hi David, et.al,
> 
>     Brainstorming ideas are always appreciated.
> 
>     Though I think our "AstLinux Principles" still apply today, as much as ever:
> 
>     AstLinux Principles:
>     https://www.astlinux-project.org/about.html
> 
>     Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
> 
>     Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.
> 
>     Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.
> 
>     Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.
> 
>     Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.
> 
>     Please discuss ...
> 
>     Lonnie
> 
>     [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
> 
> 
> 
> 
>     > On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
>     > 
>     > Moving to devel list.
>     > 
>     > This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
>     > 
>     > Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
>     > 
>     > Just thought I would throw this out there and see what people think.
>     > 
>     > David.
>     > 
>     > On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
>     > Greetings,
>     > 
>     > FYI, I forwarded (below) a note from the WireGuard mailing list.
>     > 
>     > My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
>     > 
>     > For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
>     > 
>     > Lonnie
>     > 
>     > 
>     > ================
>     > Begin forwarded message:
>     > 
>     > From: "Jason A. Donenfeld" <Ja...@zx...>
>     > Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
>     > Date: March 29, 2020 at 9:16:43 PM CDT
>     > To: WireGuard mailing list <wir...@li...>
>     > 
>     > Hi folks,
>     > 
>     > Earlier this evening, Linus released [1] Linus 5.6, which contains our
>     > first release of WireGuard. This is quite exciting. It means that
>     > kernels from here on out will have WireGuard built-in by default. And
>     > for those of you who were scared away prior by the "dOnT uSe tHiS
>     > k0de!!1!" warnings everywhere, you now have something more stable to
>     > work with.
>     > 
>     > The last several weeks of 5.6 development and stabilization have been
>     > exciting, with our codebase undergoing a quick security audit [3], and
>     > some real headway in terms of getting into distributions.
>     > 
>     > We'll also continue to maintain our wireguard-linux-compat [2]
>     > backports repo for older kernels. On the backports front, WireGuard
>     > was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
>     > Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
>     > real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
>     > and we'll see where those wind up; 5.4.y is an LTS release.
>     > 
>     > Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
>     > Fedora 32 will be getting WireGuard automatically by virtue of having
>     > 5.6, and I expect these to increase in number over time.
>     > 
>     > Enjoy!
>     > Jason
>     > 
>     > 
>     > [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
>     > [2] https://git.zx2c4.com/wireguard-linux-compat/
>     > [3] https://lore.kernel.org/netdev/202...@zx.../
>     > [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
>     > [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
>     > [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
>     > [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
>     > 
>     > 
>     > _______________________________________________
>     > Astlinux-users mailing list
>     > Ast...@li...
>     > https://lists.sourceforge.net/lists/listinfo/astlinux-users
>     > 
>     > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
>     > _______________________________________________
>     > Astlinux-devel mailing list
>     > Ast...@li...
>     > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
>     _______________________________________________
>     Astlinux-devel mailing list
>     Ast...@li...
>     https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> 
> 
> 
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] Astlinux base system

[David K. <da...@ke...>]

Changed subject to be more relevant to the discussion.

I thought more about this and realized that my itch is not really that we
should use a standard distribution, but that we should be thinking about
bringing AstLinux more up-to-date and discussing how to go about it.  Yes
the kernel 3.16.x works fine and will do for some time.  But the day will
come when we must move.  In addition our base system is built from a very
old version of buildroot, toolchains, libraries, etc. and we run into
issues as underlying hosts change... mostly simple things like version
checks failing and we have been able to work around them.  But it is
getting harder... the most recent one being when I tried the ZFS file
system on Ubuntu 19.10.

Maybe if we changed how we build AstLinux to start from a standard/stable
version of buildroot (rather than essentially copying all of buildroot into
our own source tree).  I'm not even sure what I mean by that, but I think
we should look for a way to stay closer aligned and be able to easily
update with Buildroot versions.

David.

On Mon, Mar 30, 2020 at 4:23 PM Michael Knill <
mic...@ip...> wrote:

> After using  OpenWRT for a little while, I decided to abandon its use for
> two reasons, 1) Wifi driver support but also 2) packages. It was so
> difficult to maintain a standard image across all my routers and I never
> knew what package was going to affect what and what would break when I
> upgraded and then how I would revert. Although I hate Mikrotik's UI and
> command structure, I decided to suck it up and move to them because of a
> single firmware image amongst other things.
>
> Although I am not that knowledgeable in the area, I believe the stability
> of Astlinux is because of the minimalist approach taken to what is included
> and enabled.
> I therefore really like the current approach and certainly would not want
> to move to 'a series of entangled package upgrades'.
>
> Thanks David for asking these questions as its really important that we
> understand what we are doing and why.
>
> Regards
> Michael Knill
>
> On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:
>
>     Hi David, et.al,
>
>     Brainstorming ideas are always appreciated.
>
>     Though I think our "AstLinux Principles" still apply today, as much as
> ever:
>
>     AstLinux Principles:
>     https://www.astlinux-project.org/about.html
>
>     Our current 3.16.x kernel has been getting backported fixes from
> upstream [1] for quite some time by Ben Hutchings ... some would argue that
> the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
>
>     Correct me if you disagree, but since we use i586/x86_64 architecture
> much of the newer kernel hardware support does not apply to us.  This is
> even more true for AstLinux running as VM Guests.
>
>     Additionally, a big sticking point upgrading beyond the 3.16.x kernel
> is our current unionfs kernel patches are no longer supported in 4.x.
> Looks like we will need to switch to Aufs, which we have been giving some
> thought, making it backward compatible is a concern.
>
>     Some might argue we should stick with a rock-solid 3.16.x kernel for
> another year or so, others might suggest 4.x (unclear which is best) is
> warranted.  I think 5.x is too new to consider IMO, not enough testing.
>
>     Finally, packages vs. firmware-image.  I'm convinced the
> firmware-image approach is ideal for an appliance like AstLinux.  I've
> played with OpenWrt on an EdgeRouter-X, and found the package upgrade
> approach leaves much to be desired compared with a firmware-image approach.
>
>     Please discuss ...
>
>     Lonnie
>
>     [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
>
>
>
>
>     > On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
>     >
>     > Moving to devel list.
>     >
>     > This once again prompts the question as to what to do about AstLinux
> kernel version.  It feels that we are getting further and further behind
> and should maybe even skip 4.x and go straight to a 5.x.
>     >
>     > Or... get out of the business of providing the low level OS
> components and develop on top of a standard "lightweight" distribution.
> When AstLinux started up there was a need for a tight, small, integrated
> system that would work on typical network gateway hardware of the time.
> But today's typical network gateway hardware is very capable of running a
> standard linux distribution.  And if we moved all the AstLinux-unique
> features over to installable packages I think we would benefit greatly.
>     >
>     > Just thought I would throw this out there and see what people think.
>     >
>     > David.
>     >
>     > On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <
> li...@lo...> wrote:
>     > Greetings,
>     >
>     > FYI, I forwarded (below) a note from the WireGuard mailing list.
>     >
>     > My favorite VPN type (as well as many of you reading this) has
> achieved a major milestone.  Additionally, an outside security audit of
> WireGuard has been performed.
>     >
>     > For those previously concerned about the non-official status of
> WireGuard, those concerns should now be minimized.
>     >
>     > Lonnie
>     >
>     >
>     > ================
>     > Begin forwarded message:
>     >
>     > From: "Jason A. Donenfeld" <Ja...@zx...>
>     > Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
>     > Date: March 29, 2020 at 9:16:43 PM CDT
>     > To: WireGuard mailing list <wir...@li...>
>     >
>     > Hi folks,
>     >
>     > Earlier this evening, Linus released [1] Linus 5.6, which contains
> our
>     > first release of WireGuard. This is quite exciting. It means that
>     > kernels from here on out will have WireGuard built-in by default. And
>     > for those of you who were scared away prior by the "dOnT uSe tHiS
>     > k0de!!1!" warnings everywhere, you now have something more stable to
>     > work with.
>     >
>     > The last several weeks of 5.6 development and stabilization have been
>     > exciting, with our codebase undergoing a quick security audit [3],
> and
>     > some real headway in terms of getting into distributions.
>     >
>     > We'll also continue to maintain our wireguard-linux-compat [2]
>     > backports repo for older kernels. On the backports front, WireGuard
>     > was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
>     > Debian Buster (via a real backport to 5.5.y) [5]. I'm also
> maintaining
>     > real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
>     > and we'll see where those wind up; 5.4.y is an LTS release.
>     >
>     > Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
>     > Fedora 32 will be getting WireGuard automatically by virtue of having
>     > 5.6, and I expect these to increase in number over time.
>     >
>     > Enjoy!
>     > Jason
>     >
>     >
>     > [1]
> https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
>     > [2] https://git.zx2c4.com/wireguard-linux-compat/
>     > [3]
> https://lore.kernel.org/netdev/202...@zx.../
>     > [4]
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
>     > [5]
> https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
>     > [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
>     > [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
>     >
>     >
>     > _______________________________________________
>     > Astlinux-users mailing list
>     > Ast...@li...
>     > https://lists.sourceforge.net/lists/listinfo/astlinux-users
>     >
>     > Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....
>     > _______________________________________________
>     > Astlinux-devel mailing list
>     > Ast...@li...
>     > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
>     _______________________________________________
>     Astlinux-devel mailing list
>     Ast...@li...
>     https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

Re: [Astlinux-devel] [Astlinux-users] FYI: WireGuard 1.0.0 is now official

[Michael K. <mic...@ip...>]

After using  OpenWRT for a little while, I decided to abandon its use for two reasons, 1) Wifi driver support but also 2) packages. It was so difficult to maintain a standard image across all my routers and I never knew what package was going to affect what and what would break when I upgraded and then how I would revert. Although I hate Mikrotik's UI and command structure, I decided to suck it up and move to them because of a single firmware image amongst other things.

Although I am not that knowledgeable in the area, I believe the stability of Astlinux is because of the minimalist approach taken to what is included and enabled. 
I therefore really like the current approach and certainly would not want to move to 'a series of entangled package upgrades'.

Thanks David for asking these questions as its really important that we understand what we are doing and why. 

Regards
Michael Knill

On 31/3/20, 3:11 am, "Lonnie Abelbeck" <li...@lo...> wrote:

    Hi David, et.al,
    
    Brainstorming ideas are always appreciated.
    
    Though I think our "AstLinux Principles" still apply today, as much as ever:
    
    AstLinux Principles:
    https://www.astlinux-project.org/about.html
    
    Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)
    
    Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.
    
    Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.
    
    Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.
    
    Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.
    
    Please discuss ...
    
    Lonnie
    
    [1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16
    
    
    
    
    > On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
    > 
    > Moving to devel list.
    > 
    > This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
    > 
    > Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
    > 
    > Just thought I would throw this out there and see what people think.
    > 
    > David.
    > 
    > On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
    > Greetings,
    > 
    > FYI, I forwarded (below) a note from the WireGuard mailing list.
    > 
    > My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
    > 
    > For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
    > 
    > Lonnie
    > 
    > 
    > ================
    > Begin forwarded message:
    > 
    > From: "Jason A. Donenfeld" <Ja...@zx...>
    > Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
    > Date: March 29, 2020 at 9:16:43 PM CDT
    > To: WireGuard mailing list <wir...@li...>
    > 
    > Hi folks,
    > 
    > Earlier this evening, Linus released [1] Linus 5.6, which contains our
    > first release of WireGuard. This is quite exciting. It means that
    > kernels from here on out will have WireGuard built-in by default. And
    > for those of you who were scared away prior by the "dOnT uSe tHiS
    > k0de!!1!" warnings everywhere, you now have something more stable to
    > work with.
    > 
    > The last several weeks of 5.6 development and stabilization have been
    > exciting, with our codebase undergoing a quick security audit [3], and
    > some real headway in terms of getting into distributions.
    > 
    > We'll also continue to maintain our wireguard-linux-compat [2]
    > backports repo for older kernels. On the backports front, WireGuard
    > was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
    > Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
    > real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
    > and we'll see where those wind up; 5.4.y is an LTS release.
    > 
    > Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
    > Fedora 32 will be getting WireGuard automatically by virtue of having
    > 5.6, and I expect these to increase in number over time.
    > 
    > Enjoy!
    > Jason
    > 
    > 
    > [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
    > [2] https://git.zx2c4.com/wireguard-linux-compat/
    > [3] https://lore.kernel.org/netdev/202...@zx.../
    > [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
    > [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
    > [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
    > [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
    > 
    > 
    > _______________________________________________
    > Astlinux-users mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-users
    > 
    > Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
    > _______________________________________________
    > Astlinux-devel mailing list
    > Ast...@li...
    > https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    
    
    
    _______________________________________________
    Astlinux-devel mailing list
    Ast...@li...
    https://lists.sourceforge.net/lists/listinfo/astlinux-devel
    

Re: [Astlinux-devel] [Astlinux-users] FYI: WireGuard 1.0.0 is now official

[Lonnie A. <li...@lo...>]

Hi David, et.al,

Brainstorming ideas are always appreciated.

Though I think our "AstLinux Principles" still apply today, as much as ever:

AstLinux Principles:
https://www.astlinux-project.org/about.html

Our current 3.16.x kernel has been getting backported fixes from upstream [1] for quite some time by Ben Hutchings ... some would argue that the current 3.16.x kernel has "all the fixes but none of the new bugs" :-)

Correct me if you disagree, but since we use i586/x86_64 architecture much of the newer kernel hardware support does not apply to us.  This is even more true for AstLinux running as VM Guests.

Additionally, a big sticking point upgrading beyond the 3.16.x kernel is our current unionfs kernel patches are no longer supported in 4.x.  Looks like we will need to switch to Aufs, which we have been giving some thought, making it backward compatible is a concern.

Some might argue we should stick with a rock-solid 3.16.x kernel for another year or so, others might suggest 4.x (unclear which is best) is warranted.  I think 5.x is too new to consider IMO, not enough testing.

Finally, packages vs. firmware-image.  I'm convinced the firmware-image approach is ideal for an appliance like AstLinux.  I've played with OpenWrt on an EdgeRouter-X, and found the package upgrade approach leaves much to be desired compared with a firmware-image approach.

Please discuss ...

Lonnie

[1] https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-queue.git/log/queue-3.16




> On Mar 30, 2020, at 10:13 AM, David Kerr <da...@ke...> wrote:
> 
> Moving to devel list.
> 
> This once again prompts the question as to what to do about AstLinux kernel version.  It feels that we are getting further and further behind and should maybe even skip 4.x and go straight to a 5.x.
> 
> Or... get out of the business of providing the low level OS components and develop on top of a standard "lightweight" distribution.  When AstLinux started up there was a need for a tight, small, integrated system that would work on typical network gateway hardware of the time.  But today's typical network gateway hardware is very capable of running a standard linux distribution.  And if we moved all the AstLinux-unique features over to installable packages I think we would benefit greatly.
> 
> Just thought I would throw this out there and see what people think.
> 
> David.
> 
> On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...> wrote:
> Greetings,
> 
> FYI, I forwarded (below) a note from the WireGuard mailing list.
> 
> My favorite VPN type (as well as many of you reading this) has achieved a major milestone.  Additionally, an outside security audit of WireGuard has been performed.
> 
> For those previously concerned about the non-official status of WireGuard, those concerns should now be minimized.
> 
> Lonnie
> 
> 
> ================
> Begin forwarded message:
> 
> From: "Jason A. Donenfeld" <Ja...@zx...>
> Subject: [ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released
> Date: March 29, 2020 at 9:16:43 PM CDT
> To: WireGuard mailing list <wir...@li...>
> 
> Hi folks,
> 
> Earlier this evening, Linus released [1] Linus 5.6, which contains our
> first release of WireGuard. This is quite exciting. It means that
> kernels from here on out will have WireGuard built-in by default. And
> for those of you who were scared away prior by the "dOnT uSe tHiS
> k0de!!1!" warnings everywhere, you now have something more stable to
> work with.
> 
> The last several weeks of 5.6 development and stabilization have been
> exciting, with our codebase undergoing a quick security audit [3], and
> some real headway in terms of getting into distributions.
> 
> We'll also continue to maintain our wireguard-linux-compat [2]
> backports repo for older kernels. On the backports front, WireGuard
> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> and we'll see where those wind up; 5.4.y is an LTS release.
> 
> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> Fedora 32 will be getting WireGuard automatically by virtue of having
> 5.6, and I expect these to increase in number over time.
> 
> Enjoy!
> Jason
> 
> 
> [1] https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> [2] https://git.zx2c4.com/wireguard-linux-compat/
> [3] https://lore.kernel.org/netdev/202...@zx.../
> [4] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> [5] https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
> 
> 
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
> 
> Donations to support AstLinux are graciously accepted via PayPal to pa...@kr....
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Re: [Astlinux-devel] [Astlinux-users] FYI: WireGuard 1.0.0 is now official

[David K. <da...@ke...>]

Moving to devel list.

This once again prompts the question as to what to do about AstLinux kernel
version.  It feels that we are getting further and further behind and
should maybe even skip 4.x and go straight to a 5.x.

Or... get out of the business of providing the low level OS components and
develop on top of a standard "lightweight" distribution.  When AstLinux
started up there was a need for a tight, small, integrated system that
would work on typical network gateway hardware of the time.  But today's
typical network gateway hardware is very capable of running a standard
linux distribution.  And if we moved all the AstLinux-unique features over
to installable packages I think we would benefit greatly.

Just thought I would throw this out there and see what people think.

David.

On Mon, Mar 30, 2020 at 10:36 AM Lonnie Abelbeck <li...@lo...>
wrote:

> Greetings,
>
> FYI, I forwarded (below) a note from the WireGuard mailing list.
>
> My favorite VPN type (as well as many of you reading this) has achieved a
> major milestone.  Additionally, an outside security audit of WireGuard has
> been performed.
>
> For those previously concerned about the non-official status of WireGuard,
> those concerns should now be minimized.
>
> Lonnie
>
>
> ================
> Begin forwarded message:
>
> *From: *"Jason A. Donenfeld" <Ja...@zx...>
> *Subject: **[ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released*
> *Date: *March 29, 2020 at 9:16:43 PM CDT
> *To: *WireGuard mailing list <wir...@li...>
>
> Hi folks,
>
> Earlier this evening, Linus released [1] Linus 5.6, which contains our
> first release of WireGuard. This is quite exciting. It means that
> kernels from here on out will have WireGuard built-in by default. And
> for those of you who were scared away prior by the "dOnT uSe tHiS
> k0de!!1!" warnings everywhere, you now have something more stable to
> work with.
>
> The last several weeks of 5.6 development and stabilization have been
> exciting, with our codebase undergoing a quick security audit [3], and
> some real headway in terms of getting into distributions.
>
> We'll also continue to maintain our wireguard-linux-compat [2]
> backports repo for older kernels. On the backports front, WireGuard
> was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and
> Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining
> real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7],
> and we'll see where those wind up; 5.4.y is an LTS release.
>
> Meanwhile, the usual up-to-date distributions like Arch, Gentoo, and
> Fedora 32 will be getting WireGuard automatically by virtue of having
> 5.6, and I expect these to increase in number over time.
>
> Enjoy!
> Jason
>
>
> [1]
> https://lore.kernel.org/lkml/CAHk-=wi9...@ma.../
> [2] https://git.zx2c4.com/wireguard-linux-compat/
> [3]
> https://lore.kernel.org/netdev/202...@zx.../
> [4]
> https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/tree/debian/dkms-versions?h=master-next
> [5]
> https://salsa.debian.org/kernel-team/linux/-/tree/master/debian%2Fpatches%2Ffeatures%2Fall%2Fwireguard
> [6] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.4.y
> [7] https://git.zx2c4.com/wireguard-linux/log/?h=backport-5.5.y
>
>
> _______________________________________________
> Astlinux-users mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> pa...@kr....

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4563-9cc2fc (Release Candidate2)

[Lonnie A. <li...@lo...>]

Release Candidate2 pre-1.3.8, please report any issues, ASAP.

** IMPORTANT NOTICE

-- The PPTP VPN server has been removed.
   pfSense dropped support of PPTP VPN with version 2.3 in 2016.
   Apple dropped support of PPTP VPN with iOS 10 and macOS 10.12 in 2016.
   PPTP VPN (MS-CHAPv2) is insecure and is no longer supported in AstLinux.

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Linux Kernel 3.16.82 (version bump), security and bug fixes

-- RUNNIX, version bump to runnix-0.5.11, with Linux Kernel 3.16.82, e2fsprogs 1.45.5

-- Asterisk 13.23.1 ('13se' version)
   Older than latest Asterisk 13.x version but more tested, built --without-pjproject

-- Asterisk 13.31.0 (version bump) and 16.8.0 (version bump)

-- OpenSSL, version bump to 1.1.1e, security fix: CVE-2019-1551

-- WireGuard VPN, module 0.0.20200318 (version bump), tools 1.0.20200319 (version bump)

-- OpenVPN, version bump to 2.4.8

-- arnofw (AIF), simplify integration of AIF within the build system, no functional change. After which:
   == Set the version to '2.0.2-04-astlinux'
   == Remove 'pptpd' support in the adaptive-ban plugin
   == Remove the pptp-vpn plugin
   == Remove the parasitic-net plugin

-- pppd, version bump to 2.4.8, security fix: CVE-2020-8597

-- acme-client, version bump to 2.8.5

-- arp-scan, version bump to 1.9.7, fixed with libpcap version 1.9.1

-- chrony, version bump to 4.0-pre1, adds 'maxsamples 1' and 'chronyc -N sources' support

-- ncurses, version bump to 6.2

-- ne, version bump to 3.3.0

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt


The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html


AstLinux Team

Re: [Astlinux-devel] A quick and easy build environment

[David K. <da...@ke...>]

I notice an error in my description below... a 10GB disk is not large
enough for an AstLinux build environment.... best to launch with at least
20GB.  Sorry about that.

David.

On Mon, Mar 16, 2020 at 6:32 PM Lonnie Abelbeck <li...@lo...>
wrote:

>
> > On Mar 16, 2020, at 3:54 PM, David Kerr <da...@ke...> wrote:
> >
> > Devs,
> >   I just discovered multipass... https://multipass.run and decided to
> give it a try.  It supports Mac, Windows (Pro, not Home) or Linux... for me
> I installed it on Mac.  Once installed a one-line command gets you a
> running Ubuntu 18.04 LTS environment...
> >
> > multipass launch --name astbuild --cpus 2 --mem 1G --disk 10G
> >
> > The first time you do that it takes a little time as it has to download
> the Ubuntu image.  But once started you can
> >
> > multipass shell astbuild
> >
> > and then follow the instructions at
> https://doc.astlinux-project.org/devdoc:documentation.
> >
> > You can speed things up by creating a cloud-init file to install all our
> required packages up-front, so for example on the above launch command
> add...
> >
> >  --cloud-init astlinux-cloud-config.yaml
> >
> > where the contents of the yaml file is...
> https://raw.githubusercontent.com/dkerr64/astlinux/develop/astlinux-cloud-config.yaml
> so the first time you connect to the shell everything is ready for you to
> git checkout the source, build and install Crosstool-NG and then build
> AstLinux.
> >
> > To get the built AstLinux image out of the VM you would want to
> >
> > multipass mount <host-path> astbuild:<image-path>
> >
> > so you can copy files in/out of the Ubuntu VM.
> >
> > Enjoy,
> > David.
>
> Thanks David,  I never heard of this until now.
>
> Lonnie
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4554-c8e153

[Lonnie A. <li...@lo...>]

Release Candidate pre-1.3.8, please report any issues, ASAP.

** IMPORTANT NOTICE

-- The PPTP VPN server has been removed.
   pfSense dropped support of PPTP VPN with version 2.3 in 2016.
   Apple dropped support of PPTP VPN with iOS 10 and macOS 10.12 in 2016.
   PPTP VPN (MS-CHAPv2) is insecure and is no longer supported in AstLinux.

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Linux Kernel 3.16.82 (version bump), security and bug fixes

-- Asterisk 13.23.1 ('13se' version)
   Older than latest Asterisk 13.x version but more tested, built --without-pjproject

-- Asterisk 13.31.0 (version bump) and 16.8.0 (version bump)

-- arnofw (AIF), simplify integration of AIF within the build system, no functional change. After which:
   == Set the version to '2.0.2-04-astlinux'
   == Remove 'pptpd' support in the adaptive-ban plugin
   == Remove the pptp-vpn plugin
   == Remove the parasitic-net plugin

-- pppd, version bump to 2.4.8, security fix: CVE-2020-8597

-- acme-client, version bump to 2.8.5

-- arp-scan, version bump to 1.9.7, fixed with libpcap version 1.9.1

-- chrony, version bump to 4.0-pre1, adds 'maxsamples 1' and 'chronyc -N sources' support

-- ncurses, version bump to 6.2

-- ne, version bump to 3.3.0

-- WireGuard VPN, module 0.0.20200215 (version bump), tools 1.0.20200206 (version bump)

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt


The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html


AstLinux Team

Re: [Astlinux-devel] A quick and easy build environment

[Lonnie A. <li...@lo...>]

> On Mar 16, 2020, at 3:54 PM, David Kerr <da...@ke...> wrote:
> 
> Devs,
>   I just discovered multipass... https://multipass.run and decided to give it a try.  It supports Mac, Windows (Pro, not Home) or Linux... for me I installed it on Mac.  Once installed a one-line command gets you a running Ubuntu 18.04 LTS environment...
> 
> multipass launch --name astbuild --cpus 2 --mem 1G --disk 10G
> 
> The first time you do that it takes a little time as it has to download the Ubuntu image.  But once started you can
> 
> multipass shell astbuild
> 
> and then follow the instructions at https://doc.astlinux-project.org/devdoc:documentation.
> 
> You can speed things up by creating a cloud-init file to install all our required packages up-front, so for example on the above launch command add...
> 
>  --cloud-init astlinux-cloud-config.yaml
> 
> where the contents of the yaml file is... https://raw.githubusercontent.com/dkerr64/astlinux/develop/astlinux-cloud-config.yaml so the first time you connect to the shell everything is ready for you to git checkout the source, build and install Crosstool-NG and then build AstLinux.
> 
> To get the built AstLinux image out of the VM you would want to 
> 
> multipass mount <host-path> astbuild:<image-path>
> 
> so you can copy files in/out of the Ubuntu VM.
> 
> Enjoy,
> David.

Thanks David,  I never heard of this until now.

Lonnie

[Astlinux-devel] A quick and easy build environment

[David K. <da...@ke...>]

Devs,
  I just discovered multipass... https://multipass.run and decided to give
it a try.  It supports Mac, Windows (Pro, not Home) or Linux... for me I
installed it on Mac.  Once installed a one-line command gets you a running
Ubuntu 18.04 LTS environment...

multipass launch --name astbuild --cpus 2 --mem 1G --disk 10G

The first time you do that it takes a little time as it has to download the
Ubuntu image.  But once started you can

multipass shell astbuild

and then follow the instructions at
https://doc.astlinux-project.org/devdoc:documentation.

You can speed things up by creating a cloud-init file to install all our
required packages up-front, so for example on the above launch command
add...

 --cloud-init astlinux-cloud-config.yaml

where the contents of the yaml file is...
https://raw.githubusercontent.com/dkerr64/astlinux/develop/astlinux-cloud-config.yaml
so the first time you connect to the shell everything is ready for you to
git checkout the source, build and install Crosstool-NG and then build
AstLinux.

To get the built AstLinux image out of the VM you would want to

multipass mount <host-path> astbuild:<image-path>

so you can copy files in/out of the Ubuntu VM.

Enjoy,
David.

Re: [Astlinux-devel] Ubuntu 19.10

[David K. <da...@ke...>]

Thanks Michael.  I will take another try at this once 20.04 comes out.  I
wonder wither ZFS will be default for that or still experimental given
20.04 will be a LTS release.

David

On Mon, Feb 24, 2020 at 6:09 AM Michael Keuter <li...@mk...>
wrote:

>
>
> > Am 06.11.2019 um 03:54 schrieb David Kerr <da...@ke...>:
> >
> > As usual I'm an early adopter and installed Ubuntu 19.10.  Only two
> issues of note the first I had reported to this list for 19.04 and is that
> crosstools configure does a version check for Bash version >3.1.  It checks
> for 3, 4 and no more.  Ubuntu is on v5 so it failed that check.  This time
> I went to the trouble of creating a patch which you can find in this commit
> (plus update to the readme)...
> https://github.com/dkerr64/astlinux/commit/a09900124220dd8f4c5cfe6f7d8a71e58bbeeaab
> >
> > Now the second problem I have not bothered to troubleshoot.  Being
> totally crazy I first installed Ubuntu 19.10 with the ZFS file system.
> Which is clearly flagged as experimental.  But you know, how bad could it
> be? lets try it.  Well don't bother.  I ran into a problem towards end of
> initrd.img build.  I don't know what the issue is but it just smelled like
> maybe something to do with the file system.  So I fired up another VM and
> installed again with regular old ext4 and everything is happy.  Astlinux
> builds and runs.
> >
> > Here's the part that fails on ZFS for those enquiring minds... oh, and
> googling finds...
> http://lists.busybox.net/pipermail/buildroot/2016-March/157508.html
> >
> > >>> host-makedevs buildroot-astlinux-1.x Extracting
> > >>> host-makedevs buildroot-astlinux-1.x Patching package/makedevs
> > >>> host-makedevs buildroot-astlinux-1.x Configuring
> > >>> host-makedevs buildroot-astlinux-1.x Building
> > /usr/bin/gcc -O2 -I/home/david/github/astlinux/output/host/usr/include
> -L/home/david/github/astlinux/output/host/lib
> -L/home/david/github/astlinux/output/host/usr/lib
> -Wl,-rpath,/home/david/github/astlinux/output/host/usr/lib
> package/makedevs/makedevs.c -o
> /home/david/github/astlinux/output/build/host-makedevs-buildroot-astlinux-1.x/makedevs
> > >>> host-makedevs buildroot-astlinux-1.x Installing to host directory
> > /usr/bin/install -D -m 755
> /home/david/github/astlinux/output/build/host-makedevs-buildroot-astlinux-1.x/makedevs
> /home/david/github/astlinux/output/host/usr/bin/makedevs
> > >>>   Generating root filesystem image rootfs.ext2
> > rm -f /home/david/github/astlinux/output/images/rootfs.ext2
> > rm -f /home/david/github/astlinux/output/build/_fakeroot.fs
> > echo '#!/bin/sh' > /home/david/github/astlinux/output/build/_fakeroot.fs
> > echo 'set -e' >> /home/david/github/astlinux/output/build/_fakeroot.fs
> > echo "chown -R 0:0 /home/david/github/astlinux/output/target" >>
> /home/david/github/astlinux/output/build/_fakeroot.fs
> > cat project/initrd/device_table.txt project/initrd/device_table_dev.txt
> > /home/david/github/astlinux/output/build/_device_table.txt
> > echo "/home/david/github/astlinux/output/host/usr/bin/makedevs -d
> /home/david/github/astlinux/output/build/_device_table.txt
> /home/david/github/astlinux/output/target" >>
> /home/david/github/astlinux/output/build/_fakeroot.fs
> > echo "
> PATH="/home/david/github/astlinux/output/host/bin:/home/david/github/astlinux/output/host/usr/bin:/home/david/github/astlinux/output/host/usr/sbin/:/sbin:/usr/sbin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> fs/ext2/genext2fs.sh -d /home/david/github/astlinux/output/target
> /home/david/github/astlinux/output/images/rootfs.ext2" >>
> /home/david/github/astlinux/output/build/_fakeroot.fs
> > chmod a+x /home/david/github/astlinux/output/build/_fakeroot.fs
> > /home/david/github/astlinux/output/host/usr/bin/fakeroot --
> /home/david/github/astlinux/output/build/_fakeroot.fs
> > rootdir=/home/david/github/astlinux/output/target
> > table='/home/david/github/astlinux/output/build/_device_table.txt'
> > genext2fs: couldn't allocate a block (no free space)
> > make: *** [fs/ext2/ext2.mk:38:
> /home/david/github/astlinux/output/images/rootfs.ext2] Error 1
> >
> > real  3m52.915s
> > user  2m47.901s
> > sys   1m4.448s
> > Initrd build failed.
> > mkdir -p /home/david/github/astlinux/output/build/buildroot-config
> > #
> > # configuration written to /home/david/github/astlinux/.config
> > #
>
> Hi David,
>
> sorry being so late, I just stumbled upon this post again.
> For the second ZFS part: I am running the AstLinux build engine on Proxmox
> in an old Debian 8 container on ZFS.
>
> I do sometimes see the same genext2fs error you described.
> For me it helps just to start the build process again (only creating the
> image, no clean build).
>
> Michael
>
> http://www.mksolutions.info
>
>
>
>
>
> _______________________________________________
> Astlinux-devel mailing list
> Ast...@li...
> https://lists.sourceforge.net/lists/listinfo/astlinux-devel
>

Re: [Astlinux-devel] Ubuntu 19.10

[Michael K. <li...@mk...>]

> Am 06.11.2019 um 03:54 schrieb David Kerr <da...@ke...>:
> 
> As usual I'm an early adopter and installed Ubuntu 19.10.  Only two issues of note the first I had reported to this list for 19.04 and is that crosstools configure does a version check for Bash version >3.1.  It checks for 3, 4 and no more.  Ubuntu is on v5 so it failed that check.  This time I went to the trouble of creating a patch which you can find in this commit (plus update to the readme)... https://github.com/dkerr64/astlinux/commit/a09900124220dd8f4c5cfe6f7d8a71e58bbeeaab
> 
> Now the second problem I have not bothered to troubleshoot.  Being totally crazy I first installed Ubuntu 19.10 with the ZFS file system.  Which is clearly flagged as experimental.  But you know, how bad could it be? lets try it.  Well don't bother.  I ran into a problem towards end of initrd.img build.  I don't know what the issue is but it just smelled like maybe something to do with the file system.  So I fired up another VM and installed again with regular old ext4 and everything is happy.  Astlinux builds and runs.
> 
> Here's the part that fails on ZFS for those enquiring minds... oh, and googling finds... http://lists.busybox.net/pipermail/buildroot/2016-March/157508.html
> 
> >>> host-makedevs buildroot-astlinux-1.x Extracting
> >>> host-makedevs buildroot-astlinux-1.x Patching package/makedevs
> >>> host-makedevs buildroot-astlinux-1.x Configuring
> >>> host-makedevs buildroot-astlinux-1.x Building
> /usr/bin/gcc -O2 -I/home/david/github/astlinux/output/host/usr/include -L/home/david/github/astlinux/output/host/lib -L/home/david/github/astlinux/output/host/usr/lib -Wl,-rpath,/home/david/github/astlinux/output/host/usr/lib package/makedevs/makedevs.c -o /home/david/github/astlinux/output/build/host-makedevs-buildroot-astlinux-1.x/makedevs
> >>> host-makedevs buildroot-astlinux-1.x Installing to host directory
> /usr/bin/install -D -m 755 /home/david/github/astlinux/output/build/host-makedevs-buildroot-astlinux-1.x/makedevs /home/david/github/astlinux/output/host/usr/bin/makedevs
> >>>   Generating root filesystem image rootfs.ext2
> rm -f /home/david/github/astlinux/output/images/rootfs.ext2
> rm -f /home/david/github/astlinux/output/build/_fakeroot.fs
> echo '#!/bin/sh' > /home/david/github/astlinux/output/build/_fakeroot.fs
> echo 'set -e' >> /home/david/github/astlinux/output/build/_fakeroot.fs
> echo "chown -R 0:0 /home/david/github/astlinux/output/target" >> /home/david/github/astlinux/output/build/_fakeroot.fs
> cat project/initrd/device_table.txt project/initrd/device_table_dev.txt > /home/david/github/astlinux/output/build/_device_table.txt
> echo "/home/david/github/astlinux/output/host/usr/bin/makedevs -d /home/david/github/astlinux/output/build/_device_table.txt /home/david/github/astlinux/output/target" >> /home/david/github/astlinux/output/build/_fakeroot.fs
> echo "	PATH="/home/david/github/astlinux/output/host/bin:/home/david/github/astlinux/output/host/usr/bin:/home/david/github/astlinux/output/host/usr/sbin/:/sbin:/usr/sbin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin" fs/ext2/genext2fs.sh -d /home/david/github/astlinux/output/target  /home/david/github/astlinux/output/images/rootfs.ext2" >> /home/david/github/astlinux/output/build/_fakeroot.fs
> chmod a+x /home/david/github/astlinux/output/build/_fakeroot.fs
> /home/david/github/astlinux/output/host/usr/bin/fakeroot -- /home/david/github/astlinux/output/build/_fakeroot.fs
> rootdir=/home/david/github/astlinux/output/target
> table='/home/david/github/astlinux/output/build/_device_table.txt'
> genext2fs: couldn't allocate a block (no free space)
> make: *** [fs/ext2/ext2.mk:38: /home/david/github/astlinux/output/images/rootfs.ext2] Error 1
> 
> real	3m52.915s
> user	2m47.901s
> sys	1m4.448s
> Initrd build failed.
> mkdir -p /home/david/github/astlinux/output/build/buildroot-config
> #
> # configuration written to /home/david/github/astlinux/.config
> #

Hi David,

sorry being so late, I just stumbled upon this post again.
For the second ZFS part: I am running the AstLinux build engine on Proxmox in an old Debian 8 container on ZFS.

I do sometimes see the same genext2fs error you described. 
For me it helps just to start the build process again (only creating the image, no clean build). 

Michael

http://www.mksolutions.info

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4526-35c559

[Lonnie A. <li...@lo...>]

Announcing Pre-Release Version: astlinux-1.3-4526-35c559

** IMPORTANT NOTICE

-- The PPTP VPN server has been removed.
   pfSense dropped support of PPTP VPN with version 2.3 in 2016.
   Apple dropped support of PPTP VPN with iOS 10 and macOS 10.12 in 2016.
   PPTP VPN (MS-CHAPv2) is insecure and is no longer supported in AstLinux.

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Linux Kernel 3.16.82 (version bump), security and bug fixes

-- Asterisk 13.23.1 ('13se' version)
   Older than latest Asterisk 13.x version but more tested, built --without-pjproject

-- Asterisk 13.31.0 (version bump) and 16.8.0 (version bump)

-- pppd, version bump to 2.4.8, security fix: CVE-2020-8597

-- WireGuard VPN, module 0.0.20200215 (version bump), tools 1.0.20200206 (version bump)

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt


The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html


AstLinux Team

[Astlinux-devel] AstLinux Pre-Release: astlinux-1.3-4515-62297e

[Lonnie A. <li...@lo...>]

Announcing Pre-Release Version: astlinux-1.3-4515-62297e

Latest Asterisk and WireGuard updates.

The AstLinux Team is regularly upgrading packages containing security and bug fixes as well as adding new features of our own.

-- Linux Kernel 3.16.74 (no change)

-- Asterisk 13.23.1 ('13se' version)
   Older than latest Asterisk 13.x version but more tested, built --without-pjproject

-- Asterisk 13.31.0 (version bump) and 16.8.0 (version bump)

-- WireGuard VPN, module 0.0.20200215 (version bump), tools 1.0.20200206 (version bump)

-- Complete Pre-Release ChangeLog:
https://s3.amazonaws.com/beta.astlinux-project/astlinux-changelog/ChangeLog.txt


The "AstLinux Pre-Release ChangeLog" and "Pre-Release Repository URL" entries can be found under the "Development" tab of the AstLinux Project web site ...

AstLinux Project -> Development
https://www.astlinux-project.org/dev.html


AstLinux Team

[Astlinux-devel] Announcing AstLinux Release: 1.3.7.1

[Lonnie A. <li...@lo...>]

Announcing AstLinux Release: 1.3.7.1

Shortly after we announced AstLinux 1.3.7, three security fixes to Asterisk were disclosed.

As such, we generated AstLinux 1.3.7.1 with the security fixes applied to all versions of Asterisk.

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.3.7.1 Highlights:
* Asterisk Versions: 13.23.1, 13.29.2, 16.6.2
* Asterisk security patches: AST-2019-006, AST-2019-007, AST-2019-008

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.7.1/docs/ChangeLog.txt

All users are encouraged to upgrade.

Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal.

AstLinux Team

[Astlinux-devel] Announcing AstLinux Release: 1.3.7

[Lonnie A. <li...@lo...>]

Announcing AstLinux Release: 1.3.7

More Info: AstLinux Project
https://www.astlinux-project.org/

AstLinux 1.3.7 Highlights:
* Asterisk Versions: 13.23.1, 13.29.1, 16.6.1
* Upgrade to Linux Kernel 3.16.74, including the RUNNIX bootloader, security and bug fixes
* OpenSSL, major version bump to 1.1.1d, the new LTS series. The previous 1.0.2 LTS series is EOL at the end of 2019
* Note: Many packages required version bumps or patches to be compatible with the new OpenSSL 1.1 API
* acme-client, add upstream patch from 2.8.3 to fix (important) Let's Encrypt CDN changes
* php, major version bump to 7.2.23, adds OpenSSL 1.1 compatibility
* Web Interface Edit tab, add support for CodeMirror text editing
* Fossil, major version bump to 2.9, adds numerous enhancements to the look and feel of the web interface
* iprange, new command, version 1.0.4, a tool capable of managing sets of IPs
* arnofw (AIF), reload-blocklist-netset cron script, add new netset types
* arnofw (AIF), wireguard-vpn plugin, add support for WG->Local TCP/UDP INPUT policy firewall rules
* WireGuard VPN, latest development snapshot during its incorporation into the mainline Linux Kernel
* Asterisk '13se' (stable edition) version 13.23.1 is older than latest Asterisk 13.x version but more tested, built --without-pjproject
* Package upgrades providing important security and bug fixes

Full ChangeLog:
https://raw.githubusercontent.com/astlinux-project/astlinux/1.3.7/docs/ChangeLog.txt

All users are encouraged to upgrade.

Previous Asterisk 11.x users are encouraged to switch to the new Asterisk '13se' (stable edition). Some configuration changes will be needed, though minimal.

AstLinux Team

[Astlinux-devel] Ubuntu 19.10

[David K. <da...@ke...>]

As usual I'm an early adopter and installed Ubuntu 19.10.  Only two issues
of note the first I had reported to this list for 19.04 and is that
crosstools configure does a version check for Bash version >3.1.  It checks
for 3, 4 and no more.  Ubuntu is on v5 so it failed that check.  This time
I went to the trouble of creating a patch which you can find in this commit
(plus update to the readme)...
https://github.com/dkerr64/astlinux/commit/a09900124220dd8f4c5cfe6f7d8a71e58bbeeaab

Now the second problem I have not bothered to troubleshoot.  Being totally
crazy I first installed Ubuntu 19.10 with the ZFS file system.  Which is
clearly flagged as experimental.  But you know, how bad could it be? lets
try it.  Well don't bother.  I ran into a problem towards end of initrd.img
build.  I don't know what the issue is but it just smelled like maybe
something to do with the file system.  So I fired up another VM and
installed again with regular old ext4 and everything is happy.  Astlinux
builds and runs.

Here's the part that fails on ZFS for those enquiring minds... oh, and
googling finds...
http://lists.busybox.net/pipermail/buildroot/2016-March/157508.html

>>> host-makedevs buildroot-astlinux-1.x Extracting
>>> host-makedevs buildroot-astlinux-1.x Patching package/makedevs
>>> host-makedevs buildroot-astlinux-1.x Configuring
>>> host-makedevs buildroot-astlinux-1.x Building
/usr/bin/gcc -O2 -I/home/david/github/astlinux/output/host/usr/include
-L/home/david/github/astlinux/output/host/lib
-L/home/david/github/astlinux/output/host/usr/lib
-Wl,-rpath,/home/david/github/astlinux/output/host/usr/lib
package/makedevs/makedevs.c -o
/home/david/github/astlinux/output/build/host-makedevs-buildroot-astlinux-1.x/makedevs
>>> host-makedevs buildroot-astlinux-1.x Installing to host directory
/usr/bin/install -D -m 755
/home/david/github/astlinux/output/build/host-makedevs-buildroot-astlinux-1.x/makedevs
/home/david/github/astlinux/output/host/usr/bin/makedevs
>>>   Generating root filesystem image rootfs.ext2
rm -f /home/david/github/astlinux/output/images/rootfs.ext2
rm -f /home/david/github/astlinux/output/build/_fakeroot.fs
echo '#!/bin/sh' > /home/david/github/astlinux/output/build/_fakeroot.fs
echo 'set -e' >> /home/david/github/astlinux/output/build/_fakeroot.fs
echo "chown -R 0:0 /home/david/github/astlinux/output/target" >>
/home/david/github/astlinux/output/build/_fakeroot.fs
cat project/initrd/device_table.txt project/initrd/device_table_dev.txt >
/home/david/github/astlinux/output/build/_device_table.txt
echo "/home/david/github/astlinux/output/host/usr/bin/makedevs -d
/home/david/github/astlinux/output/build/_device_table.txt
/home/david/github/astlinux/output/target" >>
/home/david/github/astlinux/output/build/_fakeroot.fs
echo "
PATH="/home/david/github/astlinux/output/host/bin:/home/david/github/astlinux/output/host/usr/bin:/home/david/github/astlinux/output/host/usr/sbin/:/sbin:/usr/sbin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
fs/ext2/genext2fs.sh -d /home/david/github/astlinux/output/target
 /home/david/github/astlinux/output/images/rootfs.ext2" >>
/home/david/github/astlinux/output/build/_fakeroot.fs
chmod a+x /home/david/github/astlinux/output/build/_fakeroot.fs
/home/david/github/astlinux/output/host/usr/bin/fakeroot --
/home/david/github/astlinux/output/build/_fakeroot.fs
rootdir=/home/david/github/astlinux/output/target
table='/home/david/github/astlinux/output/build/_device_table.txt'
genext2fs: couldn't allocate a block (no free space)
make: *** [fs/ext2/ext2.mk:38:
/home/david/github/astlinux/output/images/rootfs.ext2] Error 1

real 3m52.915s
user 2m47.901s
sys 1m4.448s
Initrd build failed.
mkdir -p /home/david/github/astlinux/output/build/buildroot-config
#
# configuration written to /home/david/github/astlinux/.config
#