compent

OK thanks. I am just trying to take a working copy of the NVME installation and create a back-up image file, just as I do with Windows installations, for restore in case of emergency. I had hoped that because I could transfer a live system from SD card to NVME, then I might be able to do something similar the other way. As I said above, all I was getting from the various attempts were errors of either Not a directory, No such file or directory or Is a directory But now that I know that it is not possible this way, I shall boot from a separate installation and hope that things work from there. I am still concerned about the 3 errors that I was continually receiving and would like to get the DD syntax correct, so that I can see what I need to do.

A few days ago I had an issue with a successfully running Armbian installation running from the NVME of my Orange Pi 5 that suddenly developed an issue with nothing being shown on my TV. So after seemingly not being to identify the problem, I started again, wrote the image to an SD card and then moved the installation to the NVME drive using armbian-config utility. So now that I have a set-up that works again, I want to instigate a more belt and braces approach and create an image of the NVME installation using GZIP to compress the image file and decided to use the DD option from terminal. Having tried well over a hundred different combinations of commands, I am unable to get things to work. I either get errors of Not a directory, No such file or directory or Is a directory The output of lsblk is NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS mtdblock0 31:0 0 16M 0 disk mmcblk1 179:0 0 59.5G 0 disk └─mmcblk1p1 179:1 0 59.5G 0 part zram0 252:0 0 3.9G 0 disk [SWAP] zram1 252:1 0 50M 0 disk /var/log zram2 252:2 0 0B 0 disk nvme0n1 259:0 0 238.5G 0 disk └─nvme0n1p1 259:1 0 238.5G 0 part /var/log.hdd So in order to create the copy of the NVME installation, that is only taking up 13gb of the 238Gb total, to the root of a 64Gb SD card, completely empty and formatted to EXT4 via gparted, using the information above, can anybody see where I am going wrong. A few typical examples of command structures that I have tried are: sudo dd if=/dev/nvme0n1 of=/dev/mmcblk1/armbian.gz conv=sync bs=64K | gzip --stdout > bs=4M status=progress dd if=/dev/nvme0n1 conv=sync bs=64K | gzip --stdout > of=/dev/mmcblk1/armbian.gz dd if=/dev/nvme0n1p1 conv=sync bs=64K | gzip --stdout > of=/dev/mmcblk1p1/armbian.gz bs=4M status=progress This is the general template that I initially followed from a website dd if=/dev/SOURCE conv=sync bs=64K | gzip --stdout > /path/to/file.gz I've researched the use of the DD command until I am cross eyed.

I've gone round in circles with this one and it seems that there might not be a solution, so will set it up again on the NVME drive. Thanks for all the help offered.

I had a look in /var/log/gdm3/, which was originally denying me permission but after obtaining access, it is empty, so no GDM log, as least in this folder. I also edited custom.conf to enable GDM logs but it had no effect. I was curious to know why there is a GDM3 folder, rather then GDM.

Lightdm wasn't seen as being installed but I installed it just to see what happened but no change. sudo nano /home/*/.xsession-errors gave the following information. Xsession: X session started for test at Fri 20 Jun 07:04:16 BST 2025 dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=> dbus-update-activation-environment: setting DISPLAY=:10.0 localuser:test being added to access control list dbus-update-activation-environment: setting QT_ACCESSIBILITY=1 dbus-update-activation-environment: setting USER=test dbus-update-activation-environment: setting LANGUAGE=en_GB.UTF-8 dbus-update-activation-environment: setting XDG_SESSION_TYPE=x11 dbus-update-activation-environment: setting HOME=/home/test dbus-update-activation-environment: setting XRDP_PULSE_SINK_SOCKET=xrdp_chansrv> dbus-update-activation-environment: setting XRDP_PULSE_SOURCE_SOCKET=xrdp_chans> dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=> dbus-update-activation-environment: setting PULSE_SCRIPT=/etc/xrdp/pulse/defaul> dbus-update-activation-environment: setting LOGNAME=test dbus-update-activation-environment: setting XDG_SESSION_CLASS=user dbus-update-activation-environment: setting PATH=/usr/local/sbin:/usr/local/bin> dbus-update-activation-environment: setting XRDP_SOCKET_PATH=/run/xrdp/sockdir dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/1000 dbus-update-activation-environment: setting DISPLAY=:10.0 dbus-update-activation-environment: setting LANG=en_GB.UTF-8 I flashed an older image and this latest one (that had been working fine for a few weeks) and both ran fine from Micro SD cards or USB. I'm not sure what connection Efe Çetin has as it's an Orange Pi 5 board, so perhaps they have some form of official input to design. I'd love to know what triggered the change. And yes, like many things, no guarantees but if what happens can give pointers to preventing it happening to others in the future or recording potential solutions for those that might end up in the same position.

