eselarm

You need an overlay for that camera and 6.1.115-vendor-rk35xx does not have that AFAIR, older legacy 5.10 has it AFAIR. Look for something called RPi camera v1 or that sensor name.

The audio codec issue

So essentially it is about adding/fixing analog audio (3.5mm plug) es83xx in mainline kernel. I am maybe lucky that there is another analog chip in Radxa ROCK5B, but I have also noticed strange (too high too low) volume levels initially, but cannot reproduce anymore as 1 of the distros is Opensuse Tumbleweed and the specific snapshot version is already deleted. It worked fine a month ago (Opensuse Tumbleweed on top of EDK2-UEFI v1.1 in SPI-flash ), but runs Armbian Trixie/Testing now as server, don't know about audio. I use pulseaudio via network normally, but that is broken? in Debian/Ubuntu for 3 years or so as pipewire is default and pipewire-pulse is not native pulseaudio. But I haven't looked into it the last 2 years or so. I had it working in bullseye and upgraded to bookworm needed removing all pipewire stuff to keep it working. New bookworm/Armbian I never got it working. In the end, it is Xunlong I guess selling the HW and not delivering mainline kernel features. Some cheap N100 boards use a well supported USB audio chip, RPi5 removed 3.5mm audio completely, the workaround is to buy a cheap USB audio dongle. So see for yourself how you fulfill your audio requirements. When I bought my ROCK5B, the OPI5plus was about 25 euros cheaper, but it is the onboard power supply circuit and SATA options that made me buy from Radxa and also that the ROCK5B is used by Collabora. It is long time (decade) ago I did some (local) changes to kernel sources, that was torwalds or mainline tree, for Armbian, look in latest build docs options. It is something with kernel-config, you can then pause things and change sources. But better to see if you can manage to fix directly on mainline kernel git.

My experience is that the edge kernel is stable enough, but if you act like a disk-jockey (playing with disks or SD-cards/images nowadays) you destroy your success potentially every time you try some new image. Instead, pick a distro Debian or Ubuntu when Armbian, and make backups and/or do snapshots of what worked and then install packages variants. You can have vendor, current, edge kernels installed at the same time. A lot faster build maybe because the kernel is already build by some person or some computer before, so you get it fetched from a cache. I have added the beta repo in my sources so I can select between various kernels (and U-Boot variants). You need a bootmanager though, so own extlinux.conf script or wipe standard boot.* files and make sure EFI works, with GRUB or so. The latter works fine if you don't need overlays etc, so more use the SBC as PC then as embedded board to control things via GPIO pins or so. You can also re-install a specific kernel every time, but that does not work when the one you wanted to run does not start the board or crashes it. The OPi5plus I would consider as a PC, I do that for similar boards like ROCK5B and NanoPi-R6C at least. I select kernel via GRUB and have a permanent serial console cable connected, so it also works without HDMI connected. It is mainly the choice between vendor and mainline, that is the state of ARM64 nowadays. Some new boards like RPi5 cannot run mainline yet, so then there is little need to have a bootmanager, then you need the disk-jockey methods.

What does: ffmpeg -codecs | grep hevc show? Even if it seems to support rkmpp, you can guess that it is broken. So install/get a dedicated external encoder. 2 people in this topic tread show working options. I can't help you any more, you need to do your homework so to say.

Armbian is a stable OS, but we don't know about what SD-card, power-supply etc you use with your Cubitruck and/or NanoPi Neo+2 The decompression error can simply mean corrupt file due to something wrong with HW. Or something could have gone wrong during download of the files that you or the system decompress. Also note you use a kernel from beta repo (25.11.0-trunk.41). I you want better control, create/build an image formatted as Btrfs, not Ext4. Then you can check where it went wrong. I have several NanoPi-NEOs, all use Btrfs. 2 run 24/7, the others not all the time and usually just get sudden power cut, but they start fine next time. I do in-place upgrade them since years. If something would go wrong, typically as the error you show, I go back to a previous Btrfs snapshot or/and backup from NAS. That is simply what you could do / have done. Maybe something went wrong with that sunxi64 kernel build on the Armbian infrastructure side, that can happen every now and then as it is beta. So Also then, protect your devices again such issues. Also please don't post kernel upgrade errors in a topic about LiPo controller chip. OK for now, but annoying

It is almost 2 years old and no info about which kernel. For you, please indicate which ffmpeg you use. You should have done that already in your first post.

Upgrade to Trixie went fine, but pressing the user-button has no effect. I won't look into it further now. I could try with ROCK5B, has a dedicated power button, but also needs to stay active 24/7 as server actually.

