Heisath

You will have to check the home-assistant documentation on how to remove it completely. armbian-config/softy does not have a remove feature build in. See also:

For bootable sd card, I'd just burn a fresh armbian image and rsync the original filesystem in there. This way you have an easy spare. Or you could try to shrink your partition before doing the dd.

Can always use rsync to just copy the files of the root. Theres plenty of tutorials on how to backup your root drive with rsync. I use something like: rsync -aAXh --stats --info=progress2 --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*/*","/media/*","/lost+found"} / <TARGET_DIR>

@Mangix probably not, if he hasn't used it for a few months. @pierre LED 8 is the power led, if nothing else shows (not even LED1 / 2 which are system / error) I'd assume your board is not even starting and your SD card might be corrupt. For further debugging you'll need to attach a computer to the micro usb and listen with some serial terminal to the output (and post it here). Or you could burn another SD card and try with that one. For LED meaning: https://wiki.kobol.io/helios4/hardware/ For Setup (also includes connecting serial terminal): https://wiki.kobol.io/helios4/install/

Maybe find a docker image then with Debian and MariaDB?

This seems to be a OMV specific problem. I just checked my clearfogpro with Armbian (Debian Buster) and it reports MariaDB 10.3: user@cfp-router:~# apt list --installed | grep maria WARNING: apt does not have a stable CLI interface. Use with caution in scripts. libmariadbclient18/now 10.1.41-0+deb9u1 armhf [installed,local] mariadb-backup/stable,now 1:10.3.27-0+deb10u1 armhf [installed] mariadb-client-10.3/stable,now 1:10.3.27-0+deb10u1 armhf [installed,automatic] mariadb-client-core-10.3/stable,now 1:10.3.27-0+deb10u1 armhf [installed,automatic] mariadb-common/stable,now 1:10.3.27-0+deb10u1 all [installed,automatic] mariadb-server-10.3/stable,now 1:10.3.27-0+deb10u1 armhf [installed,automatic] mariadb-server-core-10.3/stable,now 1:10.3.27-0+deb10u1 armhf [installed,automatic] mariadb-server/stable,now 1:10.3.27-0+deb10u1 all [installed] So it should absolutely be possible to also go to higher versions on helios4. I've never used OMV so not sure if you can just update your packages with APT or might break some thing, maybe poke the OMV guys more or risk it? This is also confusing me, I though OMV was going on top of Debian? Why is it using a ubuntu package?

Great that you found & fixed it so quickly. If you add the patch via PR please include a mention (in the patch) about the upstream fixed version, so we can easily identify and remember to remove the patch again once we reach 5.11+

Does this only work on full PRs or also on Draft PR? It should only be included on full PR imho.

This seems like a SD card corruption problem. The UUID was always the long one (check any other clean installed device). And it did not get extended but rather the value in fstab got shortened! Regarding the "(in my sight) the same text" maybe unprintable characters had been added by sd card corruption? This is not the first time something like this has occured, I remember posts about corruption in /boot/armbianEnv.txt for example (recently had this myself when often unplugging power from bananapi w/o shutdown). For reference, my fstab and blkid output: root@####:~# cat /etc/fstab UUID=c4b74654-b71b-44c9-9303-e7f9ca15211d / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 root@####:~# blkid /dev/sda1 /dev/sda1: UUID="c4b74654-b71b-44c9-9303-e7f9ca15211d" TYPE="ext4" PARTUUID="b122e6b0-01"

Is it just me, or did we have the exact same question a few weeks/month ago already? EDIT: Found it!

One solution (without upgrading) would be to wait one or two month. The next armbian release is scheduled for February and will basically include all features currently on -dev (nightly). At least for mvebu. So the openssh server should also be updated then. Although I'm curious how you got openssh-server to 8.4 just by switching to nightly? I'm running a clearfogpro with nightly and still am at 7.9... If you need it faster, you can adjust your apt sources to include an apt with a newer version of openssh.

Yes that is old and only limited switch capability given. Correct that thread is pretty up-to-date. I have received the boards and confirmed the Power and Serial Mux is working (with minor changes). Currently we are developing the firmware for the sdcard muxer (STM32 based). The hardware of the sdcard mux seems good, I was able to connect a sd card to USB (and read with PC) and also to some SBC and boot it with reasonable fast speeds. The current step is advancing the firmware so it is possible to select which SD card to mux where via USB or I2C. You can check the state on the github https://github.com/armbian/mpads

Ah but that might matter for the clearfog. Remember armbian supports more than only the helios4. The mvebu patches we've removed also affect clearfogbase & pro. So if I understand correctly we need this patch again? https://github.com/armbian/build/commit/15cb0f6e3f688d60a4565079468d9c7fd6b2f7a3#diff-0e2d5f1c7cffdc7dfa0c8bb8730d65ee262430d835a454ba5b0046dcb907800a

@FredK the PR has been merged. Maybe @Igor can give a little notice here, once the next bugfix debs are released?

@FredKout of curiosity, did you just replace the PSU? And you're doing the same high I/O tasks as before? The updates are underway, PR need to be approved, merged and debs rebuild. Probably today.

Looks nice, but do we need another plattform / bugtracker? We already have forum, github issues, github project / teams, jira. Although nobody seems to use the github project/teams stuff anymore.

Yeah that is the reason why it was not removed until now. No one complained. Armbian is past LK4.19 for a longer while (hell there even was a complete 5.4 release) and no one seems to have any issues. Igor, gprovost and myself all use Helios4 / clearfogpro on a daily basis (as NAS or whatever) and do not have / are unable to reproduce these problems... I think there are just many specific factors under which the DFS stuff causes problems.

Once the above PR has been merged and a bugfix release has been done. We can inform you then.

Okay if btrfs scrub works without the patches situation is clear. Thank you for your help! This disables DFS on legacy and current: https://github.com/armbian/build/pull/2387

I just merged the PR, so we now have DFS with the old patches on legacy&current and the new apparently better patches on dev. You mentioned these new patches also freeze but only with btrfs scrub. Can you do one more test? Compare 'btrfs scrub' without DFS vs. 'btrfs scrub' with the new patches? This should then give definitive answer.

I also assume these new patches have the same problem. But as some lines have changed they might be better adjusted to newer kernels. Because the DFS patches in general were already in 4.14, 4.19 etc. and as you had no problems prior to a specific 4.19 version, it is not "just" a problem with the patches but more a problem with the patches after a specific kernel version. So I assume the DFS patches don't fit as good anymore. In any case I'd like to be sure that DFS is not stable for mainline (and not just because of outdated patches) before we remove it.

Just in case you misunderstood: I do not want to send any PR to OpenWRT. I am only asking you (as you have a reliable way of crashing) to test once without any DFS patches at all. And once with the OpenWRT DFS patches, which I added to AR-526.

I have updated our DFS patches with the OpenWRT ones. There were some small differences (probably not functional ones). The build compiles, dfs works and there is no time drift. As @Mangix has a reliable way of causing a hang it would be great if you could build a image based on the PR and test if the openwrt patches still cause the crashes. Afterwards I will either make a PR to remove the patches for legacy&current or update the patches there to OWRT also

Yeah might be the best way. If we just remove the patches on legacy & current, I assume all the existing systems will keep working but at max clock? I'd like to leave the patches in on dev to further test.

Yeah these seem to be the exactly same. Only difference is their way of disabling the global timer. We remove the DT node, they disable the compilation. Our way: https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/fix_time_drift_remove_global_timer.patch Their way: https://github.com/hnyman/openwrt/commit/90113cd70f33449a68827e63501dcc688c14d007#diff-b7a0f3497875655ca3abc14fb540ca45c913b347a8b2c1efa2ae91b4fa5d9b39 EDIT: From the commit msg: "Note: upstream messages mention possible instability under heavy I/O."