4 hours ago, tparys said:

Adding a custom boot script

FYI. Might come handy here.
@djurny made generalization / templating of boot scripts. If only loading address is different, it would be cleaner then cp whole script. In case you find time to look into. Not a blocker.

Thanks for testing. The DP link now works correctly at 2560x1440@120. The garbage during heavy screen output is a different problem. The memory clock probably cannot increase on this boot path. The kernel has no memory timing table for the Nano ("no memory timings for RAM code 0" in your log). At 120 Hz, the display then does not get enough memory bandwidth when the screen changes a lot. Workaround for now: use a lower refresh rate. Add one of these to the kernel command line and test with a lot of text output: video=DP-1:2560x1440@100

If 100 Hz still shows garbage, use video=DP-1:2560x1440@60. Please also send the output of this command. It shows the current memory clock:

sudo cat /sys/kernel/debug/clk/emc/clk_rate

The real fix needs (a lot) more work in the kernel memory driver. I cannot do it right now. Your answers will tell which fix is necessary.

2 hours ago, TrevorH said:

That's a lot of words

It's an explanation of how we're approaching this problem. IMO better approach then any Linux OS out there. In the age of AI, we won't be doing this kind of operation by hand. But this means whole automation become more complex.

2 hours ago, TrevorH said:

I'm still left wondering when

We're looking for someone who can continuously monitor CVEs, track their status, perhaps improve its design, promote biggest gains and provide answers to questions like yours. System needs to be feed by interactive Claude or 100-150 USD of tokens to drive it fully automatic. Stable repo updating is currently under testing. Only a few kernels will be getting weekly auto-update: https://github.com/armbian/armbian.github.io/blob/main/config/repository-kernel-selection.conf while others will probably need to pass hardware validation.

That role is currently unfilled, and we have no funding allocated to it. Until someone volunteers or funds this specific work, the only answer I can give you is that our best-effort policy applies. I hope by the end of the month all this is in place. Then all CVE's that are resolved are auto-included, while reported ones will require some (serious) work.

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

2 hours ago, Sherozeali Sheroze ali said:

I understand that this chipset is not officially supported by Armbian

No. S4 (S905Y4) is the closest relative we support. There were a lot of issues to bring it up - we spent several weeks fulltime and with Librelec preliminary work, peer and agents help https://github.com/armbian/build/pull/10984 There are many common areas but there is still a lot of work to bring this SoC up.

What SC2 (S905X4) needs that the PR doesn’t have:

• meson-sc2.dtsi: SC2’s clock controller, pinctrl banks, reset and power domains differ from S4. This is the bulk of the work. devmfc’s 6.12 tree and the vendor 5.15 kernel are the places to take it from.

• Ethernet: the Gigabit MAC with an external RGMII PHY, plus the internal 10/100 PHY. S4 only covers the internal-PHY path, which is why devmfc so far has only 100 Mbit working.

• USB 3.0 / PCIe combo PHY: S4 has nothing here. The T7 USB3/PCIe patches (0073–0091) might be a useful reference, but that’s a guess until the registers are compared.

• U-Boot: S905X4 hardware is all TV boxes with locked vendor U-Boot. These may hit the same rsvmem check rejection of mainline DTBs that older VIM1S U-Boot had. That would decide whether an extlinux/edge-style boot works at all.

7 hours ago, Raul said:

I was reviewing apps and software I want installed on my new NAS and it seems like building an HA image (armbian build) will include desktop as well - whereas I only use a headless server.

How did you get to such conclusion? It can be installed on minimal CLI image and there is no desktop involved. If you want to build image, make sure to use correct build switches.

Few weeks ago I put my HA on a new hardware and this is real world experience. Everything went smooth.

10 minutes ago, gene1934 said:

What is the status of that fix?

https://github.com/armbian/cve

Under testing, not yet included. Probably by the end of month.

We have CVE system ready for testing. https://github.com/armbian/build/pull/11166

How it works?

armbian/cve collects kernel security fixes that the stable kernels do not have yet. Stable releases can take weeks to include a fix, and some fixes never reach the older LTS kernels. This repository fills that gap. Tracked kernel series: 6.1, 6.12, 6.18 (LTS) and 7.3 (newest stable).

Where the fixes come from

The fixes come from these sources, in order of preference:

1. stable-queue. These are fixes that the stable maintainers queued for the next point release. They are usually days ahead of the release.

2. Mainline Linux. This is the original fix commit, used when it applies unchanged.

3. The stable mailing list. This is a backport that the fix author posted.

4. Backport with Claude (AI). Some fixes do not apply to an older kernel. Claude adapts these fixes, and a person reviews each one before it goes in.

Two other sources decide what counts as a security fix and how urgent it is:

• The kernel CVE database (vulns.git).

• The CISA list of actively exploited vulnerabilities. A match opens an issue at once.

Fixes that touch only architectures Armbian does not build are skipped. Armbian builds arm, arm64, riscv and x86.

How often

• A check runs every 15 minutes. A full run starts only when a source has changed.

• Each full run that changes the fixes makes a dated release, for example patches-20261104-0022. In practice there are several releases a day.

• Every fix must apply cleanly on the newest stable kernel together with all the other fixes. The set must then compile.

• A fix is removed automatically when the stable kernel includes it. The list does not grow forever.

Current state (2026-11-04)

Series	Base	Fixes waiting for stable
6.1	6.1.191	507
6.12	6.12.115	188
6.18	6.18.60	120
7.3	7.3.1	14

The full list is in report.md. It shows what is included, what still needs a backport, and why. To check one CVE, run ./fasttrack.sh why CVE-XXXX-YYYY in a clone of armbian/cve.

Plan for Armbian images

1. Now: the repository runs and publishes fixes. Armbian images do not use them yet.