I think I mis-interpreted the sentence with 'the computer'; I did not relate that to OPi5 (but 'normal' PC). Re-reading again, indeed the OPi5 is meant. Then the power is there, the question is then, how the RK3588S and surrounding hardware will handle things. I don't know exactly anymore what all sleep states for traditional PCs comprehend. I know what can be achieved in mobile platforms (very low power), but that also includes switching off parts of DRAM that don't contain needed data, and many more like a tiny Cortex-M0 or so somewhere that is always on. The question is also, how much power is saved? For a LiPo battery in a smartphone this is quite different, so lots of extra system design is done in HW (SOC, PMIC). RK3588 should support it I think, but I am not sure if all the various SBCs can use it, because certain HW lines etc might not be there. At least Broadcom/RPi platforms cannot do anything like that.

I have used/tested KDE-neon a while ago December 2024 I see from rootfs backup, that was on a ROCK3A and to enjoy KDE6. Maybe now if you want KDE6, Trixie has it, so as base Armbian (Debian) then upgrade and/or install KDE plasma (sudo tasksel to select and install). I have it on my ROCK5B, at least with edge kernel it works all as expected, compared with KDE6 on Opensuse Tumbleweed and Debian Trixie on N100 miniPC. In-place upgrade went fine, although the whole user environment from KDE5 is gone and you start from scratch new template KDE6 when upgrade from Bookworm->Trixie. If you want latest KDE, then Neon is now already newer than the 6.3 in Trixie AFAIR, but it seems to me that integration issues can be expected. I see Ubuntu Noble (Kubuntu) has KDE5 still.

This is great, I have done some tests with my NanoPi-R6C a year ago. I have not noted what kernel etc, it also has no dedicated power-button (but a 'user-button') so I think I tried (as root) systemctl suspend and logging via serial console cable. Also looked at wake-on-LAN. CPU is the same as OrangePi5 and your logs I recognize going into suspend, but then it stayed frozen. Maybe if I re-purpose the user-button and push that it will resume. Such a button can be easily connected to a pin on the PMIC or SoC. At least 1 of the RJ45 ports supports wake-on-LAN, I could also set in NetworkManager, but it gets stuck in PCI-E somewhere or on the SoC I think, can be very complex, I don't know. For keyboard that is external to the product (the ARM SBC), USB connected I assume, you need to keep the USB power (5V) alive. Also some extra hardware AFAIK (not the SoC) that detects activity on USB keyboard. Can be very simple, but I think it is all not there for SBCs. There is no keyboard controller chip like in traditional PCs. So I will maybe sometime look in schematics and see what would be possible. So far I only focused on power architecture in general, whether USB-C PD works or not, etc. My NanoPi-R6C is 1.5 Watt when idle and vendor kernel, measured with a USB power meter. I will try to reproduce your power-button suspend-resume sequence first and then also measure power. I use EDK2-UEFI v1.1 at the moment, set to mainline and 6.16-rc3 kernel. Is Armbian Bookworm, will upgrade to Trixie first and then see.

I don't know, but what you describe is that OP1 is essentially able to run from RAM (network I/O mainly) so not so much storage I/O which then lowers the change of corruption. For OP2, is quite heavy disk I/O it seems, also torrents writing is tricky for some filesystems. If you want to know more why and how w.r.t. corruption, use Btrfs instead of Ext4. It still can be difficult if HW caches do the wrong thing, but you can make metadata duplicate and also play with commit time. I have a Pi3B running from SD-card and 4T 3.5i HDD via USB attached. It runs Debian Testing (Trixie now) , FAT bootfs and Btrfs rootfs with hourly snapper and also manual extra snapshots if I do upgrades. Also HDD is Btrfs formatted, 'dup' profile for metadata 'single' profile for data. I gets hard power cut every day at least once as solar powered. I do not do any UPS like noticing, also the power loss might be during a btrfs send|receive transfer, that will then fail, but in my script I delete read-write snapshots first as they should be read-only (so were correctly finished). No data loss or corruption during years. I just have a very simple guess about the amount of sunlight, which might be almost zero for days in winter. On a Pi2B that seems to have damaged GPIO pin 4 and was using a bad brand SD-card, I could quite perfectly see when corruption started, which files you see when you do scrub. It was a logfile and some other file that were recently written, but unimportant, so I could still do a btrfs send of a snapshot of the rootfs to my local laptop new SD-card. I know how to create bootfs for Raspberries. For my NanoPi-NEOs running Armbian I changed rootfs Ext4 into bootfs Ext4 + rootfs Btrfs. You can also use Armbian build to generate that off-the-shelf, I would now use FAT for bootfs as that matches how UEFI computers are organized. You also need extra write of U-Boot, that is not needed for RPi or UEFI. An Ext4 filesystem can be turned into Btrfs in-place with tool btrfs-convert. If it is a rootfilesystem where the OS runs from, you still need to create an extra bootfs though and so also change fstab and also as a consequence the partition table and organisation.

sudo apt-mark hold linux-image-vendor-rk35xx sudo apt-mark hold linux-dtb-vendor-rk35xx

I never used Ext4 directly on a whole block device. Linux in general assumes partitions. Advice is to use partitions. So create one first wit fdisk.

mmcblk1boot0 mmcblk1boot0 are for booting via other boot methods, not used for U-Boot in Linux/Armbian. Don't use them I would say, otherwisie the ROM in the BPI might leave you with a bricked board. You can make a partition on mmcblk1, format it and mount it. Same as with other disks.

