yes, i’m following it but from what i know, actually only very nice and very expensive enterprise-class ARMv8 board are fully supported.
ordroid-c2 and pine64 are community supported at the moment, but i have only a rpi3 maybe it’s time tu buy an ordroid…
please report back, and please have patience, i really am short on time
tested only on rpi2 (i’ve left in the repo the aarch64 files but i didn’t have hardware to test)
tnx
Yes this is just perfect, I’ll try it in the next few days on my RPi 3.
I tried OpenMediaVault with OwnCloud and a nextcloud ubuntu image from here but bot were lacking in speed an stability.
If this works well it could be the solution to my problem (many mobile users taking photos, needing backup)
I am also interested in using Nethserver with a Arm based SoC (a Banana / Lamobo BPi-R1) but do to other commitments, I am going have to put this project on the back burner for a while.
Yes, great work, thanks. Came in handy today
Did a reinstall from scratch on my RPi3, flashed the image and resized the partitions on the SD with computer and copied my tweaked board settings config.txt (and remove swap partition and fstab entry while I was at it).
Boot up on the RPi, login and update … failed to get some firmware packages (userland’s fault?). Manually downloaded and localinstall-ed affected packages and update went through.
Installed nextcloud and webserver from the servermanager. I’ll have to connect some disks and shares and remount them in proper places, but thats for my next adventure
Also the dashboard patch is great
Nice job, works quite well from what I’m seeing. This is going to be in a demo for some Electronic Fairs and other local events in which we will show RPis and other platforms (I have a Pine64 and also some Onion Omegas).
Unfortunately 1611 image for arm7l lacks firmware for the Broadcom Wireless interface (shame). I found someone that managed to find all the needed files and put together a script, so:
So this has to be done before the mini-wireless howto put up from @mark_nl and my additional information on auto-starting wpa_supplicant. Run the script, reboot, then go on with the mini-howto. Add my commands, then enjoy your wireless interface going up on boot
I didn’t leave it up for so long, so I cannot say it is behaving the same.
I can see is that after 2 hours up the RAM is nearly filled (924 MB used, 11 free); it can be OK (unused RAM is wasted money), unless it really hangs.
Last week it was up and running for about 6-7 hours with no issues.
I will let you know; during the weekend it is going to be up for a lot more hours.
After analysing the partitions that CentOS creates during the installation process / writing the image to a SD card, I noticed that the CentOS image creates a swap partition that is only 512M in size.
I am now wondering if, increasing the size of the swap partition (using either SUSE Yast partitioning tools, Gparted or some other partition tool that supports both Linux based file system formats and that can resize these partitions) to 2.5 GB (ie. increasing the swap partition to be no larger then 1.5 times the size of the actual physical RAM) and then increasing the ‘swappiness’ be changing vm.swappiness variable within /etc/sysctl.conf could resolve the memory limitations of the RPI3.
Obviously, using the above method would slow down read/write access to the RAM (as the RPI3 is now using a SD medium to act as virtual memory, which is slower then actual physical RAM), but theoretically, this should give the RPI3 an increase the RAM of up to an extra 2.5GB (resulting in 3.5GB of accessible RAM).
On a side note, does anybody know if there is a ARM branch of CentOS’s EPEL repository (as far as I can deduce, EPEL is only available for x86 / x86-64 architectures)?