Description On every PR, a workflow is started to check if artifacts should be built. This happens not only once, but many times, e.g. for every selected reviewer. Since the workflow has cancel-in-progress enabled, workflows are started and immediately cancelled by the next one, resulting in many notifications (see https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml how many of the workflows were duplicates which were cancelled). Move the cancel-in-progress concurrency policy to the second job which starts only after a check is done if the 'Build' label is even active on the PR. This should greatly reduce "Workflow cancelled" notifications via GitHub and email (if enabled by the user). Documentation that concurrency can also be used on jobs: https://docs.github.com/en/actions/using-jobs/using-concurrency#example-using-concurrency-and-the-default-behavior Also don't start the workflow on PR 'reviewer_requested' trigger. It does not need to be started every time a single reviewer is added, since requesting a review does not change the build. If the 'Build' label was already added earlier, the build workflow will have been started already. In addition, don't run shellcheck if a PR message ot title was edited since it does not change the code at all. See doc: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=edited#pull_request How it has been tested [x] Check started workflow this PR: https://github.com/armbian/build/actions/workflows/build-artifacts-pr.yml Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code View the full article

I'm using the latest kernel from the official armbian release: Kernel version: Linux 6.1.53-current-sunxi armv7l I must say that stability and temperatures are now normal.I disabled kernel updates from armbian config Honestly, I don't want to experiment with the current release kernel, i.e. CSC 6.6.x, again. I don't want to find random crashes and loose plastic cases due to the CPU having temperatures out of control. For now the 6.1 kernel lets me run everything and is still modern.

@Erica I did a fresh install of Armbian 24.5.1 Minimal on my Khadas VIM3 Pro last night, and everything worked smoothly: https://dl.armbian.com/khadas-vim3/archive/Armbian_24.5.1_Khadas-vim3_bookworm_current_6.6.31_minimal.oowow.img.xz Did you actually erase the SPI, as Igor suggested? I was not able to do that with oowow. That gave an error about the SPI not being found. However, with krescue, the SPI was cleared out successfully. Someone else provided a link to krescue for you in the other thread, if you do not have it anymore: https://web.archive.org/web/20240426161033/https://dl.khadas.com/firmware/Krescue/system/versions/VIM3.krescue.sd.220110_266.img.gz Another thing you can try is to connect a different monitor. I think that krescue uses a text mode, while most other images around initialize a graphics mode early in the boot process. Older versions of Armbian did not send HDMI signal to my monitor once it went to graphics mode in the past. But that has been resolved now.

Yes, but there are several bcm433x variants. You have to post dmesg log.

@Khadas what are you running on your Zero now, and how is it working? I've left mine on the legacy kernel (frozen) because it was working fine, but I just ran apt upgrade and I can't ssh into it, ping mostly fails, none of the audio server stuff on it is working. Hoping that connecting it by ethernet rather than wifi will allow me in; if not I'm really hosed.