ArmBoy1988

The info that I gathered from that thread is that the MTD/SPI bootloader that comes with the image I was trying doesn't handle ext4 file system on the NVMe. So I downloaded one of your images: Armbian_23.02.3_Orangepi5_lunar_legacy_5.10.110.img.xz Verified the SHA-256 hash and then flashed to an SD card. Flashed the MTD/SPI from that image and then rebooted with the Armbian Debian Bullseye Legacy CLI that did not previously boot up. And...it booted up properly. I use this version of OS as the software I'm using requires Bullseye. In any case, thanks.

https://mirrors.jevincanders.net/armbian/dl/orangepi5/archive/Armbian_23.02.2_Orangepi5_bullseye_legacy_5.10.110.img.xz This is from my browser downloads. I clicked on the USA directed download link under the Other Supported Variants section on the Orange Pi 5/5B download page. OK. I'll redo without doing the update/upgrade. I would have thought that even after doing an update/upgrade everything should continue to work and possible get updated/fixed scripts. No worries, I'll just redo without doing the update/upgrade. Thanks. Does the script format all partitions or only the partition where the system is being installed? Either way, I'll retry where I've formatted the partition and also with only one partition to see if there is something different in my environment. OK. That's good to know and it's what I would have thought. Not sure why my set up is not working. I'll post back after I've retried a few things as noted before. Thank you

I had installed 23.02 Debian Bullseye CLI to the SD card and then did update and upgrade. Will refresh the SD card with a fresh copy. Don't know where uart log can be found. I had asked in another thread where I could get the proper cable for the 3 pin uart header. Have not done the uart/debug console before. MBR is GPT. I removed all partitions and then recreated them in gdisk. Didn't format them. I knew that armbian-install formats the partition system is installed to. I'll try formatting the other partition as well to see if that makes a difference. PS I'll also try this with only one partition for the entire nvme to see if that makes a difference. FYI, it's a 1TB Samsung 980 2280.

Can someone provide a link, on amazon.ca if possible, to a cable that is known to work. I'd like to see what output, if any, is available when my Orange Pi 5 is not booting from NVMe. Thank you

I finally got back to re-doing my install. I removed all partitions on the NVMe and then recreated two partitions, one 58GB and the other the remaining space. I then ran armbian-install and selected 4, Boot from MTD Flash - system on SATA/USB/NVMe, it proceeded to ask for the destination. I selected /dev/nvme0n1p1. A warning was displayed that everything on that parition would be erased. It then asked what filesystem and I selected ext4. It then copied the root fs to this partition. After completion I was asked whether I wanted to flash the MTD Flash. I selected yes. At the end, it asked whether I wanted to power off or just exit. I selected poweroff. I removed the SD card and turned on the OPi5. It did not start up. Just the lights on the ethernet port and the red LED. With the other set up, with the small FAT boot partition as the first partition on the NVME and modifying it to select the other partition on the NVMe, it was booting and starting up properly. So, I'm happy to put the boot partition back on the NVMe drive and have it work that way. Just wanted you to know that something wasn't working as you described. Let me know if there's anything I can do to help figure this out. If all I had to do was select 4 from armbian-install, that would make it easier for others to set their system.

I've set up 23.02 Debian Bullseye CLI on my Orange Pi 5. I believe I read 23.05 is coming out soon. Would I just do an apt update and then apt upgrade to make the change? I'm at the point where I could just re-install and start with 23.05 but what would I do in the future for new updates? Thanks.

@royk @balbes150 I was using the official Debian CLI version. Thank you for explaining how the booting process works. I was thinking of removing the small boot partition and then moving the other two partitions and resizing the last partition. Changed my mind and will just redo the entire SSD. I've only set up a few items and it doesn't take too much time or effort to redo.

I was thinking that if the Orange Pi 5 I purchased didn't live up to what I was looking for, I'd buy the Rock 5B or something like that. In any case, I got the 16GB memory, m.2 for an SSD and I wasn't going to need WiFi or I could just get a WiFi dongle, if needed. A big difference, for me, is the PCIe throughput, I think that the throughput for the m.2 on the 5 will probably be sufficient.

@royk OK. Wasn't sure about that. I've seen this elsewhere...can't remember where. Probably from old Raspberry Pi stuff or on another Banana Pi I was previously using. In any case. When there is no boot partition, does the MTD booting process just pick the first partition it finds to boot from or is there a particular partition label it looks for? If it's not these, please describe how the determination is made. I'll remove that partition, if that boot partition is not needed.

I used this thread to also set up my NVME. What I noticed in armbian-install is that options 7 and 4 are required and that option 4 installs the system on the NVME. You are presented a list of partitions to select from. This is in place of the dd step/command listed. However, I don't believe the Armbian install modifies the boot partition with the UUID of the partition. This is from memory. I had gone through this a few times as I changed the number of partitions from 2 to 3 and needed to redo the install. The 1TB drive has first partition of 512MB (256MB was too small) is the boot partition, second of 63GB (so can backup on 64GB SD card if needed) is the rootfs and third remaining space is for data, mostly docker data. I'm also not sure if any of the armbian-install steps set up the boot partition on the NVME drive. I was/am able to boot from the NVME without an SD card installed. All has been working fine for a week or two.

