laibsch

Have you looked into hosting your own deb package cache locally? You can set the MANAGE_ACNG build switch for that purpose and have a prepopulated apt-cacher-ng proxy in your LAN. Let us know how it goes.

In my opinion and experience, armbian-config is a horrible pile of hacks that are almost guaranteed to eventually eat your data. As such, in my opinion the only sane action is to stay far clear of it.

Please prepend the commands with LC_ALL=C like "LC_ALL=C apt update" and post the output again.

ping @metalhard

Thank you for that patch. Do you know how to use git and github? You don't necessarily need to open an issue first. You can go straight to pushing a PR. Just explain yourself enough so that a reviewer who may not understand your board can see why your patch should be merged in.

I am not exactly sure what you are trying to do, but maybe the solaar or logiops package can help you achieve your goal.

Thank you for your quick answer, Jimbolaya. Yes, I did try different cables all with the same result. I wonder if there is another way to access the serial console, J13 perhaps? Albeit with some required soldering, I suppose. Then remains the question of which headers exactly relate to GND, TX and RX.

I received a Helios4 and was finally able to get it to boot. As per instructions, I booted from microSD and flashed the latest Armbian image to sda1 via the nand-sata-install command. This reboots fine now, but only with the microSD-card present and the SW1 dipswitch set to "SD card boot mode". Is anybody here using "SPI NOR Flash" or "SATA1" boot mode to get rid of the microSD card? I am bit handicapped here since my serial port on the microUSB only comes up maybe 1 in 10 times. I wonder if it's worn out or if I am simply doing something wrong. Related Links: 1 2 3 4

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.