piclone can't write the devices as a normal user, but doesn't see the devices as an elevated user

[Heptite]

piclone is a non-starter for me because if I start it as an elevated user, it sees no devices for input or output. If I start it as a normal user ("pi") it sees the devices, I can select them, but then it errors:

WARNING: You are not superuser. Watch out for permissions. Error: Error opening /dev/mmcblk0: Permission denied

[spl237]

It will only work with the command which launches it in the desktop file - "sudo dbus-launch piclone". Both of these are required - it needs sudo permissions for many of the gparted-type operations it performs, and it needs dbus-launch so it accesses the session bus for the drive monitor rather than the system bus which would otherwise be used with sudo.

Just running "piclone" from the command line will not work - I suspect you are missing the dbus-launch command above, because the drive monitor (which is what finds the input and output devices) will not work on the system dbus.

[Heptite]

That does get me further, but it still doesn't quite work:

% XAUTHORITY=/home/pi/.Xauthority sudo dbus-launch piclone

umount: /dev/sda9: mountpoint not found umount: /dev/sda8: mountpoint not found umount: /dev/sda7: not mounted umount: /dev/sda6: not mounted umount: /dev/sda5: not mounted umount: /dev/sda4: mountpoint not found umount: /dev/sda3: mountpoint not found umount: /dev/sda2: not mounted umount: /dev/sda1: not mounted 1+0 records in 1+0 records out 512 bytes copied, 0.0117627 s, 43.5 kB/s Error: Partition(s) 1, 5, 6, 7 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.

For what it's worth I'm launching it over an SSH session. Direct access to the console is difficult in my current configuration.

Edit: I should also have noted that the tool says it could not create the FAT.

[spl237]

Piclone is known not to work over SSH, for various permissions-related reasons. We might get around to fixing this at some point, but it's not a high priority, as we reckon that anyone who knows enough to be able to use SSH can probably work out how to clone a card anyway.

If you download the source package (apt-get source piclone), there is a shell script called "backup" in the src subdirectory which was the original prototype for the operations performed by the graphical application - you might have more luck with that from SSH.

[Heptite]

I'm not surprised about the SSH issues. I did hook the RPi to a console and tried it directly, but it gave me the exact same errors, even invoked from the system GUI menu.

[gsportelli]

As of today, it works for me via SSH. The differences from what was described above are that I use screen to launch sudo dbus-launch piclone and that instead of setting XAUTHORITY=/home/pi/.Xauthority I've enabled sudo X11 forwarding with the following commands as suggested here:

xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
sudo su
xauth add `cat /tmp/xauth`

[chris-bishop]

In case it's at all helpful to other RPi / SBC newcomers like myself...here's what worked for me on Raspberry Pi 4B+ // Ubuntu 20.10 Groovy aarch64...

Brief SysInfo:

cbishop@cbishop-ubuntu:~$ uname -a
Linux cbishop-ubuntu 5.8.0-1019-raspi #22-Ubuntu SMP PREEMPT Mon Mar 22 09:37:28 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
cbishop@cbishop-ubuntu:~$ 
cbishop@cbishop-ubuntu:~$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.10 (Groovy Gorilla)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.10"
VERSION_ID="20.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=groovy
UBUNTU_CODENAME=groovy
cbishop@cbishop-ubuntu:~$ 

Used the following steps to build and install from source:

# Build piclone util from source
# Git: https://github.com/raspberrypi-ui/piclone

# lib dir where we want to store source and deps
cd /usr/lib/aarch64-linux-gnu

# clone git repo in current dir
sudo git clone https://github.com/raspberrypi-ui/piclone

# cd in to project root
cd piclone

# install build deps
sudo mk-build-deps --install debian/control

# prepare build env
sudo ./autogen.sh

# config build env - NOTE - this would overwrite any previously installed apt version!
sudo ./configure --prefix=/usr --libdir=/usr/lib/aarch64-linux-gnu

# build
sudo make

# install
sudo make install

# verify install
which piclone

# verify piclone.desktop entry
ls -ltr /usr/share/applications/piclone.desktop

# to run, you must execute from the desktop entry ("shortcut") in Ubuntu Applications or Activities view! 
# Running from the command line will not work natively! 
# See: https://github.com/raspberrypi-ui/piclone/issues/14

# Launch Ubuntu Applications or Activities view > Search SD Card Copier > Launch

# Enjoy! :-)

I hope this might help others, as since switching to Ubuntu 20.10 64bit from Raspbian 32bit (to take full advantage of my RPi 4B+ hardware) I have REALLY been missing the convenience of the Raspbian SD Card Copier application for quick and easy backups / clones...

Thank you Raspberry Pi for all that you do! As a career IT Engineer myself, I absolutely love what you do for our future scientists and engineers! I only hope that through my own learning I may continue to contribute as well!

[spl237]

I hope this might help others, as since switching to Ubuntu 20.10 64bit from Raspbian 32bit (to take full advantage of my RPi 4B+ hardware)...

FWIW, Ubuntu 64-bit wll be taking far less advantage of the RPi hardware than Raspbian 32-bit!

The only advantage a 64-bit OS will offer over 32-bit Raspbian is if you are using any individual application which requires more than 4GB of RAM (which is very rare).

With the Raspbian kernel, the 64-bit 4GB RAM limit is per-application; it's not that 4GB out of the 8GB is unavailable to anything. Raspbian can allocate up to 4GB of independent RAM to multiple applications running simultaneously, so hypothetically if you were running two applications which both required 3GB, they would both get it, and there would still be 2GB free for the OS / desktop / whatever.

However, if you are using another OS like Ubuntu, you have none of the custom hardware acceleration libraries which make use of the Pi's dedicated video hardware, or those which accelerate things like memory access. For example, Chromium and VLC in Raspberry Pi OS are both hardware-accelerated for the Pi; in Ubuntu, they aren't; the difference in performance is significant.

We spend a lot of time optimising Raspberry Pi OS specifically for the Raspberry Pi hardware. It's worth benchmarking your particular use cases under Raspberry Pi OS and under Ubuntu. You'll probably find that they'll actually run slightly better under Raspberry Pi OS...

And if you are running really RAM-hungry apps, you can actually have the best of both worlds by using the 64-bit version of Raspberry Pi OS, which does have at least some of our hardware acceleration (albeit not that for Chromium or VLC yet) - the beta is available at https://www.raspberrypi.org/forums/viewtopic.php?t=275370