lanefu

Even though Ansible is not going to cut it we are open for suggestions in any case
 

we probably need to remove the desktop-install feature from Armbian-config.. we have new code for our more complex desktops and its not in armbian config.

Thankfully there is the -U fallback option

The "Invalid" tag is cancer.  That needs to be "Off-topic", "Out of scope", "needs clarification" or something else.
 
Honestly we are actively rebranding ourselves as a toxic community at a terrifying rate.

Hi, newbie here.
 
I would like to help with those tests, and maybe with Ansible. But I'm new in that, so I will try to learn and help. I learning linux, so I will try to learn bash to help you guys, and because it is usefull skill for linux.
I've got the Rock pi S, Rasp. pi 3b+, rock pi X to try some tests.

Hey,
 
I have uninstalled cron from my system completely, but I just thought I might help contribute, even just a little, by making some services and timer files to replace the ones in these folders:
 
/etc/cron.d /etc/cron.daily /etc/cron.hourly /etc/cron.weekly  
Now keep in mind that I have not fully tested any of these yet! I would appreciate feedback in testing these, since most of these I won't even use on my system. I barely even use the armbian-config utility at all, so... yeah...
 
The files in question are these. Let me know if I should add more:
 
armbian-truncate-logs armbian-updates armbian-ram-logging  
These are the Armbian specific ones. I know there's ones for like man-db, mdadm, logrotate, fake-hwclock and a bunch more that get installed by default. And I think systemd already has timer files for some of these. In fact, here's the timers in use on my Kobol system right now:
 
# systemctl list-timers NEXT LEFT LAST PASSED UNIT ACTIVATES Sat 2021-09-11 18:43:28 PDT 13min left Fri 2021-09-10 18:43:28 PDT 23h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago logrotate.timer logrotate.service Sun 2021-09-12 00:00:00 PDT 5h 29min left Sat 2021-09-11 04:38:49 PDT 13h ago man-db.timer man-db.service Sun 2021-09-12 05:57:58 PDT 11h left Sat 2021-09-11 17:25:28 PDT 1h 4min ago apt-daily.timer apt-daily.service Sun 2021-09-12 06:20:19 PDT 11h left Sat 2021-09-11 06:59:08 PDT 11h ago apt-daily-upgrade.timer apt-daily-upgrade.service n/a n/a Sat 2021-09-11 05:57:28 PDT 12h ago update-ddns.timer update-ddns.service 6 timers listed. Pass --all to see loaded but inactive timers, too.  
The "update-ddns" timer and service is my own custom one. The rest are defaults.
 
So we'll start in order of shortest to longest activation times:
 
armbian-truncate-logs (runs every 15 minutes)
 
