I have something I'd like to try, but I've hosed my BS 11.3 installation and I won't have time to reinstall until this weekend. Perhaps some kind (or curious, or desperate) soul will give this a try and report back:
First, you need to determine the Volume/Disk/Partition GUID of your Big Sur 11.3 (or 11.4 beta) boot volume.
In Terminal, run
diskutil list
and identify your boot volume - it should show up as "/dev/diskN (synthesized):", where N is some number, partition 0 is "APFS Container Scheme", there's a line that says "Physical Store diskXsY" (where X and Y are numbers), then partition 1 is an APFS Volume with a reecognizable name, presumably something like "Big Sur". There will be two such partitions, one named with the base name (e.g. "Big Sur"), the other with " - Data" appended to it (e.g. "Big Sur - Data"). Note the disk number ("/dev/diskN (synthesized)") and which partition number contains the base name WITHOUT " - Data" appended.
(Here's a concrete example:
Code:
/dev/disk5 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +239.9 GB disk5
Physical Store disk3s2
1: APFS Volume Big Sur 11_1 - Data 5.3 GB disk5s1
2: APFS Volume Preboot 248.6 MB disk5s2
3: APFS Volume Recovery 613.6 MB disk5s3
4: APFS Volume VM 1.1 MB disk5s4
5: APFS Volume Big Sur 11_1 16.3 GB disk5s5
6: APFS Volume Update 413.7 KB disk5s6
In this example, the disk number is 5 (from "/dev/disk5"), partition 1 is the data partition ("Big Sur 11_1 - Data"), and partition 5 is the base ("Big Sur 11_1")).
Once you know the disk number and base partition number, run
diskutil info diskNsY
where N is your disk number and Y is the base partition number. You should see something like this:
Code:
Device Identifier: disk5s5
Device Node: /dev/disk5s5
Whole: No
Part of Whole: disk5
Volume Name: Big Sur 11_1
Mounted: Yes
Mount Point: /Volumes/Big Sur 11_1
Partition Type: 41504653-0000-11AA-AA11-00306543ECAC
File System Personality: APFS
Type (Bundle): apfs
Name (User Visible): APFS
Owners: Enabled
OS Can Be Installed: Yes
Booter Disk: disk5s2
Recovery Disk: disk5s3
Media Type: Generic
Protocol: SATA
SMART Status: Verified
Volume UUID: D5711839-E42A-4782-9172-E0DF14B21CDF
Disk / Partition UUID: D5711839-E42A-4782-9172-E0DF14B21CDF
Disk Size: 239.9 GB (239855427584 Bytes) (exactly 468467632 512-Byte-Units)
Device Block Size: 4096 Bytes
Volume Total Space: 239.9 GB (239855427584 Bytes) (exactly 468467632 512-Byte-Units)
Volume Used Space: 22.6 GB (22643900416 Bytes) (exactly 44226368 512-Byte-Units) (9.4%)
Volume Free Space: 217.2 GB (217211527168 Bytes) (exactly 424241264 512-Byte-Units) (90.6%)
Allocation Block Size: 4096 Bytes
Read-Only Media: No
Read-Only Volume: No
Device Location: Internal
Removable Media: Fixed
Solid State: Yes
Hardware AES Support: No
Device Location: "Bay 1"
The values for "Volume UUID" and "Disk / Partition UUID" should be identical; copy that string (in this example,
D5711839-E42A-4782-9172-E0DF14B21CDF
).
Now, set your boot-args to include the following:
Code:
rd=uuid boot-uuid=The_UUID_you_just_copied
(using the diskutil output from above, our example would be
rd=uuid boot-uuid=D5711839-E42A-4782-9172-E0DF14B21CDF
). If you're running OpenCore, you probably need to edit config.plist and change boot-args there. (Remember to keep any debugging-relevant boot-args, such as
-v
or
debug=0x100
)
Once you have
rd=uuid boot-uuid=Some_UUID
in your boot-args, try booting Big Sur 11.3 and see if it makes any more progress than usual.
(For those who are interested: the first half or more of 11.3's IOFindBSDRoot() is identical to the binary of 11.1 and the source code for 11.2, but then it diverges. With limited time available, I'm hypothesizing that it's getting stuck trying to boot from either a RAMdisk or a network device, and by forcing it to use the correct disk partition, we might get past this particular hurdle. If setting the boot-uuid doesn't do it, there are still some other things to try.)
Thanks, and good luck. I should be able to check back in tomorrow.
IMPORTANT REMINDER: be sure you have a natively bootable partition available to you; if this (or any similar) experiment goes badly, you'll need to do a PRAM reset to get rid of the problematic boot-args, after which your OpenCore setup may or may not boot correctly.
(EDIT: even if this works, you'll still want to do a PRAM reset, since with
rd=uuid boot-uuid=...
in the boot-args, the
only MacOS disk you'll be able to boot will be the BS 11.3 disk...)