You are not logged in.
I was on the btrfs gotcha page and came across something that may be related.
Do not make a block-level copy of a btrfs filesystem to a block device, and then try to mount either the original or the copy while both are visible to the same kernel.
.
.
.
This problem is due to the UUID on the original and the copy being the same. This confuses the kernel, and it can end up writing updates to the wrong filesystem, causing massive data corruption.
Offline
That looks like a different problem. Copying GPT partitions with sgdisk creates a duplicate by-partlabel or by-partuuid. zfs and btrfs copy the contents whatever way they want. Copying an entire disk including contents will bypass btrfs internal management of by-uuid and create duplicates.
Offline
I'm just throwing it out there. Yeah, I agree that is it's own issue, but there is a bit of similarity there. Where there is similarity, there is reason to consider it.
I'm not changing this from solved, nor am I worried. Still. Something to think about.
Offline
The problem is with the partlabel, not the label:
% lsblk -o NAME,PARTLABEL
NAME PARTLABEL
sda
├─sda1 Linux filesystem
├─sda2 Linux filesystem
├─sda3 Linux /home
│ └─home
└─sda4 Linux swap
I used `cgdisk` option `m` as @paneless suggested.
Juan Manuel
Offline
joksnet, you've been here long enough to know not to necrobump, especially a solved thread.
Offline
Closing.
Offline