eselarm

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.

Maybe some further notes on w.r.t. running HAOS in a VM: As indicated, the process is described for Intel, see https://www.home-assistant.io/installation/alternative For ARM, people have selected RaspberryPi and then ask why it does not work. That is because RPi uses proprietary bootloader (not U-Boot, nor EFI). You need the haos_generic-aarch64 build/image, see https://github.com/home-assistant/operating-system/releases I do not use qcow2, but just a flat img. That is easy to mount as loop device in case some changes are needed to partitions or so. I extracted the .img.xz file and changed the storage (VirtIO Disk) of my existing HA VM to use the new native HAOS instead of my old Debian+supervised_HA. It started without issues and I get to the webpage from where the rest is a standard 'HA getting started', e.g. restore its backup so all devices stats etc are back again. I know many people ask for VMware or Proxmox (or some for VirtualBox), but Linux has anyway all the low-level stuff build-in and a GUI as well: root@rock5b:~# apt install virt-manager virt-manager is already the newest version (1:5.0.0-5). I have this running on ARM64 since Debian Buster 64-bit beta RPi (and 1st early 64-bit Ubuntu server image for RPi4 and also Opensuse Tumbleweed 64-bit) so the commercial ones I dropped long time ago. Above is latest Trixie. Kernel is Armbian vendor currently, but that is only because I want video HW accel (ffmpeg codecs) to work. Otherwise Armbian edge or current offers better stability IMO. Simple tests show that DRAM speed for RK3588 is same or better as for old Intel Core I7, so with also up to 32GB, is great KVM server and desktop same as that old Intel boxes, but 4 Watt idle instead of 40 Watt or so. 40W means about 40 * 9000 is 360 kWh per year, that is 108 Euros per year for my energy contract (30 cents per kWh).

It depends on what kind of- and if- HW I/O is used. USB can be redirected. PCI-E can be re-allocated from host to VM when proper IOMMU (HW) is there, that I only go working for Intel PCs, there is interest in it for ARM64, but so far haven't seen anyone got that working. Other typical SBC HW I/O like SPI, 1-wire, GPIO high-low toggle, etc, can not be virtualized, so not available to a VM. Same for video codecs HW accell blocks. Storage and networking, all things typically relevant for enterprise/servers, is no issue.