Good day. I'm running Debian Trixie in CM3588-NAS which I am using as a home server.

 

I'm currently running a kernel which came with the original install:

linux-image-vendor-rk35xx (which seems to have the version 6.1.115)

Unfortunately this is rather old.

 

The repository does have other image versions, like:

linux-image-7.2.9+deb13-arm64

 

Can I upgrade the kernel just like that or do I risk bricking my machine because the general image does not have something the vendor one does? I wouldn't ask otherwise but it seems to me that the vendor image does not seem to be walking forward and will be a problem eventually (if it isn't already).

It depends on bootloader and surroundings if it works without action and/or issues. So also DeviceTree and overlays (if you use them). In general, if the CM3588-NAS is considered as a traditional PC, so just 8-core ARM64 CPU and no special Rockchip function block like HW video encoder used/needed, it is no problem to use a latest mainline based 7.x kernel. Even simply vanilla Debian kernel from Debian Sid works fine. I do that for my RK3588 SBC's mostly as for example for Jellyfin I hardly have/watch video's that need HW based video encoding. I use EDK2-UEFI v1.1 as bootloader, then no issue to use 7.x kernels, but a recent U-Boot is also fine if headless (no HDMI at power on). I also use grub-efi, so also same as PC's. Make sure you understand and/or have that in-place, as it allow easy switching the used kernel at power-on, you might need a serial console in order not to be blind for what is happening and able so select adhoc. 

Allright, it's good that I asked, because I am not knowledgeable of these things to that degree. I think I have this based on Aptitude:

linux-u-boot-cm3588-nas-vendor

I'm marking your answer as a solution, but if you have any idea whether changing the kernel with that is safe, I'd appreciate it.

2 hours ago, Warma said:

linux-u-boot-cm3588-nas-vendor

quick check:

# strings /usr/lib/linux-u-boot-vendor-cm3588-nas/u-boot-rockchip.bin | grep "U-Boot SPL 20"
U-Boot SPL 2026.07_armbian-2026.07-Sece3-P1c54-H1a10-V102f-B5da4-R448a (Aug 14 2026 - 13:26:47 +0000)

which is very recent, not the old 2017.09 we see still quite often for RK3588 based devices, so if also the binary is actually used for booting (so written in SPI-flash or other bootloader device area), then I would say new mainline based kernels should work. 

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;

Quote

And one thing worth mentioned, vendor kernel 6.1.x are most feature complete, always.

I have no inherent problem using vendor kernels. However, I recall having this kernel version now for about a year, so at least based on my current sources, it is not being updated at all.

 

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

The 6.1 kernel is an LTS one though the current upstream version is 6.1.190.

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.