Active threads

Looks like the package in subject is not in the repos. However, there are other packages depending on it (explicitly indicating that the required version is >=25.8.2) so this prevents package updates. Interestingly, for the armhf target the package is available, so I suspect a build issue. Any clue?

Now it seems that the package is missing for version 25.8.2 and arm64 target. There are packages depending on it (and specifically asking for version >=25.8.2), so this prevents upgrades.

Armbian 25.8.1 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 23.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + wine-10.17-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.17) + DXVK-stripped v1.8.1 (https://github.com/khanh-it/dxvk/releases) ~60fps@720p @MartinB

This kernel is available only when you change repository to beta.armbian.com , which provides daily builds. EDGE kernels comes as is - glad to hear it works, but beware it might also break down as kernel is changing rapidly.

Can you send dmesg lsusb and lsmod outputs using paste.armbian.com

@lowscore I'did uploading for you! https://drive.google.com/file/d/1kgyjLl0JXTwFfWfplOKuQY3vLv_KtYlr/view?usp=sharing

Also step 1A & 1B are kind of weird... Like updating won't recognize the gpg key. I still could bypass the error by adding [trusted=true] on step 1B between deb and the link (or use sudo nano /etc/apt/sources.list.d/panfork-mesa.list if the file was already created).

Hi is there a way to enable the old USB port without re-installing Armbian? I have done to much setup work to start all over again.

Yes, or at least there should be less chances to hit some corner case that reduces the compatibility. LibreELEC is using the mainline kernel only for years though, so it is really strange you have issues with both armbian and multitool. I may wonder there is something odd in the device tree, but it would be odd that a misconfiguration in the device tree causes a kernel fault in the DRM code and in particular in the wait for vblank function 🙄

Hi Guys, I just did a new custom Armbian build ./compile.sh BOARD=orangepi5-plus BRANCH=vendor RELEASE=noble KERNEL_ONLY=yes KERNEL_CONFIGURE=no. The image is Armbian-unofficial_25.11.0-trunk_Orangepi5-plus_noble_vendor_6.1.115_cinnamon_desktop and when I installed it on orangepi I see it is not supporting Panfrost/Mail: glxinfo | grep -E "OpenGL renderer|OpenGL version" OpenGL renderer string: llvmpipe (LLVM 20.1.2, 128 bits) OpenGL version string: 4.5 (Compatibility Profile) Mesa 25.0.7-0ubuntu0.24.04.2 but for older image Old_Armbian-unofficial_25.08.0-trunk_Orangepi5-plus_noble_vendor_6.1.115_cinnamon_desktop All was well glxinfo | grep -E "OpenGL renderer|OpenGL version" OpenGL renderer string: Mali-G610 (Panfrost) OpenGL version string: 3.1 Mesa 25.0.7-0ubuntu0.24.04.2 I did need to enable "ARM Mail Display Processor" under Device Drivers -> Graphics support -> ARM devices before I perform custom build. And I did this for both OS version 25.11.0 and 25.08.0. But newer version is not able to use it. Thanks Manish

Delete the cache and output folder. Try again.

Hmm. That came across as a bit passive-aggressive, but alright — the question really was poorly phrased and in the wrong place. My intention was to find people from here who had already taken the test... because if documentation were enough, online forums wouldn’t exist 8^)

> ... straightforward and smooth. Same in 25.8.2

@Unrealchex try the x98h image. Or you’ll need to take the wifi node from x98h and add it to your dts. Not sure why your build stops in the middle of the kernel patches without any errors. Are you sure that's the full log?

