Here are the first images to kick-start testing armhfp and (experimental) aarch64.
You can download a image for the Raspberry PI here
This boots on a Raspberry PI 2 /3 /3+ and 4
You can download a image for U-boot based boards here
Here is a writeup of an example to write U-boot to a SD-card.
An experimental (1) image for aarch64 is also available here
To get some traction on aarch64 it will boot on U-Boot based boards supported by recent mainline kernel, which includes a Raspberry PI 3 and 3+.
(Note for the RPI you are much better of with the 32bit kernel /OS !)
Be patient @ first-boot: on a RPI 2 it took near 4 minutes to finish the system-init (on RPI 4 just 1:40 though…)
nethserver’s gpg-key is not imported properly. After you finished first-config- wizard, you can import those by running :
yum makecache -y
While you are on the command prompt anyways you may want to expand the rootfs to use the hole SD_Card by running :
Nethserver-cockpit awaits testers! (please share your results here)
yum --enablerepo=nethserver-testing install nethserver-cockpit
Nethserver-cockpit is released in 7.7 updates and awaits feedback/contributions!
yum install nethserver-cockpit
experimental nature of the aarch64 image
First of all notable, nothing to do with the supplied image, ATM aarch64-epel is unmaintained. And this can be problematic as Nethserver heavily depends on packages form EPEL.
Second, CentOS does not support el7 on Single Board Computers. And there for the (RHEL based) kernel is not compiled with the bits and pieces, such as device trees, to accommodate SBC’s.
Hence this aarch64 image run a kernel one-on-none build from Fedora sources. And because in every kernel release there are arm/arm64 enhancements we run a fairly new kernel
We also need to help grubby a bit with installing new kernels. Grubby has no knowledge of device trees and therefore a aarch64-img-extra-config package is installed with some helper scripts which updates links to the most recent device trees.
To accommodate U-boot autoboot which sould load the Centos gurb2-efi stub we need to patch u-boot to look for
grubaa64.efi in the centos specific location
efi/centos/ on the first fat32 partition.
here is the applied pacht to u-boot and my commit to the spec-file
Al of the above can be found @ https://github.com/markVnl/centos-sbc-tools
and tare installed from this copr repository
If you have a look at
/root/anaconda-ks.cfg you see the need to workaround some quirks because the tools used predate aarch64 (and newer versions are based on dnf)
A known issue on a rpi 3 / 3+ it can ake a awful lot of time for the gub2-uefi-stub to load the kernel. it seems to be dead in the water but be patient for the kernel to boot. Suggestions are welcome, I ran out of them…
@davide_marini @Amygos would you give it a try!?
Tested the pi image on Raspberry 3 and 4 and it works like a charm. Great work!
Nethserver-cockpit works well in first tests even on the Rpi3.
Configured wifi, installed some software, did a backup. All went well so far.
I’m closing the uploads for 7.6 to
@mark_nl, before doing that we could release the
nethserver-subscription-inventory package for ARM/7.6 upgrades to 7.7. Do you think it’s worth the effort?
Yes sure it is worth to do this, and from a arm perspective it is tested and works as expected, including the impossibility to register a non x86_64 installation.
Moreover if we want to encourage people to merge some little (visual) arm quirks in the main code-base of cockpit it is a nice gesture if there is a installable base to work from.
As we are approaching the release of ARM images I was wondering if we’d like to improve the web site and documentation for ARM users!
I’d like to follow what we have for x86_64: download links in
www.nethserver.org, install instructions in the admin’s manual.
As alternative we could go on with
wiki.nethserver.org, by setting up an “ARM download page”, one or more install instructions pages, and finally link them form
What do you think? Who want to contribute to the documentation for ARM?
Let’s say it’s a known issue I have troubles with documentation:
Main reason not native english speaker and dyslectic.
Contributions are more than welcome,
(even if I have to deliver a raw draft which someone can edit into a understandable reading)
You have to.
I’m glad to write down the manual page, but I need someone that tests your draft!
Finally, I count on you both to review my PR to the docs
Oh, @mrmarkuz don’t get out here you’re invited to the party. Of course!
@mark_nl, do you think we can provide a page similar to Installation — NethServer 7 Final?
I mean both with “Install from image” and “Install on CentOS (arm)” sections?
sorry for late… tested on:
- new image on rpi3b all ok
- upgrade of aarch64 on VM all ok (installed also cockpit)
- upgrade of aarch64 on odroid c2 (i had to download and install manually the nethserver-subscription-* from 7.7 testing) and installed cockpit, all ok
- upgrade of armhfp on odroid hc1 (i had to download and install manually the nethserver-subscription-* from 7.7 testing) all ok
@davidep @mark_nl yes you know i’m really interested but i’m little bit busy at work, but count on me…
nethserver-subscription-inventory-3.5.1-1.ns7 released in nethserver-updates 7.7 armhfp & aarch64
Now it is possible to install nethserver-cockpit on arm:
yum install nethserver-cockpit
Note: you can not subcribe a arm system becaurce it is a community effort;
If you try it will fail with:
Validation failed: Invalid secret
armhfp U-boot RC1 image is also available
sorry for bumping this up again
Should the final images include netherver-cockpit ?
we follow “upstream” x86_64
Image gets heavier; about 100 packages (did not check the installed footprint in MB’s )
Do not install nethserver-cockpit on image, let it appear in software center.
IMHO “Alt” but easily persuaded to do else.
I see no alternative to it
I think it should be included. The new server manager runs smoothly on raspi 3 and already has some features (like multi-backup or mail groups) that are not included in old server manager.
Did you try GitHub releases? Sign in to GitHub · GitHub
…it could be great for development images!
We can upload final images to SourceForge.
Is there a disk space issue with it?
A year ago, did they drop the MB limit?