btrfs send snapshot gives ERROR: could not resolve root_id

asked 2014-02-01 21:36:32 +0300

mobile
318 ●7 ●11 ●13

updated 2014-02-01 22:15:02 +0300

Hi Jolla-Team!

I wanted to send my btrfs snapshot from the phone to a debian vm and got the following error, that may be related to an old kernel/btrfs version.

devel-su

btrfs subvolume snapshot -r / /backup_0

[root@localhost nemo]# btrfs send /backup_0 | ssh 192.168.2.8 -p 9000 btrfs receive /home

At subvol /backup_0

ERROR: could not resolve root_id for /backup_0

Sending / Receiving BTRFS-Snapshots between 2 Debian-VMs in VirtualBox (NAT + PortForwarding) is working without a problem:

Linux debianbtrfs 3.12-1-486 #1 Debian 3.12.6-2 (2013-12-29) i686 GNU/Linux

Linux debianBTRFS2 3.12-1-486 #1 Debian 3.12.6-2 (2013-12-29) i686 GNU/Linux

VM1

root@debianbtrfs:/# btrfs subvolume snapshot -r /home /home/snap1

Create a readonly snapshot of '/home' in '/home/snap1'

root@debianbtrfs:/# btrfs send /home/snap1 | ssh 10.0.2.3 -p 9000 btrfs receive /home/

At subvol /home/snap1

root@10.0.2.3's password:

At subvol snap1

VM2

root@debianBTRFS2:/home# ls

snap1 user

edit retag flag offensive close delete

Comments

Same problem for me

gcobb ( 2014-03-20 23:53:31 +0300 )edit

same issue... it appears there are patches to btrfs-progs that fix this... perhaps those patches (or a newer version of btrfs-progs) can be done? send patch , receive patch

AL13N ( 2014-06-23 23:59:35 +0300 )edit

I tried an updated version from https://build.merproject.org/package/binaries/nemo:devel:mw/btrfs-progs?repository=latest_armv7hl but that fails too. Error message "ERROR: send ioctl failed with -25: Inappropriate ioctl for device". So either there's too much version mismatch between the userspace (3.16) and kernel (3.4+Jolla backports), or there's yet something missing from the kernel space required to perform a send.

Ballock ( 2014-10-21 23:36:27 +0300 )edit

AL13N: I just found the sources. It wasn't easy, but those are public, of course. The bad news is that btrfs-progs-0.20rc1+git358.4-1.1.2.armv7hl already has the patches you mention applied. Let me know if you have any other patch ideas.

Ballock ( 2014-10-23 00:31:28 +0300 )edit

is that the version that we're actually using, or is that the version in nemo that needs to be pushed to jolla internally? did you build and check that version too? i'm saying that, because it looks pretty much exactly what that patch is...

AL13N ( 2014-10-23 13:05:01 +0300 )edit

answered 2018-01-28 03:15:21 +0300

prometheos de+it

143 ●8 ●14 ●21

@DrYak in his answer to a question of mine mentions:

"... btrfs send isn't functionnal, but you can at least setup a periodic rsync.."

Perhaps @DrYak could explain why this functionality is failing?

I myself am planning to backup in two stages: first by rsync to my Ubuntu laptop. If I set the target to a btrfs snapshot, it must be possible to mockup the send/receive mechanics, and then send it further . The mounted snapshot is then subjected to its own backup: the second stage. (I will have deal with send/receive inside own backup program, when I will convert it from rsync to btrfs send/receive).

But I have first to work it out (#todo).

Comments

Regarding why: I haven't investigated further since last time I've noticed.

I would suspect this is due to BTRFS on Sailfish OS being a weird mix of much more recent user-land tools (I think btrfs is 4.x ? Or at least 3.18, for sure), and back-ported btrfs kernel drivers (it's not stock BTRFS from kernel 3.2, the Jolla dev team has backported bugfixes).

This makes a much stabler and better experience than running stock 3.2 kernel's btrfs. But it might mean that something somewhere is the wrong verison,

Regarding the rsync : Yup should work (options to use: rsync -avPHAX --inplace. (Note: --inplace conflicts -S so you lose a tiny bit efficiency on sparse files). In fact, you can use a tool like "snapper" to handle automatic creates of snapshots to get a history on your backup btrfs device (That's how I handle it).

(and by having multiple snapshots, it makes "btrfs send" even more efficient by only sending deltas between the lastest snapshots)

DrYak ( 2018-01-28 23:54:14 +0300 )edit

A few more tips regarding backups :

if you use snapper, you can also use rsync's option --delete to remove files that aren't in the source anymore to exactly replicate the content of the Jolla Phone. (As you use snapper, it doesn't matter, the files will still be accessible from the older historical snaps).
use something like mount -o subvolid=0 /dev/mmcblk0p28 /mnt/ and then rsync the contents of /mnt/@ and /mnt/@home so you exactly sync your data, and avoid all the other mount points in the smartphone root (devices, temps, etc.)

DrYak ( 2018-01-28 23:59:16 +0300 )edit

btrfs send snapshot gives ERROR: could not resolve root_id

Comments

1 Answer

Comments

Question tools

Stats

Related questions

btrfs send snapshot gives ERROR: could not resolve root_id

Comments

1 Answer

Comments

Question tools

Public thread

Stats

Related questions