/etc/systemd/system/armbian-truncate-logs.timer
[Unit] Wants=armbian-truncate-logs.service [Timer] OnActiveSec=15m [Install] WantedBy=timers.target  
/etc/systemd/system/armbian-truncate-logs.service
[Unit] Description=Truncate the Armbian log files [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-truncate-logs [Install] WantedBy=multi-user.target  
armbian-updates (runs daily and on boot up)
Note: We are going to change this to run after the network is brought Online, but still make it run daily.
 
/etc/systemd/system/armbian-updates.timer
[Unit] Wants=armbian-updates.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target  
/etc/systemd/system/armbian-updates.service
[Unit] Description=Check for updates on the Armbian system After=network-online.target [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-apt-updates [Install] WantedBy=multi-user.target  
armbian-ram-logging (runs daily)
Note: It is mentioned that this cron job should only run when logrotate is a cron job. This was confusing wording at first, because it doesn't tell you if it prefers to either have logrotate as a systemd timer, or if logrotate should not run at all.
 
After looking inside the script "/usr/lib/armbian/armbian-ramlog", which passes "write" as the first argument, I tried to see if there was any problematic code that conflicts with logrotate...
 
Using the "syncToDisk ()" function, it doesn't seem like it'd conflict with logrotate at first glance.
 
Just to be safe, I've included the line "Conflicts=logrotate.service" just in case. If this can be safely removed, let me know.
 
/etc/systemd/system/armbian-ram-logging.timer
[Unit] Wants=armbian-ram-logging.service [Timer] OnCalendar=daily Persistent=true [Install] WantedBy=timers.target  
/etc/systemd/system/armbian-ram-logging.service
[Unit] Description=Perform Armbian RAM logging Conflicts=logrotate.service [Service] Type=oneshot ExecStart=/usr/lib/armbian/armbian-ramlog write [Install] WantedBy=multi-user.target  
---
 
That's about it. Again, not sure if any of these should be set to "oneshot" or "simple" services, or if they need to be active "RemainOnExit" or whatnot. Just hope I can give a good template for converting cron jobs to systemd timers. It's a lot simpler than I thought to convert them.
 
Have a wonderful day, Armbian team. And thank you for all you contribute to this project.

Done.

I have slightly different approach to going's solution, but this would be compatible with it
 
 

Really ?
If you are on macOS Big Sur all the drivers and apps are already there. If you need to access the serial console of your Helios64, just connect your mac to the USB-C port of your Helios64. A device such as  /dev/tty.usbserial-XXXXXXXX will be recognised by macOS. All you need to do then is to enter the following into the Terminal of your mac (X to be replaced):
 
screen /dev/tty.usbserial-XXXXXXXX 1500000 -L  
Edit: If the 'screen' command on macOS does not show the output of the bootloader (scrambled characters) you could use the app serial. The only thing you need to configure is to set the serial speed manually to 1500000 bps.
 
If someone would like to contribute in kernel testing - the Armbian build system is very easy to install and use. All you need is an Ubuntu 21.04 (amd64) installation. All the rest is explained here. To compile your own kernel is then as simple as this:
./compile.sh BOARD=helios64 BRANCH=current KERNEL_ONLY=yes RELEASE=bullseye  

@Igor, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)?
That way we can participate on the QA process and help raise flags when pre-released changes break the stable builds.
I understand that you do not have an Helios64 to test, and so as part of the community we should be able to help in that regard.

Well, here's my issue. I'd like to explain it.
 
The problem was I wasn't even doing a full upgrade. I was just using "apt update; apt upgrade", and upgrading the system normally.
So if even a normal upgrade breaks the system, there's something seriously wrong here...
 
I don't know much about Debian's policies, but I do know a full distribution upgrade should only be done with "apt dist-upgrade" or "apt full-upgrade", and this policy wasn't respected. It would have been fine if the latest rockchip64 kernel image was held back before the upgrade, so that it had time to get bug fixes.
 
Also, the version numbering is confusing. The version for "linux-image-current-rockchip64" is set to "21.08.01", but that's not what version the kernel is. Shouldn't it be "5.10.60-rockchip64". That might have helped me avoid this problem altogether, so at least I'd know what version of the kernel I was about to install. In other words, I had no idea "21.08.01" had the broken kernel "5.10.60-rockchip64".
 
I know Armbian is different than Debian, but it really should play more nicely to what regular Debian users are used to, rather than deviating too much from it. It's one of the reasons why I chose Armbian! It is because I expected it 99% to work like Debian, except maybe for the fact that it uses a different kernel, DTD, maybe a BSP (base support package), U-Boot, and a few necessary patches.
 
But changing how core OS updates and upgrades work is just wrong to me.
 
A side note, I know U-Boot isn't GRUB, but it really would be nice to have support for multiple (backup) kernels like I'm used to on x86 with GRUB. It is different code, and a different arch, so I guess that makes sense though...
 
Still a shame. I will look around and see if the solutions work. Otherwise, I'll try to use my full rsync backup.

Armbian "current" (5.10.y) compiles without issues.
I second @Igor's opinion that a change somewhere in this diff broke the eMMC.
I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.
 
However I did find that with the unit I have the issue happens only in hs400{,es} modes.
With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.
 
If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:
Upgrade the kernel to 5.10.60, but don't reboot yet.
Run:
curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb sudo reboot  
If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.
There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)
Below you can find the comparison between hs400 and hs200 modes using iozone.
 

Hi all.
I've done a collaboration with @Igor, the creator of Armbian.
He shows and talks about the hardware that is used to maintain the project. Servers, boards, other electronics, ...
Enjoy!

More videos to come.
 

Hi @lanefu - do you mean whether or not a buster or bullseye system on emmc that is updated from Armbian 21.05.4 to 21.08.1 has non matching UUIDs in the three locations ?
 
What I can tell is that boot.scr does not contain a UUID at all. The device /dev/mmcblk0p1 is specified instead (in boot.cmd) - also in the fresh Buster image on the download page.
 
UUIDs are present in /boot/armbianEnv.txt and /etc/fstab. If they are correctly set to the UUID of the root filesystem, a previous Buster 21.05.4 installation was running fine on SD and on emmc.
 
The "emmc issue" occurs after the update from 21.05.4 to 21.08.1 even if the UUIDs in /boot/armbianEnv.txt and /etc/fstab are correctly set to the UUID of the root file system on emmc.
 

I believe the -minimal images do not include armbianmonitor or armbian-confg and would probably satisfy that desire.

