After going trough the final steps and tests for the first ever final community -arm release, found a bug that would need a little patch to nethserver-base.
In consultation (behind the scene) with @davidep and @giacomo we going a new route by introducing a new packageexclusive to arm architectures to insert, if possible, template snippets satisfying arm demands and quirks.
This gives us more flexibility and freedom to drive the arm development forward. However with more freedom comes more responsibly and here I like to find some assistance. Being a strong believer in the (minimal) four-eyeās principle I hope to find some code-reviewers among you.
The skills are modest:
You need to have understanding of the e-smith configuration layer and how templates are written.
More is appreciated because quite frankly Iām a hardware-developer not a software-developer nor a system-administrator.
Hope to find some volunteers.
Do not be afraid, itās fun.
We not going to blame and same if something is overseen. Even if you agreed a code snippet would work.
Working in product development for the last past years (picking up my old profession) the crucial question it always boils-down to is exactly the direction to go to
Simple answer is you need a team to reflect to; those are not easy to findā¦
Sorry @Andy_Wismer iām going to be a direct marketeer hereā¦
Reading your postās on the forum it is above doubt you clould be of great value to help at the arm-community effort. @stephdl reviewing helping out with my limited code skills it would be nice to have your skills, with empathy for arm-boards, on-board too.
As said, Iām more of a Network / Systems guy than a coder, but as any systems guy, I can code too.
Not at yours or Stephdlās level, but I can handle a few languagesā¦
Another thing counts too, I love NethServer, and Iām an avid Raspberry user.
I have installed almost anything that can run on a Raspberry, bit my teeth out at OpenBSD, but NextCloud and several stuff worked! But Iād love to have a portable NethServer on a RPI4, eg for travelling and whateverā¦
So count me in!
I would need a few tips about GIT handling, I just started using it.
Forgot too mention: arm-effort is about leaning too.
Even if you do not have the skills for e-smith templates or the mind boggling world of git; we want to be a low threshold entry point.
First tip to start to understand git: gitkraken a (unfortunately not open source) gui implementation for handling git repoās
Coming from the world of SME-Server, Iām actually quite familiar with the templating system and have modified several myself, eg to get a complete PXE boot environment up and running with SME-Server.
I also used to use the dated cvs system quite intensively, had my own CVS running in the office and at home. I know thatās more than a generation away from the present day GitHub, but certain concepts stayā¦
BTW, from your name Iād assume to be dutch, as Iām quite familiar with the country may I ask where you are? I have travelled from Vlissingen to Den Helder and on to Lieuwarden and Groningen.
I aslo have quite a few good friends here, who are dutch - two also happen to be in ITā¦
Looking at Gitkraken now (Kraken is dutch for octopus?), looks good. Mac, Linux and Windows, cool!
Gouda is famous for itās cheese - unfortunately, even being swiss, Iām allergic to cheese! Iām the only one in my family with that affliction, my brother can eat cheeseā¦
If I recall correctly, the station was rebuilt about 10-15 years ago with more platforms (Itās been 25 years, since I last was there!). There used to be two stops between Gouda and Utrecht CS, but if Iām correct, there are about 4 now. And all the way to Utrecht 4 tracksā¦
Do you work professionally with ARM?
Iād like to add: Gitkraken really looks good and a lot of help to āmanageā git workingsā¦
Iām (in Dutch) een Goudse Kaaskop an do not eat/like cheese.
Yes, but with cortex-mX. The little stuff in everything
I bet you have more of those processors (cores) running in your environment running you can imagine. For instance my mouse and keyboard actually have an arm-cortex-m0 STM32L0xx.
In this development pace we try to avoid OperatingSystems , it has to fit in de xKb flash we have.
As said iām into hardware, that means C(++) and a kind of lost if I donāt find void main in a code base.
I was dabbling with RealTime systems like QNX, a real pity that was only a brief open/shared source stint they had. Now itās part of Blackberry.
I still think they should have left it open, and continued using Photon, but as in a lot of embedded cases, there is no real use for āWindowingā, as most / all āAppsā run full screen. Typical in automotive use, like BMWs bord computer systemā¦
I really would liked to have a QNX / Photon system on at least one of my raspberries.
great! Iām there! I admit that in this period I have less free time than usual (I suppose it is the effect of āsmart workingā ) but I will do my best, even if for two months I still cannot unbox my new rpi4
at the moment if I remember correctly, I should have ns7.7 some installs as aarch64 on (odroid c2, pine64, scaleway, vm on proxmox) and armhfp (rpi3 and odroid hc1)
Iāll go a bit OT but I wanted to ask for a while ā¦ do you think it is the case to give a try to GitHub - pftf/RPi3: Raspberry Pi 3 UEFI Firmware Images ??
A bit OT is fine and it is not completely off-topic; I have been pursuing efi-boot for quite a while. I like the split of all the early boot loaders and the actually booting of the distro/kernel. Unfortunately it is (AFIAK) impossible for armhfp on centos el7. To much bitās and peaces , such as grub2-efi, are missing.
On arrch64 is is very possible but I took the uboot-route simply because the vast amouund of supported boards. Actually my odroid C2 used for all the netserver aarch64 development boots this way. However uboot needs to be patched to replace fedora-ismās with centos-ismās I tried to get this in at the centos arm-dev mailing list and the (for centos-arm) upstream fedora mailing list with no luck.
So yes the tianocore based uefi pftf/RPi3 sould be able to boot aarch64 centos/nethserver on a RPI3.
EDIT:
Itās a bit old, and needs to be updated but once i build basally every thing needed to create efi-booted aarch64 images on copr
armhfp:
nethserver-arm-extra-config is released and the final images are waiting to be released.
One little quirk remains: on a RPI-4 it can happen the self-signed server certificate is created before chronyd fetches the time. Resulting in a expiration date in 1979. None of my browsers care, @mrmarkuz reported his firefox did. Apparently only for cockpit, maybe because this is a socket and the traditional UI a straight forward web page.
Can we live with this quirk?
aarch64:
Epel is unmaintained since the EOL of 7.6.1810 (approx 2019-10-xx) ā¦Nethserver-repoās are up to date.
Iād like to test the latest RPi4 / RPi3 Image, my Home Lab Network is up and running, and Iāve a RPi4 twiddling thumbs and waiting for something to doā¦
Where can I grab these?
Does this happen often ( >50%) or less?
If less often, I think we can live with this, just inform on the web-site for users.
Firefox is known to be fussy whith SSL / Certs.
On my Mac, sometimes when I access per VPN my friends Proxmox I canāt log in. So I log in with Safari - which works! At that moment, Firefox also accepts the certificate and can log in.
I also think it depends which OS, caching settings in Firefox and a few other factorsā¦
i hope to give a try tomorrowā¦ but i think if itās too time expensive or require some big change respect to x86-&4 to fix we can doument it and leave as isā¦
yes eol of epel itās a shameā¦ but I would still try to keep active the aarch64 version (proably with even less modules than armhfp), also in this case documenting that epel packages may not be updatedā¦ we could think of it as a training for centos 8 since in the long run it will probably be the main version for arm
The thing is I kind of have a hunch for a solution: let the nethserver-system-init.serive require chrony-wait.service.
But the up-to 10min scars me. In this case: is the cure worse than the disease ?
It a shame, especially because Centos started releasing kernel which run on SBCās. My main headache until now was needing to āmaintainā a kernel to boot SBCās, without those SBCās we never get interest in aarch64ā¦
Centos even releases sclās ā¦ we should be able to run nextcloud on aarch64
Keeping practice and debugging in aarch64 is valuable for the far future
IMHO we should come up with some name/definition for aarch64
Note: inside the compressed images they still called final, lets call this an insider release @Andy_Wismer: it is the same you already have, just a name change.
) but I will do my best, even if for two months I still cannot unbox my new rpi4 
and it is not completely off-topic; I have been pursuing efi-boot for quite a while. I like the split of all the early boot loaders and the actually booting of the distro/kernel. Unfortunately it is (AFIAK) impossible for armhfp on centos el7. To much bitās and peaces , such as grub2-efi, are missing.
but once i build basally every thing needed to create efi-booted aarch64 images on 