@WERNER If I try to use xrandr through an SSH connection using putty I get the response 'Can't open display' I can use it in terminal via remote connection and the basic command returns: Screen 0: minimum 256 x 256, current 1364 x 768, maximum 16384 x 16384 rdp0 connected primary 1364x768+0+0 0mm x 0mm 1364x768 50.00* Messing around with xrandr, there seems to be more than one way to skin a cat, if I try something like: xrandr --output rdp0 --mode 1280x720 I get a response of 'cannot find mode 1280x720' I experimented with all manner of normal resolutions that I have used before and even tried both the minimum stated by the plain xrandr command, 256x256 and 16384x16384 but get exactly the same response. It would seem likely that 1364 x 768 is why my TV is not showing the desktop because I suspect the resolution is not supported. But I feel between a rock and a hard place for something that seems become hard locked. @laibsch I poured through the log I posted above but much of it seem to be more rocket science, so hard to pick out something that logically points me in the right direction.

I noticed that the resolution had been changed from 1920x1080 to 1364x768 but when using remote desktop there is no way to change the resolution using the GUI. Is there a terminal command that can do it?

For a few weeks I've been using the latest official release from May 26, 2025, running just fine from my NVME drive. But then I turned it on and at the screen where you get the Amrbian grey/red logo in the middle of the screen and the spinning circle, it went no further. The spinning circle would either stop rotating or disappear after a minute or so. I can SSH into the device. But when I use remote desktop from a Windows PC, the full and functioning desktop is there. It's just not on my TV screen any more. I've done the usual HDMI cable testing and powering off the TV completely, but no change. The fact that the desktop is accessible remotely does indicate that it must be loading in some fashion. Took a log here: https://paste.next.armbian.com/qococumoga

Thanks for the reply. I did run each element one at a time and watched to see when and if there were any that reported errors. It's not a big deal though and always worth trying new things to try and get this SOC running as it should do.

I gave this a try but after creating the /etc/apt/sources.list, when running sudo apt update it returns this error The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 0E98404D386FA1D9 NO_PUBKEY 6ED0E7B82643E131

I would say that as far as being an all round use device, a very, very long time down the track since introduction, there are still some rather critical areas to be resolved. H265 (WIP) and VP9 (TODO) decoding are perhaps 2 of the key areas holding back the device from being close to mainstream. The HDMI audio, as mentioned, is almost certainly critical going forward. HDCP, MIPI CSI video capture, DP1.4 USB-C AltMode, HDMI CEC, HDMI ARC, HDMI 8K support, H.264/H.265 encoding are some of the other missing functions that are going to be useful to some people. If it wasn't for Collabora, this turkey would have been long dead and buried. Whilst much has been done in the last couple of months, the e waste dumps are still in view.

When using the RKDevTool, do you have anything plugged into any of the USB ports? If so, remove anything so that the board is essentially out of the box. When I first started using the RKDevTool, I had a WiFi/BT dongle and a wireless dongle for my mouse, which game me maskrom errors when attempting to flash Android. As soon as I removed them, all worked well. Probably a long shot in this case but worth checking. Have you also tried to use the reset button on the board? There seems no documentation about it's use but it must do something practical. Perhaps hold it down for a few seconds whilst powering up.

