The Tall Man

I have seen kernel updates for my system since you began this thread. You could check for a latest update, and see if the issue self-corrects. Do you know when the latest zfs-dkms package was updated? Perhaps it's just getting too out of sync with the kernels. If all else fails, you can build the kernel yourself: https://docs.armbian.com/Developer-Guide_Build-Preparation/ ...and in the kernel config, be sure that zfs modules are included. From the kernel config screen, you can do a search for zfs, and see what comes up. If there are zfs modules available there, this would be a different approach that would probably replace the use of the zfs-dkms package.

Oh, okay. I'm not familiar with DKMS. But if you're updating multiple packages at once, doesn't apt sort out which need to be done first and second, etc? But if you're somehow rebuilding the kernel upon package installation, I'd install the headers package first - as those would be required for source-code level access. As for the devicetree blobs package, that just provides copies of those (already build) .dtb files to your /boot directory. But they're actually already included in the kernel package itself. The kernel package installs them to: /usr/lib/linux-image-_______/ So on my Orange PI 5 Plus, the dtb directory from the latest kernel package is here: /usr/lib/linux-image-6.18.0-rc3-edge-rockchip64/ Keeping the convention Armbian uses, instead of installing the redundant dtb package, I manually create two links to it in my /boot directory whenever I update the kernel (I have to do this for Debian-sourced kernels anyway): cd /boot ln -s /usr/lib/linux-image-6.18.0-rc3-edge-rockchip64 dtb-6.18.0-rc3-edge-rockchip64 ln -s /usr/lib/linux-image-6.18.0-rc3-edge-rockchip64 dtb Just replace that kernel with whichever one you're using. And if you're booting via uboot, be sure the Armbian.txt remains up to date.

You'll spend the money once. Then you'll have the result thereafter. I would suggest deciding what you want, then spending whatever it costs. Orange PI is "cheap", not just in price, but in hardware reliability as well as software support. I'm not aware of such issues with Radxa. RK3588 is more powerful than Raspberry PI, but as you say Raspberry PI has great community and support. Perhaps the question is - What do you need it for? Raspberry PI might be powerful enough for your needs.

I have an Orange PI 5 Plus, and both USB-C connectors (including the one used for power delivery) are faulty. Also the second HDMI output is corrupted. Clearly their manufacturer leaves a lot to be desired.

Modproble probes modules built into the kernel itself. An external package (other than the kernel itself) shouldn't affect it. If it was present via modprobe before, and not after, that isn't the zfs package, that would indicate a module that had been built into 25.8.1 kernel, then excluded from the 25.8.2 kernel build for some reason.

I don't know if this relates, but I recently discovered an issue with a Debian Trixie file system package xfsprogs on the 25.8.1 edge kernel for the Orange PI 5 Plus: https://forum.armbian.com/topic/55599-bug-report-armbian-edge-kernel-6164-xfsprogs-trixie-package-failure-to-start-low-memory-monitorservice/

The way the Debian .iso installer does it: sudo apt-get -o APT::Install-Recommends="true" install task-lxqt-desktop That will install a fully functional desktop with a minimal set of applications. If you set Install-Recommends to false, or any other way of installing it (i.e. lxqt), in my experience, the result may not be quite functional.

I've never been able to wake up my Orange PI 5 Plus from suspend. It just goes into oblivion - requiring a hard restart. The keyboard and mouse don't wake it up. Tapping the power button doesn't wake it up. I've tried it on Armbian as well as pure Debian Trixie. Apparently something is off in the design of the SBC. But also hibernation doesn't work (again in Armbian and in pure Trixie). Using a 32 GB (32 * 1024^3) swap for a "32 GB" (actually around 31 GB) RAM device, and setting RESUME to the swap partition, the hibernation option appears. But when used, it just goes into oblivion (like suspend). I left it alone like that once for about 20 minutes, it was still in limbo. and when I (have to) hard restart it, the previous supposedly-hibernated state is gone. Given that the SBC is capable of doing a power shutdown from the OS (i.e. after dumping allocated RAM to the swap), there is no legitimate reason for hibernation to not work. But it doesn't.

Hardware: OrangePI-5-Plus (rk3588), with "32 GB" of RAM Operating System: Debian Trixie (pure, except EFI boot and Armbian edge kernel) Root File System: Ext4 (encrypted) Desktop: KDE Plasma 6.3.6 (wayland, GDM3), KDE Frameworks version: 6.13.0, QT version: 6.8.2 EFI Source: https://github.com/edk2-porting/edk2-rk3588 The boot messages, after a few starts (spaced apart) of the low-memory-monitor.service, say there's a failure to start it. After booting is complete, here's a screenshot of the output of: systemctl status low-memory-monitor.service This error didn't show up until I installed a number of packages. I tracked down the offending package from the Trixie repository: Package: xfsprogs Version: 6.13.0-2+b1 Size: 4774 kB Description: A set of commands to use the XFS filesystem, including mkfs.xfs Once this package was removed, the error vanished, and a repeat of the above Status command reported low-memory-monitor-service as active and okay. I also found that, while the error occurred with the Armbian edge 6.16.4 kernel, it did NOT occur with the Debian 6.16.3 kernel. Kernel With The Error (kernel source: Armbian trixie) --------------------- Package: linux-image-edge-rockchip64 (Armbian Linux edge kernel image 6.16.4-edge-rockchip64) Version: 25.8.1 Size: 282 MB Kernel Without The Error (kernel source: Debian trixie-backports) ------------------------ Package: linux-image-6.16.3+deb13-arm64-unsigned (Linux 6.16 for 64-bit ARMv8 machines) Version: 6.16.3-1~bpo13+1 Size: 210 MB I also briefly tried regressing the Armbian edge kernel from 25.8.1 (6.16.4) to the previously available version of 25.5.2, which was 6.16.0-rc3 (I think). The error occurred with that kernel as well. An Effect of This Bug (Possibly) When this error was showing up, I was once using the internet (firefox-esr package version 140.3.1esr-1~deb13u1) for a while, when after closing it, I discovered that my desktop background image had changed on its own. I could not change it back, no matter what I did (in the KDE settings gui). I could change it to something else, but whenever I changed it back, the altered image returned instead of what it should have been. But once I rebooted, the background was back to normal. While this one experience (very much an outlier) may not be conclusive, it is indicative of a possible memory leak.

