All Activity

Drop it in a Spoiler:

Hello, I will soon be selling a working Helios64 from Kobol (with 2.5G fix done from factory). I also have 3x 6TB hard drive that could come with it if needed. Based in France, I'm able to send within EU. Please DM me if interested.

Hi Nobi, I'm in a hurry therfore short hints for your investigation. Most info you get on matrix channel. https://matrix.to/#/!AT6qaz1QxylX2sw2mzjLElHbLKVll3kAgeIQd16e7J0/$dLsP9mV-fEjbokwdo-WqcJvg5CqsUaArfNKWWdUNPp0 Listen to the podcasts mentionened in this discussion. Yes, I have ny servers upodated to 31 and did the offered 1.55.4. update before, it is offered to running instances only (ssh boot prompt).

@NOBL You can select text of someones post and then a small popup appears; If you click that, a reply/edit field is provided. It also took me some time before I discovered, maybe it was a browser issue or webblocker before I don't know. Related to it, I also don't know how to create 'hidden' text files so no endless logs or so. Anyway, on the topic: I see indeed VM is only x86-64 focused and also no Linux default build-in virtualizer, only external/commercial stuff like VMware and Windows/Mac. So for nextcloud, it is worse then for HAOS as I see it now. For HAOS, there is some Aarch64 VM image hidden somewhere on github, no documentation, but it works, does update well. It is same principle as for x86-64 VM images, so for me, having used standard Linux virt-manager (libvirtd/QEMU/KVM) for several years after VirtualBox and after VMware, it was easy to get running and as HA has a good backup-restore option, you get perfectly the same In a Aarch64 VM hosted on my ROCK5B for example as something running on old Intel Atom computer (also as VM by the way). So I would consider the easy 'nextcloudpi' and ready made images gone; You have to dig deeper and do more yourself, so looking at all the lower level components like PHP versions etc that fit a certain version. That is independent of which ARM SBC. Nextcloud is high-level software, there is no dependency on HW pins or GPIO or videocodecs etc. If there are Aarch64 images, you have to look at how they are created. I see from other post that there is ncp command, so what does that do? If you stick to 'images', you will indeed have a problem. The only relevant difference between Odroid and Raspberry or other Aarch64 SBC is the bootloader and kernel. Raspberry is the worst as they also do many changes to Debian userspace which for example from bookworm to trixie ruined my networking setup, so I blocked specific things (netplan stuff) and went back to Debian versions. Also RPi5 still cannot run standard Debian. If you want standards, make sure your HW supports UEFI, same as every PC/MAC does. See https://github.com/edk2-porting/edk2-rk3588?tab=readme-ov-file#supported-platforms I have this on ROCK5B and NanoPi-R6C and it is like a PC. You have to install it yourself of course, it is not pre-installed like is the case on a PC. But after installed, it is like a PC. Both those boards I have bought with metal case/heatsink, so no fans. Faster than a RPi5 and M.2 M-key slot on-board, so can use standard Samsung NVME or so. Also, the current/edge Armbian rockchip64 kernel runs in/as a VM, which makes it super flexible for tests but also for 24/7 doing real things. I installed grub-efi and then it boots as VM (assumuing 2 partition scheme). For Odroid (Amlogic SoC) I would expect the same. If not, install linux-image-arm64 in addition and use that kernel.

Same/similar issue. Armbian Bookworm v25.8.1 on BTT Pi. wlan0/wlan1 devices are visible, but after first reboot, do not connect anymore. Even after stopping any networking-related services/processes, "iw wlan0 scan" just returns "device or resource busy". Changing the netplan renderer to network-manager as recommended did not work for me either. I also experienced the sunxi64-mmc kernel error messages when trying to reload the rt8189fs module. After switching kernel from 6.12.47-current to 6.16.8-edge, WLAN worked right away. But in exchange the wired eth0 device is now gone completely... you can't have it all (Maybe related to this?)

Hi eselarm Thank you for your post. I can't still find a button to answer directly to your post in this forum. If I replace the HW - and I could afford it - then the question of migration to the new platform arises. Nextcloudpi worked fine on armbian releases, there is no point in changing the OS. Obviously it is close enough to debian so the "port" from debian to armbian is not very difficult. As long as the same base version (bookworm, trixie) is used. Even debian 12 did not support the required PHP version 8.1 at the time, nextcloud required it. But nextcloudpi still did the update to that nextcloud version with the result of nextcloud not running. I host nextcloud at home and I don't want a fan running at full speed in my living room. The "generic x86-64" (or amd64) is really no choice. Once I bought a WLAN router with built-in room for a disk but even with no disk installed the fan did run and couldn't be stopped. Returned it. I heared about proxmox, docker. LXC and LXD. For the latter there are images for x86-64 HW with nextcloudpi provided. But choosing the right HW and do the migration to it seems difficult to me. Regards Norbert

