Menu
▾
▴
Re: [Astlinux-devel] Astlinux base system
|
From: Michael K. <li...@mk...> - 2020-04-07 09:44:33
|
> 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 |