That's already a topic (with a solution): https://forum.armbian.com/topic/55129-trixie-apt-warning-policy-will-reject-signature-within-a-year/

Type in the command: lsblk There, addressing the nvme should be obvious.

It sounds like you're much more familiar with Linux than I am... especially on a deep level. It does have its strengths. I am grateful that it's a working alternative to anything from Microsoft or Apple. But I'm a firm believer that whether hardware or software (or any kind of design), simpler is better. Complication only arises from lack of clarity and understanding. One of the hallmarks of a good operating system is to provide complete support and essentially get itself out of the way - to make the computer an immediately usable tool for what you intend to use it for.... to be a clear conduit for that intention.

With the errant icon, yeah that kind of thing can be really frustrating with linux design. I'm not that deeply familiar with it. Usually when I experience something like that, I look it up in a search engine. What I can say is that many settings are stored in hidden directories under the user home folder. Hidden files start with a period. Go to your home directory: ls -la ...but which one to explore and what to look for... You'll probably find what you're looking for with a search engine. And on your rant, yes I've sensed our views of the computing world to be similar as well. Punching holes in cards - yes! You really would have to think and get it right the first time. And it's not so hard to do. You set the standard, practice it and make it a habit. My second computer was a Commodore 64, back in the early-mid '80s. I played lots of games on there. Even though I'd started programming in BASIC before that, I learned more to program on that computer, in BASIC, and in assembly language. I experienced from others' software and what I could do on my own, to be resourceful, and that creating software that is highly functional and can do "a lot" really doesn't require much more than a tiny program. There's no excuse for complicated software. Also others and myself created it right the first time without any "patches" or "software updates" BS - once it was done, it was done right! I almost never encountered bugs from others' software on my C64. I think there was one game than had bugs in it - that's it, it was an outlier. But that computer, you'd turn it on and get the prompt within maybe 200ms. There was no "boot up" BS. And its user interface is always immediately responsive. It was never sluggish. My first experience with the extremeness of bloating was with my first x86 PC around 1991 i think. It ran MS-DOS 5.0, which took up around 7 or 8 MB as I recall, on the hard drive (or was that Windows 3.1?). And to create an assembly language program that was just a "hello world", an executable .com of that would be around 30 bytes or so, but an executable .exe was enormously sized - just from the file format overhead, so that 99.9% of the file was .exe format overhead junk! And for today's operating systems and their functionality, there really is no excuse why the total size of the complete operating system on the hard drive should exceed a megabyte (or half that), let alone several gigabytes. The bloating of today is so far beyond reason it's way off in another galaxy. A minimum of 10,000 to 1. So much software today is based on scripting languages and run-time interpreters. Plus the linux operating system was originally designed back in the 1960s!!! ...as unix, before it was ported to personal computers as linux. Apparently, they've got layer upon layer upon layer of patches and changes and different ideas and outdated models all enmeshed in a galactic-sized mess. I've also seen how the MB, GB, and TB have been hijacked by a crooked industry which has redefined those terms to be powers of 1000 rather than the truth that they're powers of 1024. Even with that, the amount delivered on memory and storage devices, in may cases, falls short even of that crooked re-definition. Now an actual GB or MB is called "GiB" or "MiB", while what is often now called a MB or GB is a bold-faced lie! What the computer hardware and OS development needs is to throw away the existing model and create a new one from scratch. As a software engineer, I have done that numerous times on my own projects, and the result is always a spectacular improvement because I can apply what I learned from the previous iteration in developing the new foundation. And that's always a simple, creative and enjoyable process. It does take a some time to do, but the results are more than worth it, and the resulting accelerated pace of development later more than makes up for it. The Orange PI 5 Plus is my first ARM board. What I'm more looking forward to though is getting into RISC-V. I'm not to familiar with it yet, but It's completely open and apparently values simplicity. That might be a really great development environment for something genuinely new.

Thanks for giving it a nudge. Looks like some activity's brewing on it now. @laibsch, As I said before, I don't have an account with github. But I had looked at your Commit, and it looked to me like you copied the existing edge kernel's .dts, but with the needed modification. From my looking at it, I think it would work. Although if I were doing it, I would do it in 2 commits: 1. An initial commit that's just a copy of the present devicetree to bring it into the patch system, since it's apparently never been part of the patch system. 2. The change to address the specific issue. To address what paolosabatino's, comment on github said... The current kernel and edge kernel have two different devicetrees. The one this is about is the edge kernel's devicetree.

There was a devicetree related pull request sent for the audio issue on another board a month ago. It hasn't gotten any action since it was made. There apparently haven't been any devicetree-related patches in the entire Armbian build system - at least for this other board (Orange PI 5 Plus). So this would be the first. https://github.com/armbian/build/pull/8568