Something that's probably gonna keep happening if nobody is using the beta repository (nightly/edge) and reporting errors before they make it to the current version. 
FYI there is no Helios64 in Armbians testing "facility"

Howdy Igor! A workaround I found that seems to work for me, was to boot from the latest release from an SD card, and update the bootloader. It seemed to let me back in and stopped giving me the login loop i was experiencing. I am running Buster.

iozone3 is used within armbianmonitor tool. That is the reason why it comes pre-installed.

OMG that's an understatement.  Impressive article.

Armbian is a community driven project. This is not about trying to find someone to blame, but trying to solve issues by pointing to alleged sources of the trouble.
 
And indeed community support is there as you can see in this thread - it could be stronger though.
 

Armbian is an established Linux for single board computers that is used in enterprise, IOT micro services and various hobby deployments. Recent desktop improvements bring the platform on-par with key players in the Linux desktop arena while keeping the key advantage – you can easily build your own Linux distribution.
 
 
 
 
Armbian provides stable releases every three months. They are driven by CURRENT LTS kernel. Adventurers which likes rolling releases, can check EDGE releases which are using latest daily kernel builds with fresh packages from sid, hirsute or impish userland.
 
Armbian has powerful build system which can build a whole Linux distribution, an OS image or a kernel. Key advantages are simplicity, speed and excellent hardware support. Provides native or cross compilation.
 
This release is hard work of exceptional individuals who have contributed their time and expertise into this release. Many thanks to – in alphabetic order:

@balbes150 @AristoChen @belegdol @Werner@Heisath @iav @Igor @Icenowy @lanefu @jock @piter75@Rich Neese@rpardini@going @tkaiser @tparys @TonyMac32 @Azq2 @henkiejan1 @juanesf @psztoch, @redchenjs @Uglymotha

Special thanks to users and vendors @orangepi, @friendlyelec, @khadas and @olimex that understand the importance of our work and supports the project with donations of cash, hardware & expertise.

Enjoy!
 
Highlights
 
minimal, server or XFCE, Cinnamon and Budgie desktop fast and effective automated language selection on first run regular stable and daily beta & EDGE updates CLI is powered with ZSH or BASH added automated kernel upgrade on EDGE 5.13.y kernels added mainline based SPI boot support for Odroid HC4 added Qemu virtual Armbian builds added CSC images for Tinkerboard 2, Rockpi N10, added ZFS upgrade to v2.1 improved Github Actions CI and CDN network added Cinnamon and Budgie desktop enabled 3D support wherever its possible and works reasonble well added Khadas VIM1-3 & Edge boards, Avnet Microzed enabled VPU support for Rockchip added legacy kernel support for OrangepiZero2, Nvidia Jetson declare Ubuntu Hirsute and Debian Bullseye packages as stable added Ubuntu Impish and Debian Sid as beta build targets added KDE plasma DE as a beta build target
Details:
 
What’s Left
 
long term armbian-config refactoring upgrading Rockchip u-boot from 2010.y to latest resolving Allwinner boot troubles on last u-boot enable 3D on Meson G12 / SM1 infrastructure improvements: mirros, runners, publishing.  
Details:
 
Tough Decisions
 
Odroid C4/HC4 boot problem has to remain unresolved in CURRENT 5.10.y kernel since fixing it would break Khadas boards. Problem was properly solved in EDGE kernel. We had to disable 3D on latest Amlogic boards due to instability Leaving behind published Deepin, Enlightenment, Gnome, i3, KDE plasma, Mate, Xmonad desktop due to space constrains and lack of maintenance. These options are still available within the build tool.  
Known problems
 
XFCE desktop is missing package gvfs-backends and xarchiver bullseye doesn’t properly detect locales Helios64 eMMC IO errors with CURRENT kernel OrangepiZero2 EDGE kernel based image doesn’t boot. Will be fixed in bug fix release.  

Starting 5.12, no kernel patches are needed for H264. With 5.14 (due in about a week or two), only HEVC needs patches. Other supported codecs (MPEG2, VP8, H264) do not.
 
You still have to make sure that you have enough CMA memory available. 4k videos can be pretty demanding in worst case. I would suggest 256 MiB just to be on the safe side.

Interesting, but not affordable: https://www.cnet.com/tech/computing/facebook-shares-its-time-card-atomic-clock-tech-to-speed-internet-services/

At August 6, 2021, 18:04 GMT -04:00 Our VPS provider had a massive data center outage impacting multiple carriers and power.  We were offline for approximately 4.5 hours...    our apt redirect service was moved to a temporary location around 3 hours into the outage.   It's since moved back.

FYI: https://status.armbian.com provides site status info.

Prior to this our awesome VPS provider had given us 100% uptime for 13 months