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.
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.
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.
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
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?
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