lampra

Try root@cubietruck:~# apt-cache search armbian-bsp-cli-cubietruck armbian-bsp-cli-cubietruck - Tweaks for Armbian bullseye on cubietruck If it exists, you could try apt remove armbian-bsp-cli-cubietruck && apt install armbian-bsp-cli-cubietruck

Probably this needs to be uninstalled and reinstalled manually

For the welcome message, If this is an updated old installation (like mine from 2016) IIRW, you might need to manually uninstall an armbian package and reinstall it. What is the output of dpkg -l | grep -i armbian mine is below, and the welcome message is correct: root@cubietruck:~# dpkg -l | grep -i armbian hi armbian-bsp-cli-cubietruck 21.08.2 armhf Tweaks for Armbian bullseye on cubietruck ii armbian-config 21.11.0-trunk.85 all Armbian configuration utility hi armbian-firmware-full 21.08.6 all Linux firmware-full ii hostapd 3:2.9-102~armbian21.05.1+1 armhf IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator ii htop 3.1.0-0~armbian20.08.2+1 armhf interactive processes viewer ii linux-libc-dev:armhf 21.08.6 armhf Armbian Linux support headers for userspace development

Try apt update 3-4 times and new packages will come up. If I understand correctly, each time it will update from a different repo. I did this today and at the 3rd repo (imola.... something) new packages showed up. Though I did not start the upgrade yet. If you upgrade, let us know how it went.

Yes. I expect that the maintainer (@krachlatte) or someone else could send a PR

From your output, It is not obvious to me, If the limit is honored. Here is my output. It is clearly stated that runtime journal is 22.6M, max 20.1M, 0B free.: root@cubietruck:~# systemctl status systemd-journald.service ● systemd-journald.service - Journal Service Loaded: loaded (/lib/systemd/system/systemd-journald.service; static) Drop-In: /lib/systemd/system/systemd-journald.service.d └─override.conf Active: active (running) since Wed 2022-01-12 17:02:10 EET; 1 months 5 days ago TriggeredBy: ● systemd-journald-audit.socket ● systemd-journald-dev-log.socket ● systemd-journald.socket Docs: man:systemd-journald.service(8) man:journald.conf(5) Main PID: 547 (systemd-journal) Status: "Processing requests..." Tasks: 1 (limit: 4569) Memory: 13.3M CPU: 3min 45.567s CGroup: /system.slice/systemd-journald.service └─547 /lib/systemd/systemd-journald Feb 16 17:11:22 cubietruck systemd-journald[547]: Runtime Journal (/run/log/journal/b1762bb2a9d8431a988c6cac5ff8f356) is 22.6M, max 20.1M, 0B free. Warning: journal has been rotated since unit was started, output may be incomplete. and here is my doubled zram Filesystem Size Used Avail Use% Mounted on /dev/zram1 97M 18M 73M 20% /var/log

Maybe you could check if zram size (using: df -h) and journal max limit (using: systemctl status systemd-journald.service ) are honored. Then you could examine the logs and check if something is flooding the journal. That was the case in one of my boards.

Sorry, I do not remember exactly. Check at `/etc/systemd/journald.conf` the `SystemMaxUse`. My setting is 20M When using `vacuum-size` Just remember that journal logs are located both at `/var/log/journal` (zram) and `/var/log.hdd/journal`

In my case, not on espressobin, I doubled zram and still had these errors. Then I had to instruct journal to a max (eg. 10-20 mb) and the errors stopped. ps: @y52 did you try u-boot from openwrt for espressobin? It seems that it supports distroboot so probably vanilla debian out of the box

Yes Armbian, Ubuntu flavor can use overlayroot. https://unix.stackexchange.com/questions/155784/advantages-disadvantages-of-increasing-commit-in-fstab

How about wifi and bluetooth? Do these work?

This will only check, but it will not repair. As they use Ubuntu, they should probably consider `overlayroot` To my knowledge, by default, armbian uses `commit=600` in fstab to minimize corruption probability

