Igor

Thank you! It took few days and now almost everything works. If you can provide more data, I can try to fix problem you have.

test without the video= options.
Post armbianmonitor -u.
Post the output of dmesg | grep -iE 'drm|tegra|sor|dpaux|hdmi'.
Post the EDID for each port: cat /sys/class/drm/card*-DP-1/edid | edid-decode and the same with HDMI-A-1.

Untested.
https://github.com/armbian/build/pull/11194

Test kernel with the fix. It has the same version string as your current kernel, so install it with dpkg, not apt: sudo dpkg -i linux-image-edge-uefi-arm64-dt_26.11.0-trunk_arm64__7.3.1-*-Pa723-*.deb Reboot without video= and with drm.debug=0x6. Expected: no failed to choose link: -34, and DP shows 2560x1440@120. The 144 Hz and 165 Hz modes need more than the 600 MHz pixel clock the SOR supports. Please share dmesg and cat /sys/class/drm/card1-DP-1/modes.
linux-dtb-edge-uefi-arm64-dt_26.11.0-trunk_arm64__7.3.1-S79a9-D68f5-Pa723-Cf941-Hd102-HK01ba-V3428-B0577-R448a.deb linux-image-edge-uefi-arm64-dt_26.11.0-trunk_arm64__7.3.1-S79a9-D68f5-Pa723-Cf941-Hd102-HK01ba-V3428-B0577-R448a.deb

