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?