A new variation of Orange Pi 5 is now available. I think it's available on AliExpress, but I've seen the item on Amazon.com as well...reasonable price: https://www.amazon.com/Orange-Pi-Rockchip-Frequency-Development/dp/B0C5BZLPZN It comes now with the RK3588 instead of the RK3588s of the 5 and 5B. It's similar in capabilities of the Rock 5B but I believe has a few more bells and whistles. It has two 2.5GB ethernet ports. Separate connectors than GPIO for RTC and fan. Full size HDMI input as well as 2 full size HDMI outputs. Can have m.2 for 2230 WiFi/BT on top side as well as m.2 2280 on bottom of board. I think it can only go up to 16GB memory. Not sure if Armbian will make all of these work...yet. But this makes perfect sense...I just bouth my Orange Pi 5 about a month ago PS: A new tag is required for this new variation...I guess. PPS: Other thing to note is that Amazon link is for a 16GB version and includes a power supply. However, this particular listing ships from China. For Orange Pi 5 and 5B there were listings that were fulfilled by Amazon. I would think that Orange Pi will/may have those in the near future, that ship from the US...hopefully, but likely a little more expensive. PPPS: If you go to that Amazon link, there is also a version with 4GB and no power supply for $99.99 at the time this was posted.

Note that in the Armbian documentation it mentions that the sha is an sha-256 hash. I guess I missed that. Wanted to point that out. It's good to use https://docs.armbian.com/User-Guide_Getting-Started to get started...of course.

Figured it out. Found the sha file in another mirror and then compared it...didn't work. Did an sha hash on the file and it didn't match. Did an sha-256 on the file and then it matched. FYI, the sha-256 hash is: 29545a9916279a31412242e29ffa328c5d3395bd92adbe600cb4cb5a002461de *Armbian_23.02.2_Orangepi5_jammy_legacy_5.10.110.img.xz

404 when trying to download SHA on this link:

This is solved. Nothing was changed on the T4, Armbian or OpenMediaVault. I've decided to stick with the 4.4.x version of Armbian as the shutdown and a few other functions perform/work better than the 4.20.x version. I was trying to set up some testing of the NFS mounts between the client and server and couldn't use the built-in NFS mounting in Kodi as there is no way to change options., etc. So, I set up external mounts of the drives. Following that, the issue no longer occurred. I tried to use NFS version 4, but that isn't supported. I specified NFS version 3 and no issues. I tried skipping around and no hanging...I played a video file that was about 1hr 30min and it played properly to completion. So, this is really a workaround. I use LibreElec version of Kodi on the Raspberry Pi's. This issue is either in Kodi or the LibreElec version built-in NFS handling. It could be some mismatched configuration or options. In any case, the workaround, mounting the drives before starting Kodi, seems to work properly. Issue closed. I'll post on the Kodi and LibreElec forums.

I'm setting up a NanoPC T4 as a network server running OpenMediaVault. I wasn't sure where to post this and I thought I'd start here. I'm replacing an existing BananaPi and I have it and the T4 up at the same time. I've used the BananaPi to stream video files to Raspberry Pi clients running Kodi. The BananaPi has been working well with an older version of Linux and OpenMediaVault. What's happening is video served from the T4 starts playing well but then stops shortly after playback has started. The same video file works well on the BananaPi. I've tried placing the file on an NVMe M.2 drive as well as USB 3.0 and USB 2.0 connected hard disks. I've tried this through NFS as well as Samba and the same things happen with both. I tried this with both the nightly Armbian Stretch 4.20.x image and the legacy Armbian Stretch 4.4.x image with the same issue happening. The BananaPi and the T4 are both wired to a router with the T4 directly connected to a router port and the BananaPi connected through a small unmanaged switch. At this point, it looks like it may be some network related issue as this seems like the common point for all of these devices/attempts. I'm not sure how to confirm this and if this is the issue, how it can be corrected. Any help is appreciated. Thank you

So, here's another NVMe that seems to work properly...Samsung PM961, 512GB, MZVLW512HMJP

I'm using it headless so I don't need a desktop or video. I'm setting up OpenMediaVault and so far so good. Are you saying that with 4.20.x there are issues with NVMe? I would need to rebuild. Where can I find more info on this. I was having issues with 4.4.x and that's why I went with 4.20.x As for the Samsung, well it's not new, so very reasonably priced, $130 CAD total. The specs are great and I figure I will always be able to use it later. Only about $30 more than the Toshiba I was researching.

Hopefully, I'll be trying a Samsung PM961 512GB soon. I had the possibility to get a Toshiba SSD and I'm choosing not to, at this point, thanks to this thread. It may work, though. I'm going to be trying it with the nightly Armbian Stretch with the 4.20.y kernel. Have others been using this one or the build based on the legacy 4.4.y kernel? I had tried the legacy build but had some issues so I thought I'd try to nightly build to see what happened and so far seems to be working fine.