2. Next: the build framework gets the option KERNEL_CVE_PATCHES=yes (build#11166, in review). It is off by default. At first it covers the mainline 6.18 (current) and 7.3 (edge) kernels.

3. Then: the scheduled stable image builds turn the option on. Other builds stay without it until the fixes prove reliable.

4. Later: more series, and the default turned on for more builds.

Limits

• Vendor kernels (for example Rockchip 6.1 and the Raspberry Pi kernels) are not covered. They come from separate trees.

• The fixes apply to a kernel only when it is the exact stable version that the fixes were checked on. Otherwise the build skips them and shows a warning.

• "Applies and compiles" does not mean "tested on hardware". Report a problem on the forum or in the repository.

Help

Backports that still need work are listed in report.md under "Needs a backport". CONTRIBUTING.md explains how to help.

Which image you are using in particular, so I can once check what is going on. Normally disabling power management should help. Does it only power the screen off or board goes into standby?

Thanks. The log looks the same as before, so I need more data:

1. dpkg -l | grep linux-image and uname -a

2. Boot with drm.debug=0x6 log_buf_len=4M added to the kernel command line, without video=. Then share dmesg via paste.

3. 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.

Untested.

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

We need to implement update functionality and / or convert to docker compose.

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.

3 minutes ago, perpetual said:

All fixed! the boxes are now getting the latest kernel / firmware updates again

Good, a temprally issue then. Like I mentioned, our daily build can stay behind in case build fails. This will happen here and there.

On 7/10/2026 at 3:45 PM, Vlad Maglasu said:

Also, what is the latest working image for jetson nano? 

It has latest kernel support with good hw support.
https://armbian.com/boards/jetson-nano

23 hours ago, Kuba said:

First of all big thank you to everyone who worked on adding nvidia Jetson nano back to list of supported boards.

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.

1. test without the video= options.

2. Post armbianmonitor -u.

3. Post the output of dmesg | grep -iE 'drm|tegra|sor|dpaux|hdmi'.

4. Post the EDID for each port: cat /sys/class/drm/card*-DP-1/edid | edid-decode and the same with HDMI-A-1.

14 hours ago, perpetual said:

but do not show any updates to get Linux aml-s9xx-box 6.18.57-current-meson64

 

Nighly builds sometimes breaks. Do you notice this like "now" or on longer period?

Theoretically this way, but no warranty that it will work on this specific hw / sw combo:
 

echo 1 | sudo tee /sys/class/graphics/fbcon/rotate_all

 

Values: 0 normal, 1 90° clockwise, 2 upside down, 3 90° counter-clockwise.

 

Keep it after reboot. Add the value to the kernel command line in /boot/armbianEnv.txt:

 

extraargs=fbcon=rotate:1

 

And Welcome!  

11 hours ago, Warma said:

Considering the current AI race for exploits and fixes, I can't help but to worry.

 

I'm afraid that doesn't extend to hardware bring-up kernels, aka vendor kernels. Security maintenance for vendor kernels is largely the responsibility of the SoC vendor. Since these kernels typically contain extensive out-of-tree modifications, applying upstream security fixes represent troubles - reain troublessome even with usage of AI as each code commit, still needs human (double) check.

 

Even with mainline-based kernels, it takes time for security fixes to reach package repositories. However, the maintenance effort is at least shared across all hardware, while vendor kernels typically serve only a single SoC platform.

 

Given our limited resources, comprehensive security maintenance of vendor kernels is simply not possible. We can't cover for them. If security and long-term maintenance are priorities, we recommend using a mainline-based current/LTS kernel whenever hardware support permits. If this is your business critical deployment and you need vendor kernek, I am sure one can find proffessional services that will provide this.

5 hours ago, Warma said:

The repository does have other image versions, like:

linux-image-7.2.9+deb13-arm64

Generic Debian kernels might boot and even work as simple server case, but won't be close to support level of Armbian mainline based kernels. We are also doing automatic tests on hardware and verify certain functions. Examples: 

https://docs.armbian.com/status/board-tests/#rock-5t-01 

https://docs.armbian.com/status/board-tests/#rock-5b-01

we don't have this specific device in the lab).
 

Debian kernels, which you are reffering to, are not tested on hardware in such fashion nor anyone there maintain them. Its pure mainline. In repository look for kernels named "current" (latest LTS) and "edge" (7.x). Those are patched and tested but it is recommended to use current LTS for production. EDGE are more fragile and usually doesn't bring any features as we tend to backport them. Also worth trying: https://docs.armbian.com/config/kernel/

 

And one thing worth mentioned, vendor kernel 6.1.x are most feature complete, always. More recent version support less hw related features. Gap is getting smaller with time. tl;dr;

Perhaps add it here: https://docs.armbian.com/contribute/armbian-config/

11 hours ago, bedna said:

Will this be the "default" build going forward for armbian

 

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.

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

Now we have a dedicated family and this is a good example of adding a new device:
https://github.com/armbian/build/pull/11034

Thanks for your suggestion!
 

Unfortunately, we cannot provide prebuilt images for every possible combination of board, distribution, and configuration. Building, testing, hosting, and maintaining all these variants requires considerable resources, so we have to prioritize the most commonly used configurations.
 

The good news is that Armbian is not just a collection of downloadable images, but also a powerful build framework that allows anyone to create exactly the image they need.

You can build a Debian 13 (Trixie) minimal server image for the Orange Pi 4 Pro yourself.

Build instructions: https://docs.armbian.com/build-framework/

./compile.sh BOARD=orangepi4pro RELEASE=trixie BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no

This flexibility is one of Armbian's key strengths. We encourage users to explore the build framework and, whenever possible, contribute improvements back to the project.