Ecco una risposta adeguata per il forum in inglese, considerando il tuo aggiornamento: Hello everyone, I’ve reviewed all the connections carefully using the reference manual to ensure everything is correctly wired. Unfortunately, while the display powers on and stays brightly lit, I still don’t see any output on the screen. Here are a few thoughts and tests I’ve tried: Initialization Problem? I’m unsure if the issue is related to the initialization sequence. I don’t know how to create one tailored to this display. Perhaps this could be due to the fact that it’s an ST7735S, while the driver is designed for the ST7735R? Could this be causing incompatibility issues with the current driver? GPIO Changes: I’ve also experimented with changing the GPIO configurations, specifically: dc-gpios = <&pio 2 6 1>; /* changed the 1 to 0 */ r eset-gpios = <&pio 2 9 1>; /* changed the 1 to 0 */ However, this had no effect. Kernel Compatibility: When I use a kernel version 5.x, the display works correctly. But with the current configuration and the newer kernel, I can’t seem to get it to work. This might be a kernel-level issue, or perhaps something changed in how the driver is initialized. Temporary Workaround: I’ve ordered another display to rule out any potential hardware issues, but it will take a while to arrive. At this point, I’m unsure of how to proceed. If anyone has advice on adapting the driver for ST7735S or creating a compatible initialization sequence, I’d greatly appreciate it. Thanks in advance for your help!

Some manufactures change the wifi and lan controllers to keep prices down on new BOM of materials: @WINEDS got experience with thos problems https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/page/16/#comment-210825 https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/#findComment-217289 https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/#findComment-216154

Please share your .desktop file... with sensitive information redacted.

Hello. Sorry to be late. I succeed, I find the image to be installed. I think it was debian-12.11.0-arm64-netinst.iso.

A known issue with the Odroid XU4, HC1, and HC2 is that it (uboot?) does not properly park the hard disk heads before/during shutdown or power cycle/off. So, the disk drive is forced to emergency hard retract the heads when power is shutdown/cycled. This is of course a violent action for the HDD and should be avoided. Use this odroid.shutdown script and install into /lib/systemd/system-shutdown/. https://wiki.odroid.com/odroid-xu4/troubleshooting/shutdown_script Recommend adding to armbian for XU4 distros.

Just a note the download of latest release Armbian_25.8.1_Odroidxu4_noble_current_6.6.102.img works fine, so something in the build system.

Hi again Werner. Please excuse the long waiting time. It's taken me a long time to place back the device at its intended location. Here's the requested output. https://paste.armbian.com/alefaladep At the moment I've got it running on a realtek usb-ethernet dongle at full speed (confirmed throughput up to about 300Mbit). Last year when I created the thread we were using the Nanopi Neo4's onboard realtek ethernet port. No matter what we did it wouldn't run at speeds over 10Mbit. And no, the port isn't faulty. It's happening on ALL armbian devices (official and unofficial) on current distributions still to this day. Bookworm/Trixie/Noble/Jammy, with kernels 6.12, 6.6, 6.1 and 5.15 tested. On x86 debian it works right out of the box at full speed and we're talking much weaker hardware (Intel z8350). Thanks for your work. Armbian is definitely the future IMO.

Yeah fan working on :- https://github.com/radxa-build/rock-5b-plus/releases/download/rsdk-b2/rock-5b-plus_bookworm_kde_b2.output.img.xz

An `armbian-plymouth-theme` package must be installed to make it worked in the latest (6.x ???) kernels. Steps: 1. `sudo nano /boot/armbianEnv.txt` and adjust/add following line `bootlogo=true` 2. `sudo apt install armbian-plymouth-theme` 3. sudo reboot 4. Check plymouth or/and armbian-plymouth-theme documentation for more customizations

Both Debian 12 and Debian 13 use Wayland by default for the GNOME desktop environment. However, X11 also remains an available option in the login manager, allowing you to choose between the two. Wayland is a communication protocol that specifies the communication between a display server and its clients. A display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager. The aim of Wayland is replacing the X Window System (Also known as X11, or Xorg) with a modern, secure, and simpler windowing system xrandr is used on top of X.org, that's why it doesn't work on a debian that uses Wayland.

Hi @Igor, I was looking at configng repo and I found this issue: https://github.com/armbian/configng/issues/225. I think that's why I could not find a place to create the sway section in the desktop. In the same I found this in not being planned yet to be made, if ever. Should I look at the Armbian build and try there instead?