laibsch

Thank you for the nudge. But who are you nudging? It isn't up to the PR author (me) to get this accepted. It's been rotting away since nobody actually tested it. And that could only be done by people who have the device, including @The Tall Man, I believe or others. I do not have access to the device(s) in question. And then one of the other devs needs to accept it. I'm happy to rebase or respond to reviews, but that hadn't happened, so we are now going in circles. So, the question is really who you are nudging.

Thank you for that additional information, Igor. The lack of desktop images is only a minor inconvenience, I'd say. Easy enough to install the required packages after installation of the base image to the SBC itself.

We support Armbian software but not random software from the internet. RKdevtool is as far as I know a tool from Radxa, not Armbian, either. CPU boxes are cheap and cheap for a reason. Nobody really supports them. We give some very limited community support here. With your current random software this is not the right spot for you. Best of luck to you.

I retried that image now but with a different installation method, booting into OOWOW (?) via the Function+Reset button, control via serial debug console. I then wget the image from my local server and dd out to /dev/mmcblock0. Subsequent boot was indeed successful.

Thank you, @c0rnelius. I might do that. But I believe that in fact, the images are faulty (and hence should be replaced). Can you confirm to boot successfully from any of the ones I marked as broken?

Today's Khadas-supplied Armbian Trixie image works but gives out a warning that it is intended only for developers and not for production. sha256sum: f4a3038ce2f3b67151ceab10d6cb075939262956995038d23d1527fe74fd08d9

Yes, the more recent Khadas-supplied image also fails to boot. The unit came with Android flashed from the factory and that image worked fine (but was ugly and I do not know which one it was exactly). Trying to install an Android or Ubuntu image via their OOWOW service also failed but at the time I did not log it via serial console. Maybe it is to do with the changes in VIM4 New? Maybe it is a Ubuntu issue? At this point, I cannot say for sure, yet. I believe I can say with a fair degree of certainty that recent images from both Armbian and Khadas are broken. Other users have reported similar experiences. I am currently going through all kinds of images to see if they work or not. @c0rnelius was kind enough to provide me with a trixie-based, self-compiled image and that one worked, too. He also did not have any issues with other images, but I believe he did not try Android or Ubuntu images, but only Trixie and Coreelec ones. I believe I tried at one point a self-compiled Ubuntu image and that also did not work. Again, I did not get a serial console log for that one.

@Igor is probably in the best position to answer when a new image for your board might be available. This is actually fairly easy to do by building your own image: "git clone https://github.com/armbian/build.git;cd build;./compile.sh" https://docs.armbian.com/Developer-Guide_Building-with-Docker/ https://evilolaf.github.io/docupreview/Developer-Guide_Build-Preparation/ https://www.youtube.com/watch?v=kQcEFsXEJEE

Here's a very old image that worked.

no boot for Khadas-supplied Fenix 24.04.1.6.9 image, either. sha256sum: e89b80b7777fed524651b98d04e8afc0406fee76e4c5f9ccf4457df4fb6d9054

The latest Armbian IoT image for Khadas VIM4 does not boot. sha256sum: 69b10797369fd572d590aeb0dd7b28a4ebc5882cec8db8daf592db7b158bf141 Here is the log from the serial debug console.

I suggest booting from µSD and then making a copy of eMMC to somewhere and reinstall after that. You can then restore whatever you need from your eMMC backup. Most likely that will be vastly less headache and much higher chances of success.

It may or may not work to use a Tinkerboard image for your Chromebook. Same processor or manufacturer does not mean much, though, in terms of compatibility.

unfortunately, your board has no maintainer in Armbian, it is only supported by the community

what version of OS are you guys running? are you possibly affected by the hardening of fancontrol in trixie?

Why would you think that?

this can easily be answered with a quick web search or AI request for "disadvantage of LPAE on armhf". As expected, one of the drawbacks is increased use of memory when the benefit of larger addressable memory applies only to few installations and in a limited way.

OK, this is the line that is problematic. You need to find out why sda2 is mounted read-only. Go through the logs, for example "sudo grep sda2 /var/log/syslog". If you can, boot from a different medium and fsck sda2.

They certainly did fork armbian, apparently at tag v24.11.1 AKA dd379da888f7d114f9f954d94a7ebcf261d179e5 $ git merge-base dd379da888f7d114f9f954d94a7ebcf261d179e5 main 017549347bb8c278a067d1be14c2f1b3538690c2 Add the Olimex repo as a remote and then rebase the latest armbian/build HEAD to their HEAD.

@Dann https://dl.armbian.com/rock-5b-plus/Noble_vendor_gnome verifies fine for me. Try https://netcup-03.armbian.com/dl/rock-5b-plus/archive/Armbian_25.5.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img.xz and https://netcup-03.armbian.com/dl/rock-5b-plus/archive/Armbian_25.5.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img.xz.sha

show the output of "mount|grep ro"

You can add APA to your system and as one of the benefits get a managed GPG key so you should not run into this issue again in the future.

Or simply add whatever packages you desire with apt.

"apt policy ffmpeg" FTW ;-) apt also has a command-line option to force the installation of a particular package version. To automate this, you can put a file under /etc/apt/preferences.d/

Thank you for your work, @dg4gg8cb9s