mrjpaxton

Okay, so I finally did it this Friday. I did the expose eMMC steps - https://wiki.kobol.io/helios64/install/emmc/
 
(Somebody will probably have to mirror that link and the eMMC SD-Card exposure image if those instructions and files ever come Offline for good.)
 
I'm also going to report that it all works just fine. I connected it with Picocom afterwards over USB-C with `picocom -b 1500000 /dev/ttyUSB0`, boots up fine, got a login prompt, did the Armbian initial setup stuff like setting up root password, a user password, which was different from last time I think, and then shell, etc...
 
Now I'm in the long-haul process of meticulously restoring my config backups one by one from my old install, got SSH quickly set up again so I could disconnect the serial cable, double-checking them to make sure my static mounts will still work, my personal user scripts still run, and everything else still works without too many errors. I'm going to install more packages, set up Systemd's networking stack (networkd/resolved) the way I want, the Btrfs array, then NFS, and finally, maybe I'll even try to set up extras that I can't remember right now, like maybe disabling the ZRAM if it becomes a problem. Because usually the 4 GB of regular RAM is enough.
 
So far, yes, everything is working great. I'll report back with any problems I run into.

We set maintainership conditions pretty low - he/she doesn't need to fix any low level troubles, keeping a list of them is already a great value or taking such burden away. As I am not paying attention to this hardware (to remain sane) I didn't notice there were no images at all, while we usually provide images for community/no supported targets too.
 
Images would be up, but one bug prevent them from building correctly - you can build then on your own, but they fail to build in automation.

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.

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.