I wanted to try this with the latest Armbian 24.8.1 Noble Gnome build for the Orange Pi 5 but there were errors when attempting to run sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia, where errors indicated that the repository isn't compatible with this latest build. Err:9 https://ppa.launchpadcontent.net/liujianfeng1994/panfork-mesa/ubuntu noble Release 404 Not Found [IP: 185.125.190.80 443] Hit:10 http://armbian.tnahosting.net/apt noble InRelease Reading package lists... Done E: The repository 'https://ppa.launchpadcontent.net/liujianfeng1994/panfork-mesa/ubuntu noble Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.

If the question was "Can I dual boot different variations of Armbian from the same SSD", then, for the most part, this would likely apply to any combination of operating systems. At present there is no way (that I have seen) that dual boot from the same source can be achieved and I would say that any expectation that Orange Pi would develop such an option should be as close to zero as you can get. Whether any third party option will be developed is anybody's guess. Something like Pinn that is available for the Raspberry Pi would be nice but with the current state of OS development from Rockchip and OrangePi as it is, he prospect of something earlier than much, much later would be akin to expecting to get blood from a stone. As for posting on the Official Orange Pi forums, note that there is pretty much zero response from the company. The forums are choc full of spam and so the only responses that you will get are from the communities that post, which are rather small. There is more frustration on there, rathe than solutions and advances. So for now, the best dual boot option is to have one OS on an NVME and another on an SD card, where you have to insert or remove the card to be the determining factor to which OS you wish to use. I'm not sure that we will see any significant development in the RK3588 that will come close to match what is happening with the Raspberry Pi 5 until at least 2025, if ever. But if you really do need dual boot from the same source right now, you would be better off with a Raspberry Pi 5 or an X86 mini PC. I did see a video on YouTube a few months back from Firefly who were supposedly unveiling a multi boot OS option that seemed to be a variant of Petitboot that can be used on some AMLogic devices but nothing seem to have materialised but perhaps worth contacting them just to determine whether the option is actually going to roll out to their own RK3588 products.

@Khadas Having asked for the steps to be specifically listed, having now solved it yourself, might it be useful to others for you to list the steps that you took to obtain a resolution?

Dbosco Thanks, that worked and to the point where login was also automatic. I'm not sure if the updates broke anything because video and webgl performance testing in Chromium didn't indicate any performance increases.

A very worthwhile discussion indeed now that there seems to be some light being seen at the other end of the tunnel. I'm not so sure that the specific USB hardware support is now in place in it's entirety. For the past few days I have been testing all of the rolling releases for both 6.1 and 6.8 kernels and the results can differ from day to day. I fully understand that the nature of rolling releases is that there are all manner of changes made from day to day, so no complaints at all as I know that things can break. The fact that we do know that the USB hardware support does now have solutions does bode well and I would imagine that it will integrate into all builds very soon. In terms of the transitioning, pitfalls and remedies, I have come across an issue with a particular build type. This week I spotted a build that was of particular interest because of the panthor and amazingfated connections , the Orangepi5_jammy_vendor-boogie-panthor_6.1.43_kde-neon-amazingfated-oibaf_desktop.img, which is now at Armbian_24.5.0-trunk.416. Unfortunately I am unable to get it to load from any trunk build. It initially boots correctly and I go though the config routine to create login and passwords etc. But when things get to the actual desktop login screen, when logging in, the screen goes briefly black, with the mouse cursor popping up and a small white bar at the top left of the screen, before being returned to the login screen. No matter how many times I try, it will not complete the login process. I know that the password is correct because if I deliberately enter an incorrect password, it is rejected with a specific message to conform this. I did then attempt to login as root but even when entering the correct credentials created during the initial config process, the credentials were rejected as being incorrect, despite them being correct. Hopefully somebody else may have tested the same and can offer a potential solution to enable me to fully test and report back on this particular 6.1 build.

