Cannot replicate a bootable Big Sur using asr.

Hi, all.

Question is:
Is there correct way to replicate the bootable big sur apfs volumes.

My understanding is that Big sur introduces Signed System Volume. It has cryptography hashes of data and metadata in filesystem. Especially, a hash of metadata is called "seal", and we can see that via diskutil command.

I can replicate a apfs volume group that includes signed system volume and data volume, but a seal of replicated volume was broken and macos cannot boot from the volume.

Details are following.

I tried to make a replication of the system volume group using asr. The making replication is working successfully.
The ROSV is mounted a snapshot, so I specified it, like a following command.
Code Block shell
$ asr restore --source /dev/disk1 --toSnapshot ${snapshot_id} --target /dev/disk2 --erase


However, the seal is broken.
Code Block shell
$ diskutil apfs list /dev/disk2
shunsukemie@zeit129000 /Volumes % diskutil apfs list disk1
|
+-- Container disk2 .....
  ====================================================
  APFS Container Reference:   disk2
...
+-> Volume .....
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s2 (System)
| Name: HD-System (Case-insensitive)
| Mount Point: /Volumes/HD-System
| Capacity Consumed: 16089018368 B (16.1 GB)
| Sealed: Broken
| FileVault: No (Encrypted at rest)
...


Thanks a lot.

I have a slightly different problem: I can't make replication work.

Code Block
sudo asr restore --source / --target /Volumes/BB --erase
Validating target...done
Validating source...
Source volume format on device "/dev/disk4s5s1" is not valid for restoring
Could not validate source - Permission denied

or
Code Block
sudo asr restore --source /dev/disk4s5 --target /dev/disk5s1 --erase
Validating target...done
Validating source...
The source volume cannot be restored because it has a broken seal
Could not validate source - Invalid argument

Indeed, APFS seal seems broken on my system volume. But I don't know what could have broke this seal, how to fix that, and why it prevents completely volume replication from working
Hello, Naoned.
Could you try to specify a snapshot using --toSnapshot with snapshot id?
The id is shown in diskutil apfs list.

I think the system volume is mounted on a snapshot.
In my environment, disk2s5s1 is snapshot. it has correct seal and mount on '/'.
Code Block shell
$ diskutil list apfs
...
   +-> Volume disk2s5 D75FFE69-60AA-4C51-A3DE-52B1753DA61D
    ---------------------------------------------------
    APFS Volume Disk (Role):  disk2s5 (System)
    Name:           sysapfs (Case-insensitive)
    Mount Point:        /Users/username/mnt
    Capacity Consumed:     15121588224 B (15.1 GB)
    Sealed:          Broken
    FileVault:         No (Encrypted at rest)
    |
    Snapshot:         5891FB51-B637-4CC6-8EEF-959D961167C8
    Snapshot Disk:       disk2s5s1
    Snapshot Mount Point:   /
    Snapshot Sealed:      Yes


In addition, Bombich Software (they makes Carbon Copy Cloner) also face a same obstacle, and they're working with Apple.
Thanks sux2mfgj.

I just installed beta 7, and there are some improvements: my startup disk is now correctly sealed.

I tried with "toSnapshot" option on beta 7, and it's better: I can see a different error :)

Code Block sudo asr restore --source "/dev/disk3s5" --toSnapshot "70DEFB5A-985F-410F-A013-CD0839B345EE" --target "/dev/disk1"
Validating target...done
Validating source...done
Couldn't set up partitions on target device - operation AddAPFSVolumeToContainer, line #5330 - error 49231


I also noticed that other vendors have the same problem. Let's hope it will be fixed for GM.
Beta 8 is better. I can finish the apfs operation:
Code Block sudo asr restore --source /dev/disk1s7 -toSnapshot "FE39B97C-8747-47EF-B3CD-A2D3CDC53476" --target /dev/disk3s2 --erase --noprompt
Password:
Validating target...done
Validating source...done
Replicating ....10....20....30....40....50....60....70....80....90....100
Replicating ....10....20....30....40....50....60....70....80....90....100
Restored target device is /dev/disk3s2.
Restore completed successfully.


However, the result is not shown in System Preferences…
Code Block     +-> Volume disk3s3 4B2A807B-B7D7-4385-9F5F-4B34CFB17F50
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk3s3 (Data)
    |   Name:                      macOS Big Sur - Données (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         40842784768 B (40.8 GB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk3s2 B47FE0AC-CD4C-4444-BE16-785C96F6EFD5
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk3s2 (System)
    |   Name:                      macOS Big Sur (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         15706312704 B (15.7 GB)
    |   Sealed:                    Broken
    |   FileVault:                 No
    |
    +-> Volume disk3s4 72F5627F-D60D-40A7-B1C9-CED3A8BD80E3
    |   ---------------------------------------------------
    |   APFS Volume Disk (Role):   disk3s4 (Preboot)
    |   Name:                      Preboot (Case-insensitive)
    |   Mount Point:               Not Mounted
    |   Capacity Consumed:         528404480 B (528.4 MB)
    |   Sealed:                    No
    |   FileVault:                 No
    |
    +-> Volume disk3s5 29D5A484-E049-4239-8D4C-8ECDBEED7B67
        ---------------------------------------------------
        APFS Volume Disk (Role):   disk3s5 (Recovery)
        Name:                      Recovery (Case-insensitive)
        Mount Point:               Not Mounted
        Capacity Consumed:         765935616 B (765.9 MB)
        Sealed:                    No
        FileVault:                 No



In beta 9, asr did almost work. By almost, I mean that the command succeeded, but the resulting volume is still not bootable.

But there is a regression in beta 10 : the command failed. I tried several options, but it's ending on a failure on:
"Couldn't embed the APFS EFI driver - erreur 49174"

I hope this is not the GM…
You can now clone Big Sur to a bootable external hard drive. This happened with the most recent version of Big Sur, 11.0.1. I used CCC 5.1.23 beta (the current version at time of writing this), and was able to create a bootable external drive.
macOS 11.1 (20C69)
Having the same issue. What could one do to fix it?
I would seem to be having the same problem in the latest preview build 11.2 Beta. I cannot see how it would happen from actual file system corruption in my case. It starts fine and first aid under disk utility finds no errors. I was trying to run this in recovery mode for migrating to a larger SSD using the restore feature in disk utility, running asr in Terminal had the same issue. I will just install macOS to the new one and use Migration Assistant instead.
Cannot replicate a bootable Big Sur using asr.
 
 
Q