The Tall Man

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

You can install firefox. Not sure why you're not seeing it. If you're using Ubuntu Noble, firefox has issues. I think it normally installs from an Armbian repository, and last I installed it in Armbian Noble (just a couple days ago), it didn't work at all, so Armbian's firefox is, at present, non-functional. However you can install Ubuntu's, but their version is only available as a snap rather than a debian package. In my experience snap applications are slower to start up, plus they invade your home directories with a snap folder. Snap applications are also not necessarily open-source behind Cannonical's wall. Armbian desktop images also come with a Microsoft program: Visual Studio Code. And a Microsoft repository is added to the apt repositories specifically to handle updates for that program. You can, of course, uninstall it. The package name is just called code. Then you can go it: /etc/apt/sources.list.d/ and delete the microsoft file (using sudo), if it's still there. That will remove its repository. Then apt update. If there's no microsoft file there, then it's already been done. Not sure why it's taking 30 minutes to run apt update??? There is an Armbian repository that's usually slow, but it's I've never experienced it being that slow. If you really want an OS created by those who are more trustworthy, I would recommend Debian over Ubuntu. In Debian, firefox works without issue. Although the Armbian firefox hijacks your home page to keep returning to Armbian's site, despite your settings. There's a settings file somewhere that they modified to do that, you can delete their modification to stop that. I'm not sure which file it is though. I looked it up once, but never kept the info. But Ubuntu does seem to run better, and it has many more software options in its repositories, but those extras tend to be closed-source. But in Debian, there are a couple of software GUIs you can used to install snaps and flatpacks if you want to. Apparently snaps are maintained by Cannonical (Ubuntu) and tend to be closed, whereas flatpacks are openly-maintained and are apparently more efficient - though I don't have much experience with either. I prefer straight debian (.deb) packages when available.

Hi Keith, I'm not too familiar with the in and outs of armbian-config. Just navigate around and see what's available. The kernel being Edge makes it easiest to install to a different device (i.e. if that's eMMC), so you're goo there. And remember, if you break the operating system, you can always start again with a clean install. So don't be afraid to experiment. It's how we learn. But I am very careful with the 16 MB SPI-NOR, and not to mess with that. I'm not sure if overwriting that with junk would brick the machine or not. Perhaps someone else who knows more about that can comment. But otherwise just follow your instincts as best you can and do what makes sense to you. Armbian-config is meant to be pretty straight-forward.

Btw, about things turning orange... I had that experience some time ago before I got into Armbian. I did a clean install of Debian Bookworm. Then I tried installing the vendor GPU drivers and packages from the Orange PI company. Their drivers and packages were so horribly hacked / designed that various programs that needed certain SoC features needed to be custom modified to work with those specific vendor drivers. So all versions of those programs needed be held and were non-upgradable if I wanted continued GPU and video acceleration support. Anyway the main GPU driver package, when I installed it myself (instead of whatever secret sorcery their installation did), it turned things orange. Fortunately now, pure Trixie works out of the box on my board (from the Debian installer .iso), except that the kernel needs to be upgraded from their 6.12 to 6.16.3 from trixie-backports. Armbian's edge kernel on an otherwise pure Trixie is even better than Debian's, because it's customized for Rockchip. If you've been doing things like I was trying to before, things have much improved and now simple is better and it works. Also things tend to get really mangled up when upgrading over time - especially major LTS upgrades. Why not try a fresh install of a 25.8.1 Armbian image?

I have a different board (Orange PI 5 Plus). My experience with the edge is that it works great in Wayland and terribly in X. Also KDE Plasma Wayland is different than Gnome Wayland (and Plasma is buggy in Trixie). So you could try all three combinations and see if one works better than the others. You tried both the stable edge and the rolling edge ...with the same results?

Kernel 6.1 is Vendor. Kernel 6.12 is Current / Mainline Kernel 6.16 is Edge. It's simple to change to edge. Just run armbian-config (it's available in the menu, or just type it in the command line using sudo). In armbian-config, as you make the selections, you'll find that you keep pressing ENTER until you get to the long list of kernels. Then scroll down to the latest Edge, which as of I last looked was 6.16.4. It may also say Armbian 25.8.1.

You can switch to an edge kernel using armbian-config. You can install the stable edge or switch to the rolling releases and install the rolling edge. Stable edge is at 6.16.4 and should work just fine.

