All Activity

[|] Error 1 occurred in main shell [ at /armbian/.tmp/work-5d76f14c-45ca-4630-ba99-8ded11db4ca4/uboot-write-Fhg7X/usr/lib/u-boot/platform_install.sh:6 and tracking down that platform_install.sh yields dd if="$SRC"/cache/sources/arm-trusted-firmware/mtksoc-20250212/build/mt7988/release/bl2.img of=$2 bs=512 seek=34 status=noxfer > /dev/null 2>&1; Note that cache/sources/arm-trusted-firmware does not appear to exist, and [although this may be my lack of knowing what to look for] I find no evidence it attempted to fetch this repo or build the firmware. Yes, this board is only recently submitted, so some problems may be expected. I did wait for the automated build, but no luck there. or maybe I'm screwing up the build somehow. Using docker, but it's on a Debian11 host, which I know isn't supported as a build platform. ./compile.sh build BOARD=bananapir4 BUILD_MINIMAL=yes RELEASE=bookworm DEBUG=yes KERNEL_CONFIGURE=no BRANCH=current Full build log here: https://paste.armbian.com/isidematup @chainsx looks to be the guy who submitted the pull-request.

I have the same problem. I just downloaded the latest IOT-Armbian. No Wifi and no BT.

No deal. Thanks for your support. Hopefully we find a solution together.

resolution: https://github.com/armbian/build/issues/8400#issuecomment-3136454158

I got hardware acceleration working in wayland+labwc, in Bookworm, Linux 6.15.4, self built armbian With a self-compiled labwc (instructions: https://forum.armbian.com/topic/53797-labwc-wayland-crashes-on-exit/#findComment-223267 ) And the ffmpeg instructions in the original post were used with no changes... plus the extraargs=cma=256M in armbianEnv.txt Side question: can anybody make hardware acceleration work in Trixie?

Thank you for following up. I just did build on bare metal and checked on the result a few minutes ago and came here now to see you already responded. I can confirm this is not a github issue as I ran into the exact same problem on my Thinkpad 16GB RAM and 16GB swap. Never had an OOM issue with any armbian builds before. Thank you for bringing this to our attention.

We saw that Github has no swap activated. So we activated it using thejerrybao/setup-swap-space@v1 step with 64GB which should be plenty enough. It happens sporadically, but when it happens it happens always at the same place, during this second apt update. Here is something else interesting: 2025-07-31T09:58:48.5188156Z [0m[1;30m[🐳|[0m🔨[0m] [0m total used free shared buff/cache available 2025-07-31T09:58:48.5189232Z [0m[1;30m[🐳|[0m🔨[0m] [0mMem: 31Gi 3.8Gi 15Gi 2.3Gi 14Gi 27Gi 2025-07-31T09:58:48.5190178Z [0m[1;30m[🐳|[0m🔨[0m] [0mSwap: 63Gi 0B 63Gi 2025-07-31T09:58:48.5643835Z [0m[1;30m[🐳|[0m🔨[0m] [0mFilesystem Size Used Avail Use% Mounted on 2025-07-31T09:58:48.5645400Z [0m[1;30m[🐳|[0m🔨[0m] [0mtmpfs 32G 2.3G 29G 8% / 2025-07-31T09:58:48.5646148Z [0m[1;30m[🐳|[0m🔨[0m] [0mtmpfs 32G 12M 32G 1% /tmp 2025-07-31T09:58:48.5646870Z [0m[1;30m[🐳|[0m🔨[0m] [0mtmpfs 32G 0 32G 0% /var/tmp 2025-07-31T09:58:48.5647587Z [0m[1;30m[🐳|[0m🔨[0m] [0mtmpfs 32G 0 32G 0% /run/user/0 2025-07-31T09:58:48.5648279Z [0m[1;30m[🐳|[0m🔨[0m] [0mtmpfs 64M 0 64M 0% /dev 2025-07-31T09:58:48.5648972Z [0m[1;30m[🐳|[0m🔨[0m] [0m/dev/root 290G 105G 186G 37% /tmp/overlay 2025-07-31T09:58:48.5669589Z [0m[1;30m[🐳|[0m🔨[0m] [0m------------------------------------------------------------------ 2025-07-31T09:58:48.5670721Z [0m[1;30m[🐳|[0m🔨[0m] [0m------------------------------------------------------------------------------------ 2025-07-31T09:58:48.5671415Z [0m[1;30m[🐳|[0m🔨[0m] [0mInstalling NodeRED 2025-07-31T09:58:49.1670560Z [0m[1;30m[🐳|[0m🔨[0m] [0mHit:1 http://deb.debian.org/debian bookworm InRelease 2025-07-31T09:58:49.1677442Z [0m[1;30m[🐳|[0m🔨[0m] [0mHit:2 http://github.armbian.com/configng stable InRelease 2025-07-31T09:58:49.1680378Z [0m[1;30m[🐳|[0m🔨[0m] [0mHit:3 http://deb.debian.org/debian bookworm-updates InRelease 2025-07-31T09:58:49.1682868Z [0m[1;30m[🐳|[0m🔨[0m] [0mHit:4 http://deb.debian.org/debian bookworm-backports InRelease 2025-07-31T09:58:49.1685589Z [0m[1;30m[🐳|[0m🔨[0m] [0mHit:5 http://security.debian.org bookworm-security InRelease 2025-07-31T09:58:58.1575506Z [0m[1;30m[🐳|[0m🔨[0m] [0mReading package lists... 2025-07-31T09:58:58.2559413Z [0m[1;30m[🐳|[0m🔨[0m] [0mE: Could not read from /var/lib/apt/lists/deb.debian.org_debian_dists_bookworm-backports_InRelease - getline (12: Cannot allocate memory) 2025-07-31T09:58:58.2561244Z [0m[1;30m[🐳|[0m🔨[0m] [0mE: The repository 'http://deb.debian.org/debian bookworm-backports InRelease' provides only weak security information. We added a free -h and a df -h command. It seems that the memleak is in apt-get update because there is around 78GBi of RAM available. No we did not build on bare metal for a long time.

Yes. Correct. Start with an armbian minimal or xcfe image that you build, with linux edge. Then install all the compilation dependencies mentioned in https://github.com/labwc/labwc/wiki and https://github.com/swaywm/sway/wiki/Debian-10-(Buster)-Installation#install-wlroots Some are mentioned as indicated for raspberry, but I installed them as well Do not install the debian bookworm libwlroots10 !! (this old wlroots interferes with the wlroots that will be installed now) Do not install libelogind-dev (it tried to modify my initramfs, it messed up the boot process, I didnt actually need it) You need a meson compiler more recent than bookworm provides. Install the backports repo: https://backports.debian.org/Instructions/ $ sudo apt install meson/bookworm-backports $ meson -v 1.7.0 Getting the labwc source code, and building: $ sudo apt install foot seatd (a minimal xterm for wayland, and a "seat manager" (may not be needed)) $ git clone https://github.com/labwc/labwc $ cd labwc $ meson setup build <-check that you have at least the GLES2 or EGL renderer If not, check that you have these dependencies: libegl-dev, libegl1-mesa-dev, libgles2-mesa-dev, libgles-dev If xwayland is desired, install xwayland from the bookworm repo After installing extra dependencies, run reconfiguration: $ meson setup --reconfigure build You will notice that the labwc build process auto-downloads and compiles a recent wlroots Finally compile (it took less than 5 minutes in my orange pi zero 3) $ meson compile -C build If it finishes compiling, check that the produced labwc works with: $ ./build/labwc -s foot If there's an error about memory allocation, add to armbianEnv.txt "extraargs=cma=256M", then reboot To install globally: $ sudo meson install -C build Test by exiting the labwc folder: cd ~ $ labwc -s foot Tomorrow, I will continue installing a display manager and greeter that works with wayland... since I am trying to avoid X11, due to my SPI LCD driver But all of you who try getting labwc in bookworm, hopefully the meson install command does something that lets lightdm see it is available as an option (I started with a minimal image)

Actually, on my board, this value can be set to either 1 or 4. Setting it to 4 provides a significant boost to read/write performance, while a value of 8 fails the test.

When auto login is enabled, this is how it starts - its in "show all screens" mode. I don't know how to fix this - its some Gnome settings / it doesn't bother me as click of a mouse to the empty space solves it. I saw you are trying Debian variant. Here it might be better to stick to Ubuntu based - its more polished. Weird beep you are experiencing - I haven't tested this HW for awhile, but so far I didn't notice it. Dunno where that is coming from.

Thanks everyone. I went with another phone and distro (ubuntu touch) since i found a fully supported one.

still looks like a cert error to me ("handshake failed"). but maybe somebody else can see something else.

"doesn't work" or equivalents are not enough information. pastebin your logs somewhere so that people can actually see what exactly doesn't work.

I was talking a out GPU error not certificate error [2510:0730/102955.113685:ERROR:ssl_client_socket_impl.cc(877)] handshake failed; returned -1, SSL error code 1, net_error -202 [2440:0730/104601.001405:ERROR:network_service_instance_impl.cc(612)] Network service crashed, restarting service. [2440:0730/104601.014376:ERROR:zygote_communication_linux.cc(296)] Failed to send GetTerminationStatus message to zygote [2440:0730/104601.020244:ERROR:zygote_communication_linux.cc(296)] Failed to send GetTerminationStatus message to zygote [2440:0730/104601.041426:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.042506:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.043109:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.043662:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.044196:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.045030:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.046123:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.046765:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.047349:ERROR:gpu_process_host.cc(947)] GPU process launch failed: error_code=1002 [2440:0730/104601.047374:FATAL:gpu_data_manager_impl_private.cc(420)] GPU process isn't usable. Goodbye.

The error message looks pretty straight-forward to me. I suggest you have a look at your certs. Sounds like a generic issue not related to Armbian in any way whatsoever.

Hello @sans-ltd, thank you for providing the logs. 32GB sounds like it should be plenty to compile the image successfully. Have you ever tried to reproduce this on bare metal? Would adding swap space to the github runner to mask the issue be an option? Does the runner always error out at the same step? It's a bit odd for apt to be running out of memory like this. Have you been able to monitor memory consumption during a failed build? Can you share your github workflow definition?

onleplus 8t is running mainline kernel so don't expect it can work as an android phone. At the moment cellular and camera is not working. Dsiplay, touchscreen, wifi and bluetooth work.

As far as I understand the terminology, "standard support" means we have someone in the core team who has access to the device and regularly runs boot tests on the actual hardware and is willing to attempt to fix issues that are found (best effort, not a guarantee). It does not mean all hardware features of the board are working. Source

As @Werner said and then just ask any specific questions you may have. Welcome to the Armbian community, @Sahil Usmani.

Seriously? https://www.lmgt.org/?q=simulate+high+latency https://duckduckgo.com/?q=simulate+high+latency You're welcome. "Many many months" of what?

I've started using an MXQ-4K box as a file server, but writing files over the network is slow, with speeds in the 3-5 MB/s range. Reads cap out at the fast ethernet link speed (~11 MB/s). I don't believe there's a CPU, disc, or RAM bottleneck as the speeds are the same regardless of file size or transfer protocol as SMB, FTP, and WebDAV all give me the same speeds, and checking in htop, they are never at 100%. These speeds are also observed when downloading a file from another device on the local network using wget or aria2 while sshed into it, with faster speeds on other devices. As far as I can tell, iostat doesn't suggest high io wait times are the culprit. If it matters, I'm writing to an external USB HDD, but the write speeds are the same when writing to the SD card through the network, which makes me believe this is not an issue. If I write a ~1.0GB file using dd to the HDD while sshed into it with `dd if=/dev/random of=/mnt/disk/tmp.bin bs=64k count=16500 conv=fdatasync`, it gives a local disk speed of ~20 MB/s, which is more than enough to saturate the 100 mbps link. Has anyone else experienced similar results? Are the slow network speeds just a limitation of the onboard nic/hardware? I'm open to suggestions.

You are asking for help. Have you actually followed the guidance you were given, though? Have you been successful to compile an image for any target (virtual or otherwise)?

@Sandeep Please don't hijack / necro old threads. You have a completely different issue from the OP, this particular one was already solved. Please open a new thread and show the output of "cat /etc/apt/sources.list /etc/apt/sources.list.d/*.{list,sources}". Feel free to ping me there and I'll be happy to help.

OK, what does that leave us with? You tried an armbian image with armbian and debian kernel and binaries and get a kernel oops. Then you tried an Armbian image with Armbian kernel and Debian userland but a self-compiled labwc and you do not get the crash? Summary so far correct?

Thanks a lot, It works! I've bought the orange pi zero 2 rencently, with also the board version v1.5, but in my case it seems that "pull PC5 to GND" is still needed, which is written at wiki: I use the latest Armbian IoT based on Ubnutu: So it may have some variant? Whatever, as it says: "pull PC5 to GND", I used a 2pin jumper(header) to shortcut the pin13(PC5) and pin14 rather than pin13 and pin9, since they are next to each other, and it works! 🙂 So I posted here in case someone runs into the same issue.