mwilck / btrfs-clone

A tool for copying a btrfs file system with all its subvolumes to another btrfs file system
GNU General Public License v2.0
116 stars 17 forks source link

Cloning attempt immediately fails with `cannot flip ro->rw with received_uuid set` #14

Closed jmrohwer closed 11 months ago

jmrohwer commented 3 years ago

Running Manjaro linux, kernel version 5.10.70-1-MANJARO btrfs-progs version 5.14.2-1

[jr-yoga900 ~]# btrfs-clone --verbose --verbose --verbose /btrfs /mnt/backup 
unsharing mount namespace
OLD btrfs 2f7b6b96-af7b-441a-946e-3fa3f0e409b5 mounted on /tmp/tmpck00p3rs
NEW btrfs bf70e57f-71ba-480a-b988-227c9d144f87 mounted on /tmp/tmphohd6a3_
Create a readonly snapshot of '/tmp/tmpck00p3rs' in '/tmp/tmpck00p3rs/694e3bac37f6'
btrfs send -v -v -v /tmp/tmpck00p3rs/694e3bac37f6 |
         btrfs receive -v -v -v /tmp/tmphohd6a3_
btrfs property set /tmp/tmphohd6a3_/694e3bac37f6 ro false
ERROR: cannot flip ro->rw with received_uuid set, use force if you really want that
Traceback (most recent call last):
  File "/home/jr/.local/bin/btrfs-clone", line 844, in <module>
    main()
  File "/home/jr/.local/bin/btrfs-clone", line 839, in main
    new_mnt = send_root(old_mnt, new_mnt)
  File "/home/jr/.local/bin/btrfs-clone", line 251, in send_root
    maybe_call([opts.btrfs, "property", "set", new_snap, "ro", "false"])
  File "/home/jr/.local/bin/btrfs-clone", line 45, in maybe_call
    check_call(*args, **kwargs)
  File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['btrfs', 'property', 'set', '/tmp/tmphohd6a3_/694e3bac37f6', 'ro', 'false']' returned non-zero exit status 1.
Delete subvolume (no-commit): '/tmp/tmpck00p3rs/694e3bac37f6'

It looks like it has to do with this set of patches: https://lore.kernel.org/linux-btrfs/20211004152229.GA9286@twin.jikos.cz/T/

What are the possible downsides of using --force in this case? I am trying to copy my btrfs filesystem to a new computer via an intermediate removable ssd. Possible corruption on the destination (new) filesystem is not a problem as I can check for that, but possible corruption on the original (old) filesystem is problematic and I don't want to risk damaging that filesystem.

The filesystem has a number of linear timeline snapshots created by snapper that I want to preserve.

wileyvic commented 2 years ago

Having the same issue trying to clone a disk with Garuda Linux installed. I even tried running the script with --force and --ignore-errors args given and I am still getting the same error message and the script fails.

Opened my own ticket for my issue, but seeing as this has been opened and unaddressed for months I'm not feeling optimistic about getting any help here. If I manage to find a solution I'll post back.

Sepero commented 1 year ago

A simple work around for making the subvolume writable is just make a new snapshot of the subvolume. You can then delete the original.