Thanks. The log looks the same as before, so I need more data:
dpkg -l | grep linux-image and uname -a
Boot with drm.debug=0x6 log_buf_len=4M added to the kernel command line, without video=. Then share dmesg via paste.
cat /sys/class/drm/card1-DP-1/modes
Unfortunately, this is what R&D often looks like. A lot of time spent troubleshooting, with plenty of frustration along the way. :(

Having direct access to the hardware makes this process much easier and faster. We really need to develop a service (add on to this) that allows users to enable remote debugging with a single click. Right now, there is simply too much manual back-and-forth involved.

Well, I've read that its a hard thing to execute successfully, so I'm not terribly worried.
Thank you Igor. Stay safe.

Indeed, even its not a problem having so many kernels. We designed whole Armbian project that this is not really a problem. Canonical lack such infrastructure.

Closests generic approach is https://github.com/armbian/build/blob/main/config/boards/uefi-arm64-dt.conf which supports device tree and can run multiple boards with single image. I recently moved Nvidia Jetson Nano there with practically 100% hw support. And we could / will move other similar, namely Qcom and Cix based. With addition of recently developed service https://github.com/armbian/cve we will also provide kernels with uptodate security fixes for LTS kernels. There are no reasons to run Canonical kernels.

Found a solution to automatically create a docker-compose.yml file and bring it under compose control.
I created it using this tool: https://github.com/Red5d/docker-autocompose

Ran: $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/red5d/docker-autocompose <container_id> > /armbian/adguardhome/docker-compose.yml
Modified the image stanza to pull latest: image: "adguard/adguardhome:latest"
Then docker stop and docker rm the old container, and start the new version with docker compose up -d

It is now running fine:
user@host:/armbian/adguardhome$ docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
adguardhome adguard/adguardhome:latest "/opt/adguardhome/Ad…" adguardhome 6 minutes ago Up 6 minutes

Thanks!

Hi all

First of all big thank you to everyone who worked on adding nvidia Jetson nano back to list of supported boards.
I was able to do upgrade to Ubuntu 24.04 by myself but still on old kernel.
Now, after recent changes to Armbian - the little board received new live!!

Thanks!
Kuba

Hint:
Somehow my LG monitor required extra grub config before DisplayPort & HDMI ports started to work properly (frequency was an issue).  
If anyone faced similar problems - here is what worked for me.

GRUB_CMDLINE_LINUX="video=DP-1:2560x1440@60 video=HDMI-A-1:1920x1080@60e"

 

No worries. Nothing changes by default. The separate ext4 /boot with EFI at /boot/efi only happens if you build with BOOTFS_TYPE=ext4 BOOTSIZE=XXX yourself.
 
It's for people who need a bigger /boot for initramfs. Standard UEFI/GRUB images keep the usual layout: EFI at /boot/efi, and /boot on the root filesystem. No board config turns this on, so your shrink-backup script won't come across it in official images. It might still be worth supporting later, since a three-partition layout (EFI + /boot + root) is what Debian and Ubuntu installers create with LVM or encryption.

Hi,
I'm working on bringing back support for the original LeMaker LCD
panels on the Banana Pi Pro (LeMaker Banana Pro, A20) with current
Armbian kernels. The old script.bin / fex files only worked with
sunxi-3.4, so I ported the settings to device tree overlays:
- 3.5" RGB 320x240 (BL035-RGB-002, already in panel-simple)
- 5" RGB 800x480 (panel-dpi)
- 7" LVDS 1024x600 (panel-lvds)
- FT5x06 touch for all three (edt-ft5x06 driver)
Repository: https://github.com/cyryllo/fex_configuration
The overlays compile and apply cleanly to sun7i-a20-bananapro.dtb
(kernel 6.18). I'm now building a Debian 13 (trixie) minimal image
with the Armbian build framework that includes the overlays and the
edt-ft5x06 module, and I'll test it on my 5" and 7" panels.
I don't have the 3.5" panel, so testers are welcome.
Plan once it's tested:
- enable CONFIG_TOUCHSCREEN_EDT_FT5X06=m in the sunxi kernel config
- submit the overlays, so the panels work on standard images
I've also applied to become the maintainer of this board, as it
currently has none.
 
Feedback and test reports are very welcome.
 

I was bored two weeks ago and ... https://github.com/armbian/build/pull/10988

Thank you. I understand you

Ah My bad!
 
I can confirm that the image boots successfully and the files are correctly populated in /boot and EFI:
 
 

Thanks for fixing this! I am sure a lot of people are going to appreciate seeing the traditional Linux boot folder structure and layout - esp the folks with the ITX boards...
 
Cheers and have a Great weekend ahead!

yes, it seems packages are updated and server is rebooted. So solution was fixing the bugs. Thanks a lot.

Firefox got back to me and that funny question came up again.... "Is that a recent regression? Did it work before?"
Claude went through a few Firefox releases and no it did not. So I'm back to a day job but should have the 4 changes they want in my patch over the weekend.

https://bugzilla.mozilla.org/show_bug.cgi?id=2078820
The multi stage 4 or 5 Agent review is working well, they seem to find either issues or a better way of getting it done.

My new driver is near completion. all codecs, Chrome & Firefox browsers, all hardware accelerated.

Added Mainline's new Patch to my OS
[PATCH v5 00/15] Support 10-bit YUV422 and 8/10-bit YUV420 color format on DW HDMI QP

peace,
defcom5-rockchip

Well, I'm an idiot.
 
Yesterday I connected a USB drive that I was going to format, but forgot about doing so. That drive had a fresh install of armbian on it. USB is higher in boot priority so the board used that install instead of the SD one.
 
*laughs*
All is well again.

OK. I think workaround is to re-download / re-install armbian.key from repository. As key was already changed.

Hello @Igor,
 
sorry about the late response.
Everything are working perfect now 😊.
 
Thanks
 
Markus
 
(How can I mark it as solved?)

VM
removed Proxmox armbian-upgrade reboot VM installed Proxmox (now without error messages) Great!!! So nice to get a little test/learning Proxmox instance rapidly, Than You.
 

Upstream change in packages relations. Fixed. For now.
 
- bug recreated
- fixed
- CI install tests are green ✅ 
- manually verififed on Radxa Cubie A5E (took 30+ minutes to install on SD card, full suite with ZFS)
 

 

 
 
armbian-upgrade
 
Then run installer again.

hello ,
it seem the issue is back online <
don't know what should do with "armbian-install"
use the minimal-6.18-trixie image from frontpage to write to sd-card;
htop report that only thread1 is active? (thread 2-3-4 stay at 0% activity)
 
if evoke "armbian-install" it asks for a sdcard/usb/nvme > if let use a usb-stick - it writes something to it, but afterwards it would not boot from it?
surely, must have understood it wrongly.
 
thanks.
 
EDIT: sorry, nproc report "4", so the images should be good (did just not have enough activity, is suppose). still glad to haer what "armbian-install" could or should do in such a case, thanks.

https://github.com/sgjava/javauio2
 
Java UIO 2 is the next-generation evolution of the Java UIO project, rebuilt from the ground up to leverage the Foreign Function & Memory API (FFM). By moving beyond traditional JNI, Java UIO 2 achieves unprecedented performance and hardware-level accuracy for Linux Userspace IO. Engineered for JDK 25, it provides a cutting-edge cross-platform solution for modern embedded systems.
 
You will see a huge improvement in performance on 64 bit systems, but I've also included a script to build ARM 32 JDK 25 with FFM which currently doesn't exist. https://github.com/sgjava/javauio2#arm32-support--modern-ffm-back-to-the-future
 
I'm running code on my NanoPi Duo with an image built using standard Armbian build system. That means Ubuntu 26.04 LTS and JDK 25 on boards I bought in 2017. Love Armbian!

Thank you!! I did a `nand-sata-install` from my working copy and now the images are finally booting up. Wifi is WORKING with mainline kernel 🥳

Totally undestand, just I probably know less then you about those things ...  mpv is the king, I know that. But most people don't and they will keep asking why VLC, Totem or whatever player doesn't support accelerated video. Every SoC family has its own tricks to get this working ... 

On prebuild images we test video acceeleration within Chromium and it works. Both kernels, Ubuntu Noble / Resolute Gnome, same good or bad on all boards. Others userspace combo might not work and other/all video players we don't even try to cover. Our job is done, when at least one method works OOB.
 
 
It was integrated. This is not needed anymore. For overlay, I don't know. I think its still needed and it that case, its certanly present. On kernel, where this is needed.