lanefu

Hows this

Hows this

I'd be happy to assist with Pinebook Pro maintenance. github.com/seclorum
 

Go @lanefu!
Go @NicoD!

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.