lsblk should show you 2 mmcblk devices; 1 is SD-card, the other is on-board eMMC. Which is which number can vary depending on what kernel and DTB. If you only see 1, you should change operating system maybe.

OK so it is Armbian. You can use KVM with the 6.1.115-vendor kernel, but you must set fixed allocation in the VM which CPU cores to use. You can chose 0 to 7, 0-3 are Cortex-A55, 4-7 are Cortex-A76. Read the post(s) I linked to earlier, I and others explain it there (even 2 methods). Use virt-manager GUI ane enable .xml editing. then change that line with the cpus, I my case I use 2 cores. You van also do it with virsh CLI tool, but you need to read through the options then.

gfs2-utils But it looks like you want to share storage. You do not need a GFS2 system for that, but a regular Linux filesystem and a NFS server or SMB server for sharing over the network. Most people will use Ext4 or Btrfs or XFS in Linux.

This is not a Orange Pi 5 Plus where this topic is about. Also you need to provide more info, which Armbian version, etc. Your error might have a different reason. In general you can use armbian-config to switch kernels. I never did it like that so cannot really say what you should do. KVM / virtualization you need to read about and understand good enough in order to fix things like this. It is not armbian specific.

You need to create a logical volume in that vgroup and then format that logical volume with mkfs, then mount that. See: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/lvm_examples

Maybe others know, but I stopped buying and using USB cabling and hubs for storage/NAS solutions more than a decade ago, except that unfortunately for RaspberryPi4 I had a Samsung 840 Evo 256GB reserved form an older PC. Raspberries only have USB so you cannot use dedicated normal storage I/O protocols like SATA and NVME. Only way to not let it crash every now and then is a USB adaptor cable with ASMedia chipset (not JMicron at least) and own dedicated externally powered USB3 hub. I use 4-port RSTECH with a 2A adaptor, it prevents back feeding 5V from the adaptor to the Pi at reboots and shutdown. If it is all only 5V, assume max 3A for the whole setup, else you need to study your power tree setup. And solder DC/DC converters etc yourself or indeed look for USB hubs that don't exist. USB2 is 0.5 Amps per port, 10x as much you only get when there is special chips and negotiation in the USB-C cables that allow switching from 3A to 5A and also switching from 5v to 9v or 12v or 15v or 20v. I went back to what I did 2 decades ago for PC NAS: SATA and 12V (for a large 3.5 inch HDD). I use a 12V 10A powerbrick, but also enough old and good unused PC PSU units that can do many Amps on 12V and I believe 1 PSU can do 40 Amps on 5V. They have a fan, that is why I do not use them. I use a car battery as UPS. Swapping /dev/sdX names is also often a sign of power problems so USB storage disappears but the kernel still uses a particular /dev/sdX. In mutli-device setups, it is a receipt for disaster mostly (corrupt filesystem).

Maybe have a look at

Have a look in /dev/disk/ You can use the 'by-id' symbolic links normally to identify the storage devices exactly.

Knowing this means your options are to return the case+NVMe back to shop. Or do a cross-check; case with other NVME and NVME in M.2 slot of some other computer. But this is a typical Raspberry problem; storage via USB (SATA or NVME nowadays) easily leads to trouble. Mostly power related, but also many just the chipset in the adaptor. In case of Pi5, you could get an NVMe adaptor board, but also that is not always working out-of-the box. Only if you buy RPi adaptor and RPI NVME it should work out-of-the-box. Or other SBC that has M.2 slot already on the board.

The more SW components you try to let work together in your own systems, the higher the risk something will break as no one else has the same setup. Also if that SW is commercial (and closed-source) things will get worse. Final killer might be external storage like OneDrive, it is not even related to SW actually, just is fundamentally out of your control. If POTUS wants, internet plug is pulled and no access to your data, that, in the mean time can be used for al sorts of purposes you won't benefit from yourself on the longer term. I keep a Windows10 VM around, I had one (upgraded from free Windows Internal test license AFAIR) in VirtualBox, but wanted to move to libvirt/QEMU/KVM as that also works nice for ARM64 and it turned out that the USB extension not always worked (and needed manual install). Also as you noticed, VirtualBox is not in Debian. It was/is? in Opensuse, but with custom kernel module (that is what VMware and VirtualBox need). Now can be based on KVM, but not their defaults and complex as you need to setup/compile? yourself. Windows10 sees another computer when going from VirtualBox to libvirt/QEMU/KVM (with virt-manager as GUI) so I had to buy a new digital license for 20 Euros. I read in september MS will stop delivering updates (unpaid). That day would come of course, so I have a multi-year plan to get rid of Windows (and Google). Windows is almost done. I also have only 1 Intel box running (N100, runs Opensuse Tumbleweed but came pre-installed with Windows11), rest is ARM (or RISC-V or Atmel or Xtensa). Google is more difficult to get rid of, but slowly progressing.