Debian Trixie repository

The documentation for testing Debian Trixie (see here) includes a script that configures an apt repository that doesn’t seem to support Debian Trixie:

Error: The repository ‘https://archive.cixtech.com/debian trixie Release’ does not have a Release file.

Sure enough, bookworm is there, but not trixie. Is there an explanation as to what’s going on?

I had been running on an image provided by the sky1 project, but as it’s based on Debian testing (and doesn’t seem to be getting updates now) I’d rather switch over to Debian stable and support offered by the vendor.

Hi,
Yes, it is strange. It worked a few days ago and I am running it right now on my Orion O6N.
I hope it is just an error and they will fix it soon.

1 Like

I filed a bug about this.

1 Like

This is unfortunately another regression on CIX’s part. It looks like the Debian 12 packages were rebuilt in late May, and when they were posted, all of the Debian 13 archives were deleted. Oddly they left the install script (if you try to run it, it fails when it can’t find the Trixie repository.) Prior to this change, I can report the script worked as expected and fully functional on Debian 13 and an O6N, and CPU, GPU, NPU, and VPU were all working properly.

If someone at Radxa or CIX reads this, publishing the debian13 variants of the same files would be helpful. These are the “keystone” packages needed by the script:

  • cix-debian13-k7.0-driver-opensource
  • cix-debian13-k6.6.89-driver-full
  • cix-debian13-k6.6.89-driver

The best workaround at the moment is to manually download the debian12 variants from the CIX archive and install by hand on Debian 13. This works, even if frustrating.


On a related topic, I also spent some time looking to see if I could build CIX’s mainline kernel on my own (I’m specifically looking for a kernel variant that has patches for the recent kernel security issues). As of 2026-06-10, both 6.18.35 and 7.0.12 are broken for O6N. My test rig was an O6N 48GB w/ the latest 1.2.1 BIOS and all of the relevant kernel command line flags set, including acpi=force.

The specific kernel crash / hang occurs bringing up SMP. If I disable SMP on kernel command line, the crash shifts to a CPU capability mismatch kernel panic. Both are likely related to a bad DTB, but beyond my skill to fix. I did a little sleuthing to the Sky1-Linux DTB on the same kernels and the differences were extensive.

On the positive side, with a small adjustment to a single failing patch, the Sky1 Linux kernel is operational and stable, which allowed me to compile and run v6.18.35 on my O6N with this kernel command line:

ro clk_ignore_unused cma=640M earlycon=efifb efi=noruntime keep_bootcon linlon_dp.enable_fb=1 linlon_dp.enable_render=0 acpi=force

More to share in a later post about how I was able to do this, but it enables a fully accelerated far more modern (and security-patched) version of the kernel with the current CIX 2026Q1 NPU/AI framework on it.

4 Likes

It seems it is back :grinning_face:

1 Like

Indeed, it is back - though I’m having new issues with this, but I’ll start a new thread on it if I can’t figure things out (the 7.0.0-generic kernel doesn’t seem to detect any USB devices which is pretty crippling).