To my knowledge, this option is available in armbian-config only for Ubuntu builds

Just for the record here is the first "release" message archived! https://web.archive.org/web/20140102083415/http://www.cubieforums.com/index.php/topic,1275.0.html

Check the device tree. Only one change was needed https://github.com/jernejsk/linux-1/commit/acb0d7a34dd77ed84228478f5ffb3479a3118fed I changed this in my board using armian-config `Welcome to Armbian 21.08.2 Focal with bleeding edge Linux 5.14.8-sunxi64` and reboot works

I do not have any other A20 board. I will ask around my colleagues for a spare one. Though If indeed there is a spare cubietruck to be provided by any forum member I would gladly help maintain this board.

Thank you for the clarifications. I do build my images or kernels from time to time, but what about newer kernel version patches? How will this work? Maybe it's not clear to me the meaning of CSC. Regarding LTS kernels, at least, say 5.10 with expected EOL in 2026, who is going to submit patches for newer kernel versions if there is no maintainer? Does this mean that if no one submits patches, the kernel will become stale?

I can clearly see the point for the maintainers, but there is an issue with the old boards. For example, I have a cubietruck which I would definitely like it to keep being supported, and I could probably help to maintain it within Armbian. Though I do have only one board which works 24/7. To my understanding, I can not be a maintainer, as I can't test new releases on a productive board. So If no one has two pieces, then the board can not be supported. In this case, I expect that current owners have to freeze kernel updates and keep the board for some more months - years, or try to test and use plain Debian or other distros. Is there any other alternative?

I use this script except the three last lines. For 1wire you could use this module, but you need to build it. For me it works

I doubt that the maintainer tracks all discussions here. So for your benefit in the future and the benefit of the community, if you could spare some minutes (after the "next" days), go ahead and check the sources. If this is not already fixed there you could open an issue in GitHub linking here or, if you have the skills, send a pull request that resolves this issue (i.e. deletes the line).

Not sure what you mean, but `armbian-config` provides experimental device tree editor. So if the difference is one added line, what happens if you delete this line in the current device tree using the editor?

You can find here the uboot binaries from armbian and here the boot.cmd-src. I expect that they are no longer maintained. The binaries from openwrt should be compatible with armbian, I expect that you will need to use the armbian boot.cmd-src though, or modify it according to your needs and boot environment as described here. PS: Could you post here your current uboot version, your boot.cmd and your current uboot environment?

I used the Debian manual to upgrade from Stretch to Buster but not on espressobin. You may face some minor issues with python (from 2.7 to 3) but nothing very serious on the system itself. Though, you need to check first the dependencies of other software that you have installed.IIRW, I had some issues with owncloud which I had installed before the nextcloud fork. There is also a major upgrade of uboot and boot.cmd on recent builds so you might need to flash the latest uboot also Are you booting from the sd card or from sata? You could probably try first with a dual boot system i e. set the priority in the uboot environmental variables and test the new builds for some time before upgrading your current system. Or you could keep your current system as is and try to setup/install the needed software on a new (eg 21.08) release and use dualboot if needed. About the stability, I also had issues on my v5 board, so I moved to openwrt 19.07 which is rock solid using overlay but of limited abilities. I am planning a test migration back to armbian in the next months now that the mainline kernel includes the recent patches. Openwrt has also produced uboot builds (look at the supplementary files) for recent distros

My guess is that there might be some issue with the latest uboot. Similar issues were experienced previously here, but no clue of the source.

I see some recent changes in the dts https://github.com/armbian/build/pull/3117/commits/a215617b78a05b5895e5eaca14b974d5968178de but probably nothing to do with sata. I also see that you have not installed the uboot package Can you provide the output of: cat /boot/armbianEnv.txt strings /boot/boot.scr strings /dev/mmcblk0 | grep "^U-Boot.*(" You might need to interrupt the last command (press Ctrl c) after a few lines of output