Yes the WTL-40110175 3.8v 10.000mAh battery has 3x red (PB+) and 3x black (PB- GND) and 1x yellow (Overvoltage?) or Temperature) Here in Turkey I do only find a 3.7v 10.000mAh Cell, but without the yellow cable (only red and black): https://www.n11.com/urun/1260110-37v-10000mah-li-polymer-pil-devreli15a-87767963 The battery PDF gives me very less clues Pinebook-WTL40110175-3_8V-10000mAh-14inch.pdf

Hi geoW Couldn't find any button to reply to your answer to my question in this forum 😐 . But here it goes: I know well how to do updates of armbian, nextcloud and nextcloudpi and how to use ncp-config. I configured it even to do the updates automatically but was burned twice - once with Armbian OS (didn't boot because of compressed kernel modules) and once with nextcloudpi updates to nextcloud without prior checking the required PHP version (8.1). So, no automatic updates any more, but manual checks, of course. I have configured an RSS feed to the nextcloudpi github page. That didn't include the never officially released version 1.55.4 of nextcloudpi, of course. In the release notes for nextcloudpi (v1.55.3) it mentions support for nextcloud 30. See the github page: Nextcloud 30.0.1 (can be automatically updated to latest minor version) PHP 8.3 Debian bookworm Armbian v24.08 Fine. There are no release notes for version v1.55.4 nor where this one officially released, at all, just tagged. So, where do you get the information that an update to nextcloud version 31 is supported by this version of nextcloudpi (v.1.55.4) ? Did you successfully update nextcloud to version 31.x with this version v1.55.4 of nextcloudpi ? Where do you get the information about someone working to allow updates to nextcloud version 32 via nextcloudpi ? Unless there is an official report about this, I won't simply update my installation. So, my original question is: what to do after the end of support for version 30.0.x ? Added: OK, I see: you are running one of the provided images for your Raspi5. I don't have a Raspi 4 or 5, That's why I posted my problem in this forum. So the story is: There is no support for any HW except for the images provided. I agree, that Nextcloud GmbH is overflowed with european requests for offers and work due to the politics of the orange head in the US. This is favourable in my opinion. So, my impression is that, obviously, nobody cares about the few nextcloudpi users not running nextcloud on HW other than on the images provided. Regards Norbert

In the end, I couldn’t recover the device and ended up purchasing a new one. It was also a V5.1 board, but fortunately, it booted from the SD card without any extra steps and installed successfully. It seems we should keep in mind that even boards with the same version may not always work the same way.

There are schematics available for this device, so one could get a hint from those, but depends if you have electronics background or not. To me it seems that higher level software in Debian/Linux enables power management handling all the way using info it gets from the power management chip/circuitry. You can guess that for this device, same as smartphone, battery operation is considered primary/essential, so decision is 'low-batt' and shutdown. I have a BananaPi M1 that also has LiPo charging, but that is DIY soldereing, so no OS component bothers with not-connected cell, but if a cell is connected/soldered which I did, is charges and runs on that cell if microUSB PSU (they call it 'AC' in the chip signal names) is disconnected, although its SATA port is unpowered then. Runs Armbian Trixie CLI only (eth + serial console). An old business HP 2-core laptop that I got without battery and HDD runs fine on just the original HP power adaptor (has 3rd wire for some genuine HP charger purposes). For USB-C powered devices, there might be many things to deal with, e.g. my ROCK5B after un-boxing goes in a bootloop with a RPI5 PSU, was/is know, so I feed it with own 12V USB-C pig-tail. For the Pinebook, it might be that the 5V is perfectly 5.000V but drops to 4.900V or so in spikes under load, so the typical 5V SBC powering issue well-known from RPi and other cheap SBCs that cannot handle >5V USB PD voltages. The Pinebook might do well if you fake the battery, so look at colored wire/connector. I have used that several times in the past decades. The yellow wire might be for temperature so besides a proper voltage on black and red, you also need to do something with the yellow wire I guess. It also might be that is you skip/disable the parts of software that do power management handling, that it runs fine. So I would boot/run the 'image' of the pinebook in a systemd-nspawn container or libvirt VM (at least the user space) and see what is what. Maybe it is something like purge 'laptop-tools' package or so, or blacklist the kernel module for power management.

Yes, but I haven't test it. I used pre-flashed to boot my image and I am done with this board / platform. Someone else has to take it from here. If board gets maintained status, this will start working automatically. Links point to our servers where this board images are not present - we only keep supported on our servers, for things we know they at least boot.

The rk3588 soc has a fixed boot order which is spi, emmc, microsd, other I think. So if there is a boot loader found on spi it will ignore other options and try to boot from that. While Armbian uboot binaries on spi are instructed to check if there is a microsd card inserted and boot from that, vendors can (ab)use this circumstance to make it harder for other operation systems being used because tools like rkdevtool are necessary to get rid of it. If the spi is pre-flashed with crap, I guess that's why the step is necessary.

😄

I believe it was android I don't care what os it has just want to get it to work again

@AndroidNewbie Do you have the image of the box?

Could you please explain why we need to erase and flash bootloader again? Could you elaborate the reason behind this step?