Very nice and with clearly laid out installation instructions.

I tried Armbian_24.5.0-trunk.257_Orangepi5_noble_vendor_6.1.43_xfce_desktop.img but the USB port is still not accessible. The fact that there is a solution available is of course good though and will no doubt find it's way into new builds.

@Igor As Android is based upon Linux, I would have thought that a manufacturer bringing a newer kernel would bring things closer to mainline support. I could no see any release of the kernel so far, so wonder how you can know what the new SDK does and does not bring. Based on Rockchip's rather chequered history, I can certainly empathise with your views, so little would surprise me with regards to their business practices. But regardless of the angles of view, things are still clearly headed in the right direction, with your work also clearly being rather pivotal.

It boots fine into a desktop but sadly the USB-C does not yet work. Although I could plug a keyboard into the top USB 3 port, if I attempted to plug in any USB wireless dongle, for a mouse/keyboard combo, nothing is registered. I can confirm that the vertical USB port does not work either, although not surprising since it is directly linked to the USB-C. Definitely a step forward though and I have no doubt that when Rockchip release their 6.1 SDK in the next few weeks, we should see easier OS implementation.

Anything with it's own 2.4Ghz USB dongle should work because the wireless connectivity happens outside of the Orange Pi board sphere. I have a variety of them, from the Logitech 400 to the cheapest of the Rii style clones. So my own focus would be on which device has the best battery usage and which keyboards and trackpads etc seem to have the best tactile inputs, which is where carrying out some YouTube reviews will likely give you more ideas of which ones may suit your tastes and needs.

I can quite understand the frustrations of @Paulo da Silva, even though, it is not the board that is the issue, but the company, Orange Pi, who are next to useless and absent when it comes to support. They show that they are essentially, only box shifters. Whilst the (very useful) process specified by @vandyman, seems easy, when it comes to changing the boot to NVME, the menu options are written in such a manner that it can be confusing to know exactly which specific option to use. And even then, to then decide to want to boot from USB, the options have to be changed again, which then renders NVME null unless the process is run yet again. In terms of a solution, based on the line from @royk, 'With the Orange Pi 5 plus I didn't even had to update the bootloader to make it boot from NVME', this would indicate that Orange Pi corrected the boot process for the Plus model, so why not do the same for the prior 2 models? The original bootloader boot process should have been simple. 1. MicroSD card 2. USB (any port) 3. MVME That, IMO, would have satisfied most users needs and removed the frustrations. You could still have options in the config for people to modify that for their specific purposes but having an easy to understand base of priority boot ports was always the way to go. So why didn't they do it? Was it because, not unlike their vaunted and much touted Orange Pi OS, which is half baked and (still) half finished, they only put half the effort in to shove the board off the shelves? All evidence would suggest so. But with a complete absence of them making any comment, we may never know. Bottom line right now is that all real efforts are coming from and will have to continue to come from communities and users. Forget Orange Pi the company as they are nowhere to be seen in any useful and practical terms. It is somewhat ironic that they have (and were the first), to obtain Platinum support and yet there is no evidence that I can see that they have provided Armbian any service that could be seen to be even close to what might be considered such. All the promise of Orange Pi the company has become rather tarnished, following them taking an instant and decisive lead in the RK3588 SBC arena. I am sure that with time we will see more maturity for the SOC and I/O over time, which was always to be expected with a new product but as far as this vendor is concerned, they won't ever get any of my money again because they have shown what they are at a base level. If a company said hey, we are a box shifter, then you know from the start what you are going to get but when they tell you that their new product and OS combination will change everything and then doesn't even come close , how can they ever be trusted?

RK3588 isn't supported by Libreelec yet though.

There does seem to be some movement on Kodi being able to play X265 (which I believe also encompasses those with HDR) correctly. https://github.com/batocera-linux/batocera.linux/issues/9182 I'm not exactly sure what the specific github meaning of 'planned' is but I would guess that it is an indication of action being in the works.