laibsch

aww, too bad. I kinda like the tea distribution. ;-) regardless, I still can't find a reference as to what it really is.

was it kernel 6.16?

MOD: Your attitude of taking but not contributing and being abrasive is not welcome here. You received a warning now and will be unable to post to this forum for a few days. You were warned by several people many times before. If you still don't get the message and do not change course, expect to be blocked completely from Armbian. Be constructive, contribute or be gone.

no worries! and that is even when you try some of the suggestions from https://unix.stackexchange.com/questions/609438/how-can-i-use-a-usb-keyboard-or-mouse-to-wake-from-suspend which I linked above?

Apologies, but what is RooibOS? I'm sure it's got nothing to do with tea ;-)

I don't know this topic very well, either. But here is a link to get you started. https://docs.armbian.com/User-Guide_Autoconfig/

Just to clarify, you did try the Armbian vendor build as well or only Radxa's vendor build?

Thank you for making us aware of the problem. But kindly also search the forum and other publicly accessible places of information: https://disk.yandex.ru/d/kK6KIqHShRHLyw/20230620/u-boot-station-m2-EDK2-EFI.img and higher level directories @Igor Can you update the website, please?

thank you for the extensive testing and superb documentation, @twwn You do know how to compile your own images, right? Did you try vendor kernels with an Armbian image already? it's very odd that orientation of the USB-C cables matters. I thought it was one of the design principles of USB-C that it shouldn't.

thank you for reporting back, @ER Samson

Thank you for the heads-up, @Kluas. Your Packages file is uptodate. It is indeed a mirror issue. Just wait or use a different mirror. $ wget -qO- https://xogium.performanceservers.nl/apt/dists/bookworm/main/binary-arm64/Packages.bz2|bzgrep 25.8.1 -8|grep ^Package.*armbian-bsp-cli-odroidc4-current -A18 | grep -e ^SHA512 -e ^Size Size: 435180 SHA512: 7e978f3ef834a0a01e52728dd72062f573fb7f973b3dedbdf36a6efd58972c5fab93c526a3945a9b6e0ff28a81bc4ade80029cf8ddb149f5d1a4ffaf8a6c2ab1 $ wget -qO- https://xogium.performanceservers.nl/apt/pool/main/a/armbian-bsp-cli-odroidhc4-current/armbian-bsp-cli-odroidhc4-current_25.8.1_arm64__1-PCee86-Va97e-He458-B1e5d-Rf36a.deb | sha512sum c0a4948328da1996a6d4df7adf33ff36dcd9f4bb377c4727d2a8f244e8809668754abb1fbee741fdfb2a0573690ebd858afdbb350f0fec4f6519b65b1b9cb385 - $ wget -qO- https://xogium.performanceservers.nl/apt/pool/main/a/armbian-bsp-cli-odroidhc4-current/armbian-bsp-cli-odroidhc4-current_25.8.1_arm64__1-PCee86-Va97e-He458-B1e5d-Rf36a.deb | wc -c 434960

The way I understood it is that he already has a button on the SBC that successfully wakes up the board, the dedicated power button. He wanted a solution not having to touch the SBC but wake up from the keyboard. And the keyboard does seem to be under power, the lights light up he says when the keyboard is touched. It appears he is very close to getting this done.

I think that is to be expected and working as designed (assuming I understand you correctly). At least I experience the same from my regular Intel-based laptop. When it is merely screen-blanking I can get back in via a keyboard press or mouse movement. But when the system is properly suspended a press of the power key is required. Back in the day, I had a PS/2-keyboard from Siemens Nixdorf that had a power button integrated. That one was able to wake up the attached machine. It worked like a power button on the computer itself. Similar to the one you see above. The power button is the one above the numpad, next to the Siemens logo. If I am not mistaken, mine was also labeled with a power symbol while the one I found on the net is blank. Maybe somebody still makes keyboards with such a button, I don't know. I agree it would be useful. Maybe you can use wake-on lan to achieve a similar result and wake up your machine from your phone or even repurpose one of those Internet-enabled Amazon dash buttons. Heck, come to think of it, I should really go ahead and do that myself. My power button is in an inconvenient place and I still have a couple of those dash buttons that I meant to use for IoT but never did. Edit: Looks like I am mistaken and it should be possible to wake up from suspend via USB. I'd love to learn how to enable that myself.

check the logs. /var/log, ~/.Xsession-errors, etc.

That issue was just dealt with by disabling cruft instead. If you want to test a newer uboot with a reenabled cruft you will again need to go into building and testing, followed by a PR.

pinging maintainer @Efe Çetin

@royk What is the risk of doing that? Can you do actual hardware damage this way or would it be a case of reflashing in the worst case?

adding COMPRESS_OUTPUTIMAGE to your call will compress your image. $ ./compile.sh build BOARD=rockpi-s BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=trixie COMPRESS_OUTPUTIMAGE=xz [...] $ ls -lh output/images/*.xz -rw-rw-r-- 1 user root 342M Aug 15 01:03 output/images/Armbian-unofficial_25.11.0-trunk_Rockpi-s_trixie_current_6.12.41_minimal.img.xz

Compiling your own image may sound dauting but is actually fairly easy. Help is also available, just ask. https://docs.armbian.com/Developer-Guide_Building-with-Docker/ https://evilolaf.github.io/docupreview/Developer-Guide_Build-Preparation/ https://www.youtube.com/watch?v=kQcEFsXEJEE

I wonder if the ENOENT at around line 493 of your log has anything to do with this. Maybe @schwar3kat has a comment?

I second btrfs. I second-guess running bittorrent off SD cards.

@TRay Best way to find out is to change and recompile your own image, then you will know. After that, push a PR so everybody can profit from your work.

In addition to what Werner said, I would like to point to the option of not installing recommended packages. "sudo apt install --no-install-recommends lxqt". Personally, i like to use aptitude for package management for more control and transparency.

Thank you so much for your generosity, @coroner21. I shall do my very best to keep the machine well maintained in Armbian.

are you sure this is not a genuine running-out-of-memory situation?