Hey @Igor, is there new bootloader firmware built as a result of your changes? I can probably do a quick test at some point (I've got a large build underway on one of my devices). This page is probably in need of work: https://www.armbian.com/espressobin/ the download links don't seem to work for me (they redirect to mirrors.aliyun.com)

hello everyone!! I have the same box here, it's says that it's 8gb 128gb, but real specs is 1gb of ram and 8gb of rom, any help? Thanks!

Hi, I’m working on enabling I²S audio output using a PCM5102 DAC on an Orange Pi Zero 2W (SoC: Allwinner H618) running Armbian_community_25.11.0-trunk.334_trixie_current_6.12.47_minimal. Despite several tests and rebuild attempts, I haven’t been able to obtain any sound output from the I²S interface. Below is a summary of what has been done so far. Hardware setup Board: Orange Pi Zero 2W SoC: Allwinner H618 DAC: PCM5102 (I²S input, analog stereo output) Connections: I2S0 → used for DAC (pins LRCK, BCLK, DIN, GND, 3.3V) Confirmed pin mappings according to H618 documentation and available DTS files. OS Image: Armbian_community_25.11.0-trunk.334_Orangepizero2w_trixie_current_6.12.47_minimal What has been done 1. Kernel confirmed to be mainline-based (6.12.47-current-sunxi64). Linux orangepizero2w 6.12.47-current-sunxi64 #1 SMP aarch64 GNU/Linux 2. Checked kernel symbols to verify presence of sunxi audio modules: Shows sound/soc/sunxi/sun8i-codec.c among others. Created a custom overlay at /boot/overlay-user/sun50i-h618-i2s0-pcm5102.dtso, based on examples from sun8i boards, with simple-audio-card referencing the i2s0 controller. Enabled overlay in /boot/armbianEnv.txt : user_overlays=sun50i-h618-i2s0-pcm5102 Rebooted and verified device tree loading → No audio device or sound card is registered. Also tried with predefined overlay sun50i-h618-i2s2-pcm5102 included in the Armbian tree → no sound card detected (aplay -l returns “no soundcards found”). Findings It seems that the H618 SoC has no upstream audio codec driver (unlike H616 which includes sun8i-codec). The I²S controller node exists in the mainline kernel sources, but may not be fully supported or linked to a DAI (Digital Audio Interface) for external DACs. simple-audio-card bindings appear to compile correctly in the overlay, but the device never registers in ALSA. Questions Is there any working DTS overlay or patch enabling I²S output (no internal codec) for the H618 platform? If not, what would be the correct approach — patching the DTS at kernel source level or adding a compatible binding manually? Has anyone successfully used a PCM5102 (or similar DAC) with the H618-based boards under Armbian? My goal To have a functional stereo I²S audio output through PCM5102 (or any compatible DAC), recognized as an ALSA sound card in Linux. Any help, hints, or working overlay examples would be greatly appreciated. Thanks in advance for your time and expertise! Jose Cardoso

Please help, I'm stucked (or, may be stupid). I use my tv-box as printserver (Klipper), it works fine. Now I attempt to use accelerometer ADXL345 usb board, and I havnt success. It must be simple task, but something went wrong here. Board works, flashed normally without any errors and shown as should by lsusb: klipper@transpeed-8k618-t:/usr/lib/udev/rules.d$ lsusb Bus 003 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 013: ID 1d50:614e OpenMoko, Inc. rp2040 Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Also, it must be appear as serial device, but... klipper@transpeed-8k618-t:/usr/lib/udev/rules.d$ ls -l /dev/serial/by-id total 0 lrwxrwxrwx 1 root root 13 Nov 8 18:47 usb-1a86_USB_Serial-if00-port0 -> ../../ttyUSB0 ...here is my "Ender" only. dmesg: [30617.149526] usb 4-1: new full-speed USB device number 22 using ohci-platform [30617.358206] usb 4-1: New USB device found, idVendor=1d50, idProduct=6177, bcdDevice= 1.00 [30617.358227] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [30617.358235] usb 4-1: Product: rp2040 [30617.358242] usb 4-1: Manufacturer: katapult [30617.358249] usb 4-1: SerialNumber: E6647C7403433637 [30663.467079] usb 3-1: new full-speed USB device number 3 using ohci-platform [30663.665820] usb 3-1: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice= 2.64 [30663.665867] usb 3-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [30663.665891] usb 3-1: Product: USB Serial [30663.668223] ch341 3-1:1.0: ch341-uart converter detected [30663.680198] usb 3-1: ch341-uart converter now attached to ttyUSB0 I've search solutions, but have not resolve.

@eli It's compiled in the kernel https://github.com/NickAlilovic/build/blob/Radxa-A7A/config/kernel/linux-sun60i-legacy.config#L1659-L1672

Thanks, is KVM supported?

I gave some information ..... Hit:8 http://fi.mirror.armbian.de/beta bookworm InRelease ? 🙂 If this is a bug, meaning the repositories are in beta, then OK... but I don't know if I installed them? Or are they standard in the images/firmware installations, e.g., for the Opi3LTS version? Ps. Has support for my OrangePi3LTS model been completely abandoned? ...because now I don't have the option to install the system to the emmc memory in the :armbian-config options? / nand-sata-install / armbian-install 😞