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.

Up vote post of sux2mfgj Down vote post of sux2mfgj
5.2k views
Posted by
sux2mfgj
Reply
Add a Comment

Replies

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
Posted by
Naoned
Up vote reply of Naoned Down vote reply of Naoned
Add a Comment
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.
Posted by
sux2mfgj
Up vote reply of sux2mfgj Down vote reply of sux2mfgj
Add a Comment
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.
Posted by
Naoned
Up vote reply of Naoned Down vote reply of Naoned
Add a Comment
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



Posted by
Naoned
Up vote reply of Naoned Down vote reply of Naoned
Add a Comment
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…
Posted by
Naoned
Up vote reply of Naoned Down vote reply of Naoned
Add a Comment
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.
Posted by
LKQuestions
Post not yet marked as solved Up vote reply of LKQuestions Down vote reply of LKQuestions
Add a Comment
macOS 11.1 (20C69)
Having the same issue. What could one do to fix it?
Posted by
apsiedler
Up vote reply of apsiedler Down vote reply of apsiedler
Add a Comment
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.
Posted by
tjehlar
Up vote reply of tjehlar Down vote reply of tjehlar
Add a Comment