Recommendation: Switch to the edge kernel (eMMC drive access + better performance + more complete kernel features) I just tried out that Armbian Noble image with the vendor kernel. I noticed the eMMC drive didn't show up. Also the user interface seemed a bit sluggish. I normally use the edge kernel, it's far more complete than the vender kernel. I tried that here, and the eMMC drive appeared, and also the user interface become much smoother. You can use armbian-config to switch to the latest edge kernel (6.16.4).

Additional Tip: The sync command: Btw - an additional tip, whenever you're copying files or images, it's a good idea to finish it off with the sync command. When using cp or dd, the prompt returns when the CPU portion of the copying is done, but that doesn't necessarily mean that the final data buffer has finished transferring its data to the drive or device. The sync command holds and only returns the prompt once the buffer has finished copying to the drive or device. Note that if you're copying a batch of files, the sync command will return only when the current file has finished, not necessarily the entire batch.

Great!! I'm glad you got it working!

Don't concern yourself with the LED light color and whether it flashes or not. It will flash with some kernels and say red with others. And FYI, kernel 6.12 seems to boot, but it has no video output. This is why I suggest starting with 6.1 (vendor).

A 1 GB SSD... don't you mean a 1 TB? I wouldn't start with questioning your bootloader. From what you said, that makes no sense to me. It sounds like that part of your system is already working. From what you said, I would begin with an Armbian image instead of Xunlong (official Orange PI) image - as Xunlong really doesn't do a good job with OS support. https://www.armbian.com/orange-pi-5-plus/ Don't download a 6.12 image because they don't work. 6.1 is does work. Here is a specific Armbian Ubuntu Gnome image for the Orange PI 5 Plus 0 click on this and the download will begin: https://dl.armbian.com/orangepi5-plus/Noble_vendor_gnome You were right to use dd in Linux instead of some fancy piece of software. The images from Armbian are compressed to .xz. To decompress the image, after you download it: unxz [FILENAME] After you decompress it, dd the. .img file to your uSD. Remember to dd it to the device itself, not to a partition on it. This assumes there's nothing on the drive you want to keep, because this will overwrite its GPT (partition) table if it has one. Then verify your image: cmp -l [FILENAME] [DEVICE] If the verification is a success, it will not list any differences between the two files. It will just say EOF on your FILENAME. If it lists differences, it's a failure. Then simply dd again and verify again. I've had occasional instances where I've had to dd something twice from another computer. Then place the uSD in the Orange PI 5 Plus, and power it up. Everything should go well. It'll ask you a few easy questions. Then take you to your (Gnome) desktop. Then of course, do an update and reboot. Then run armbian-config. They have an installer program I've never really used so I can't speak to it. But it's supposed to let you install it on another device (i.e. your SSD). Whenever the uSD card is present in the Orange PI 5 Plus, it will take precedence in boot. So after you do the install onto your SSD drive, shut down and power off the Orange PI 5 Plus, then remove the uSD .Then power it on. Hopefully it will boot from your SSD.

Well I'm glad you found a way to get what you really needed and now have something that works : )

