Menu
▾
▴
Re: [Astlinux-devel] Astlinux base system
|
From: David K. <da...@ke...> - 2020-04-06 22:34:35
|
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 > |
