DiegoBM

Thank you for the clarification @Torte. Then I guess that it was what you mentioned, but I sure tried multiple times, so I guess I must have done something else wrong

That's a great idea, thanks again @IBV!

Sorry to disturb you again @IBV, but in your experience after moving "/var" to a separate partition, when you upgrade Armbian in any way (I presume a dist upgrade would be the potential culprit), have you ever found any issues in the past? For example the upgrade re-enabling the ram log, or resetting "fstab" and losing the reference to your partition, or the upgraded OS having new elements in "/var" that didn't exist in your external drive causing boot problems, or anything that you can think of really? Thank you in advance.

It seems I was doing something wrong. I can't seem to find the option to delete this post so I will keep this comment here.

I reckon I know what was I doing wrong. I had decompressed the ".img" file from within the ".img.xz" file and that's what I was trying to flash. I don't know why I assumed that the .xz file was just some form of zip and extracting the image would speed things up for multiple flashing, but I guess that's not the case and that there must be more going on with the.xz file. You're right that will probably be the most sensible choice and the one that I'll finally use. I will give the first option a try just for the sake of checking how wrongly it can turn. Having the NVME available won't be an issue, I have a NVMe-to-USB adapter that I was using anyway to encrypt one of the partitions within the NVME

I did follow the instructions except for the part where they recommend using USBImager, since it won't work on Windows 11 (it won't display the USB devices) Absolutely, here's the output: [Mar24 12:46] usb 1-4: new high-speed USB device number 14 using xhci_hcd [ +0.131864] usb 1-4: New USB device found, idVendor=05e3, idProduct=0751, bcdDevice=14.02 [ +0.000007] usb 1-4: New USB device strings: Mfr=3, Product=4, SerialNumber=0 [ +0.000002] usb 1-4: Product: USB Storage [ +0.000002] usb 1-4: Manufacturer: USB Storage [ +0.001897] usb-storage 1-4:1.0: USB Mass Storage device detected [ +0.000495] scsi host3: usb-storage 1-4:1.0 [ +1.027333] scsi 3:0:0:0: Direct-Access Generic STORAGE DEVICE 1402 PQ: 0 ANSI: 6 [ +0.000552] sd 3:0:0:0: Attached scsi generic sg1 type 0 [ +0.181714] sd 3:0:0:0: [sdb] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB) [ +0.001269] sd 3:0:0:0: [sdb] Write Protect is off [ +0.000007] sd 3:0:0:0: [sdb] Mode Sense: 21 00 00 00 [ +0.001264] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ +0.043992] GPT:Primary header thinks Alt. header is not at the end of the disk. [ +0.000005] GPT:3571711 != 31116287 [ +0.000002] GPT:Alternate GPT header not at the end of the disk. [ +0.000002] GPT:3571711 != 31116287 [ +0.000002] GPT: Use GNU Parted to correct GPT errors. [ +0.000009] sdb: sdb1 [ +0.000209] sd 3:0:0:0: [sdb] Attached SCSI removable disk

The images Debian Bookworm "Minimal/IOT images with Armbian Linux v6.12" generate what I understand is bad partition information. Once flashed to the SD card, the partition won't be recognised by Linux hinted by the message "couldn't find valid filesystem superblock", therefore they can't be mounted. The desktop image is fine though and the partitions generated after flashing into the SD card are recognised by the "disks" application. I've also tried with the Ubuntu-rockchip image which also generates correct/mountable partition information. I've tested this for the minimal images for OrangePi Max as well as OrangePi 5 Plus. The images were flashed with both "Raspberry Pi Imager" and "imageusb", since for some reason the recommended "USBImager" won't list my usb devices on Windows

Unfortunately it seems like I won't be able to test the first method since, no matter how I write the image into the sd card, Ubuntu is not able to mount it when using an SD card reader. It might seem like there's something wrong with the partition information in the sd card according to gparted. Maybe it's something specific of the orange pi 5 max image....?

@IBV I can't thank you enough for taking the time to put together such an elaborate response! You're a rockstar! I'll make sure to try actually try both options over the week, and I will come back to report how it went. Once again, thank you!

Thank you for your reply @IBV! Can I not use the device name (something along the lines of "/dev/nvme0n1p1") which I know upfront, and will always be the same, since I have prepared all the NVME devices? That will be known before boot, although initially the NVME won't have any "/var" contents on it (can those be extracted from the image before boot?). Also how can you edit the /etc/fstab file on the sd card? I'm working on Windows where I can't see the sd card contents after flashing. Would it mount automatically if I used Linux? It might be more reasonable to follow your method, since I will also need to disable ram log and copy the "/var" contents. Maybe I could follow your process with the first card. Create an image out of the process, capture the /var contents inside nvme. And reutilize that with all the other cards? Could you please show me how to complete your process or indicate me where could I read more about it? Thanks in advance!

I've a set of Orange Pi 5 Max boards, all of them mounting fast NVME units. My plan was to use micro SD card to host the OS, but delegate all intensive writing (log, tmp) to a special partition on the NVME unit which will be used for OS and Application data (both for performance, and to extend the lifetime of the SD card). That way I can flash the OS disk as needed without worrying about flashing the data disk with it. I've seen that Armbian uses zram by default, but I'd like to keep the entire RAM available for the applications that will be running in the boards (NVME should be fast enough to not notice a massive impact vs using the RAM). As I have seen disabling it is not a problem. I've also seen that Armbian can use zswap but I presume that zswap also uses memory before writing back to the designated storage unit, so it would be a similar situation. I reckon that the best solution for me would be to have the OS in the SD card but make it search the for the entire "/var" folder (that should include log, tmp, and swap. Am I missing any other intensive writes?) into the NVME device. So my question is: is there any way to configure Armbian after flashing, and before the first boot, so that it automatically goes to the NVME device (which should be available) for "/var"? If a good article exists on the topic, could you please point me in its direction? Thank you in advance!

Thank you @Werner, by the sound of it, it certainly makes sense to think that it should not be used for production then. Regards

I was in the middle of assessing which new firmware to use on a set of OrangePi 5 Max, since the future of Joshua Riek's one is uncertain, and after installing the corresponding Armbian release I was welcomed with a notorious message warning me not to use it in production. I understand that it's community maintained, but is it really unsafe to use for production projects? Since Armbian seems to be the most popular distribution I wanted to double check before moving on to the next.

Using Image "Armbian_community_25.5.0-trunk.185_Orangepi5-max_bookworm_current_6.12.17_minimal.img.xz" on orange pi 5 max, the fan connected to the designated 1.25mm pwm fan connector won't do anything at all regardless of the cpu load. Just to verify the connector was fine I tested the same on the same board with the same fan, using orange pi's image "Orangepi5max_1.0.0_ubuntu_jammy_server_linux5.10.160" and the fan worked fine under cpu stress.