Addendum: An Easy Way To Bypass Grub's Self-Centric Orientation & Eliminate The Need For OS-Prober 1. Assuming you already have your EFI partition set up, for any OS that's mounting the EFI partition, stop that. In the /etc/fstab file, comment out (with a #) the line where it's mounted (i.e. as /boot/efi/). 2. Install grub on each OS. You can keep the /boot/grub/ directory on the same partition as root. Each installed OS will just update its own grub.cfg whenever it's needed. # If the your OS doesn't have a /boot/efi/ directory, create one. mkdir /boot/efi # Install grub. This will force it to install even though it won't detect a genuine EFI. grub-install --efi-directory /boot/efi --force Remember if you need to disable os-prober (recommended), just comment-out its line in /etc/default/grub. 3. Optional: Eliminate the pesky EFI Firmware menu entry in each OS this way: cd /etc/grub.d mkdir skip.d mv 30_uefi-firmware skip.d/ 4. Update Grub with your current kernels update-grub 5. Create a small partition for grub. 64 MB will suffice. 6. Choose an OS's grub, and copy all files from /boot/grub/ to that small grub partition. 7. On that grub partition, create a new grub.cfg. Here is a sample: set timeout=10 # Load Modules insmod all_video insmod part_gpt insmod ext2 insmod png # Setup Background loadfont unicode terminal_output gfxterm background_image /grub-16x9.png set color_normal=white/black set color_highlight=black/white # Menu Entries menuentry 'Orange PI Bookworm' { search.fs_uuid df078711-12a0-4637-9264-bac72ee25e4c root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Debian Trixie' { search.fs_uuid 1b6add1b-05ac-4568-bf54-1f920a6f8e3e root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Armbian 25.8.1 Bookworm' { search.fs_uuid ecb0ae86-8f5c-477e-bcd0-bc77ee5ebee9 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Armbian 25.8.1 Trixie' { search.fs_uuid 6f2d1972-8868-4fb2-bde4-e14325ea4d31 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Armbian 25.8.1 Noble (Ubuntu 24.04)' { search.fs_uuid d974e989-b201-48c6-b74b-f9ab5dfdfdae root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } Of course, change the menu entry titles and UUIDs to your own. 8. Copy the background image you'd like to use to your grub partition. On Debian, background images for grub are typically stored some place like this: /usr/share/desktop-base/emerald-theme/grub Note in the sample grub.cfg file, grub-16x9.png is the background image named. If you want to use a .jpg instead of a .png, change the insmod png to insmod jpeg. 9. In your EFI partition, modify the grub.cfg to be as follows: search.fs_uuid 3D53-E216 root set prefix=($root)'/' configfile $prefix/grub.cfg ...changing the UUID to that of your grub partition. Usage Select the OS you want. That will take you to the OS's own grub menu, which will likely show you two options, the main boot option and "Advanced" boot options. If you select an operating system and wish to change your mind, the ESCAPE key will return you to your previous menu. Problems I did this and everything worked well except the Armbian Noble (Ubuntu) entry. I coped Debian Bookworm's grub to my grub partition, and either Ubuntu's grub is buggy or apparently Ubuntu's grub used language in its grub.cfg that Debian's grub didn't like. It boots into Ubuntu automatically, but it doesn't show any boot menu. I set its timeout for 10 seconds, so it sits with a blank screen for 10 seconds before it boots. Update: I replaced the grub files on my grub partition with those from Debian Trixie. Same results with Armbian Noble (Ubuntu).

Addendum: How To Include Devicetree Overlays Since Grub does not have devicetree overlay support, we need to merge the desired overlay(s) in with the main devicetree (.dtb) file we're using. Part of the device-tree-compiler package is this command: fdtoverlay An example from Armbian 25.8.1 Trixie running on the Orange Pi 5 Plus, to enable GPU acceleration in the Vendor (6.1) kernel. In sudo: cd /boot/dtb-6.1.115-vendor-rk35xx/rockchip fdtoverlay -i rk3588-orangepi-5-plus.dtb -o rk3588-orangepi-5-plus-panthor.dtb overlay/rockchip-rk3588-panthor-gpu.dtbo Of course, to have that load automatically from grub using the modification above, you'll need to rename (or move) the original .dtb to something else, then rename the one with the -panthor suffix to the original name to take its place.

@Werner, I merged the Panthor overlay with the Vendor devicetree using the fdtoverlay command (since I'm using efi/grub instead of u-boot), and now Vendor kernel with GPU is an option!! Thank you so much!! https://forum.armbian.com/topic/55266-add-devicetree-to-grub-automatically-heres-how/#findComment-226070 Question: I've noticed (at least in Debian on the Orange PI 5 Plus) that the Vendor kernel (with Panthor GPU overlay) works well under X and Wayland, but the Edge kernel only works well under Wayland. With the Edge kernel under X, the GPU is "there", but it doesn't seem to offer any kind of acceleration. I noticed this the first time I tried the Edge kernel several months ago, and it's still the case. Do you know of a fix for this as well?

@DiplDi I was doing some experiments on Armbian 25.8.1 Trixie, and I decided to do a quick try of installing the XFCE desktop (along with some others): sudo apt-get -o APT::Install-Recommends="true" install task-xfce-desktop It works under X, but not under Wayland. I found out that its Wayland support is experimental, and that if you install the labwc package, that will get it running (very very badly) under Wayland. But it does work well under X. It's possible a different wayland compositor (than labwc) will work better? I also tried with the Vendor kernel (with the Panthor GPU overlay), and the edge kernel. Edge GPU performs seemingly not at all under X, but vendor with Panthor overlay performs well in X. I initially logged in via the SDDM display manager, but I switched to LightDM, and that worked as well, although with a hiccup.

My brief experience in trying out a USB-C display wasn't great. I was never able to get any video at all until / unless I was fully booted into an OS, and even then it was shotty. Both USB-C connectors on the Orange PI 5 Plus (on mine anyway) are poorly made and intermittently lose connection if moved around at all. I recently read that's a real problem with SBCs in general that get their power over USB-C... clearly a very poor design. I also read somewhere that a similar board required proprietary drivers for USB-C display output to function. My experience indicates at least something like that likely applies here as well. Dysfunctional hardware design.