We would like to setup a shared roadmap on the nethserver-arm project.
Purpose
The main aim of the roadmap it’s having an ARM beta when NethServer 7.6.x will be out.
We would like to release an official image for Raspberry 3 (ARM 32) along with a base system for ARM 64 (aarch64).
It should be something like an ARM spin with a list of supported (or at least tested) modules. Some of them may have less feasible use-cases, still offered keeping the Fun-Part in mind.
Development strategy
As long as the code is simple, we can merge ARM specific features inside the core.
If more modifications are needed, we can create an ad-hoc package for ARM installations (something like nethserver-arm-box) to tune specific parameters.
The last resource is the creation of a branch inside git repositories, but we should avoid it because it highly increase the maintenance effort.
Package building
Just stick on manual compilation for now, directly into a Raspberry or using QEMU.
In the meanwhile, we should try to setup an ARM build on Travis.
Otherwise Nethesis could provide a machine using Scaleway (thanks to @Amygos for pointing it out!)
The best solution is to have ARM repository officially hosted inside the main mirror (packages.nethserver.org). We need a little time to improve the upload process and deploy noarch packages for all architectures.
In the meanwhile, @mrmarkuz mirror is working great. We will let you know as soon as @davidep has little time to work on the infra.
The yum repository will have different comps for each architecture, so we are going to merge the ARM comps inside the main repository
Documentation
What is the best place to store the ARM documentation:
Meanwhile the first merges in the core-code are a fact!
Tomorrow going find some time to test
I’v been thinking and working on our aarch64 ambition; get some insight on the project risks (which is basically my job, but than for hardware). And identified 3 topics:
Default boot method for aarch64 in centos/rhel environment is UEFI boot. IMO we sould adopt this too and enhance it with u-boot EFI for SBC’s. Despite it’s against rhel’s policy.
There seem to be no SCL packages, other than devtoolsets, for aarch64 => PHP5.6 and PHP7.x will be hard to get.
Because of the smaller audience testing might be less elaborate
Already did some reached on the U-boot/UEFI marriage and am able to load GRUB2 with u-boot and boot a kernel with the linux EFI stub. Unfortunately it gets stuck at loading systemd (PID1)
(And to be frank I do know J@ck Sh!t about UEFI…)
We have a prove of concept to boot Centos aarch64 on a SBC over u-boot > UEFI > grub2
As usual still a lot of ironing before us; it is still a bit “hacked” :
grub2 config is not written to the appropriate efi directory
centos uboot-images-armv8 carry a fedora patch causing u-boot to look in EFIi/fedora for grubaa64.efi
can not persuade the appliance-creator to flag the (fat) efi partition as boot
And my Odroid C2 is in need of a kernel > 4.16; Just a with a small change in the kernel-config of the fedora (FC28) was necessary.
Successfully booted an Odroid C2, rpi3 and rpi3+ in 64 bit.
NOTE: this does not change my position on the Raspberry PI’s. They are better off with the 32 bit kernel, it’s just a (academic) prove of concept. (And very funny!)
On a RPI 3(+) it takes a loooong time to boot, and the hard-beat (green led) does not work;
be patient and if you can hook up a monitor (even this gets blacked out for quite some time…)
For U-boot based boards you must take care of a (recent) u-boot with efi capabilities,
(note for the odroid c2 you need mainline u-boot the one offert by HK nor Centos work, i grabbed mine from a alarm package)
Turns out i made a stupid mistake creating the img with a kernel not suitable for the C2. Corrected now although it would not be maintained.
Furthermore the heartbeat LED comes to live…; modprobe ledtrig-heartbeat did it.
(Link does does not change)
Pretty close to a complete (armhfp matching) aarch64 repository; evebox, nethserver-dc and nextcloud are still missing.
For the latter I propose to wait and see developments on PHP upstream can bring us.
The 7.6 is behind the corner (far more early than expected), so we need to decide how to continue the work.
My guess is that CentOS 7.6 will be out later this week, and I’d like to have a stable NS 7.6 release maximum in a couple of weeks.
Do you think we need to provide the ARM spin along with the official release? Or can we postpone it on a second time? Let’s say another couple of weeks.
document the whole thing (including the list all supported modules)
Am I missing something?
@mark_nl, what is the best way to test the spin without a real hardware? I’d like to have an ARM 7.5, upgrade it from CR (http://mirror.centos.org/altarch/7/cr/) and check what is missing.
I remember I considered the multi-arch during the initial development of the automated repository maintenance scripts. But I need to get my hands on it again: on the top of my list.
i think that much will depend on how much it will engage the release of 7.6 on x86_64.
it would be better to have stable repositories from first release, so, a lot will depend on when packages.nethserver.org (or a stable alternative) will be available, and I would not see anything wrong if the release for ARM was postponed for a few weeks, it would make us do things right
Simple and straight forward, probably the easiest to adopt current automation
Opens the possibility to merge arm in to nethserver release because repo urls are the same
con:
Final (point)releases must be released at the same time because “7” is linked to the latest point release.
(B) in altarch
pro:
Point releases can lag behind a bit
con:
!pro(A); does not have the pro’s of (A)
I tend to favor in altarch (B) because of the decoupling, especially in this early stage.
Also because:
I tend to agree with @dz00te and lag behind a little bit with arm:
at the release of x86_64 alpha we populate the arm repos, at x86_64 beta we release arm alpha and so on…
This mainly because of lack of man power; to me its appears to be more efficient to test on arm known to work packages instead of aiming at a moving (86_64 test) target.
See above, although it is possible to sync the arm testing repository with planned updates for early birds. As said I tend to prefer to wait until the x86_64 repositories are populated.
Cannot really help with this. But am not confident too: most solutions described are based on qemu-static and this is not a stable build environment. However noarch’s with some arm specific requirements (is this a contradiction? ) like nethserver-arm-release or nethserver-nextcloud can be build on x86_64
I can make a start with this, but written by me, suffering from a mild-form of Dyslexia, it’s mot going to be really good.
Do not have an answer yet On my todo/idea list is to find a convenient way to make snapshots for testing employments, PXE boot on real hardware? ZFS?
For armhfp we have a community with appropriate hardware (raspberry pi) to help. For aarch64 it’s a bigger challenge…
(IMHO)
Agree on the repo location
Create means to populate this repo (automated or in the initial stage by hand)
I am kind of back. Still a couple weeks in the sling, so working a little slow. Getting an Kenisngton Optical Track ball (Expert I think) mae a significant improvement; I can use it left-handed.
Also got an Odroid-HC1. I have Fedora29 running on it with rootfs on the sata drive. I am on the Odroid forum getting help on options to also move the boot partition over. It may only be a matter of setting the right env in their special bootloader piece. Centos is waiting on a new image build from Pablo; he had a bad build for 419 and is working on a fix.
So I am looking soon at working with Nethserver again. I will be working on a AD on a Cubietruck, so that should not be too challenging. (other than working with your AD setup and finally moving from XP to Win7 clients!).
The Odroid is for my mailserver and here is the challenge. I MUST support multiple domains in different DNS domains. I use Postfixadmin for this. It works great. How do I start a dialog to see what it would take to integrate Postfixadmin into the Nethserver mail environment?
Postfixadmin is provides all the hooks into postfix and an sql DB to support multiple domains. Your ldap/pop server, ldap web client, and spam/virus agent all have components to work with the multi-domain database.
For example. I can have joe@foo.com and joe@bar.com and they are different accounts and different users. They each log into the same ldap/pop server with their specific account.
From what I have seen of the Nethserver mail system, this is not supported.
I have been working on 7.6 and think most (1) dependencies for arm32 bit are met. Coming day’s aarch64 will follow.
(1) most because rspamd 1.8.2 does not play along: it won’t compile, 1.8.1 and 1.8.3 does
Having thought about the above led to the insight it’s almost mandatory to merge arm in nethserver-release to avoid mistakenly install the noarch package targeted @x86_64. An other solution would be to define the arch of the release package.
AFAIK to make a merge possible we need:
a package which provides “epel” for arm32
a package which provides php72-scl for arm32 and rm64, although these packages may live in “base” (like rh-php56)
just a few conditionals in /usr/sbin/nethserver-install, athough it does not seem to be impossible to workaround this in the end.
my question is how do we get the arm packages on packges.nethserver.org ? Or should i proceed with building a 7.6 repo and image based on the current (@mrmarkuz) location?
) like nethserver-arm-release or nethserver-nextcloud can be build on x86_64
On my todo/idea list is to find a convenient way to make snapshots for testing employments, PXE boot on real hardware? ZFS?