Bootable volume renaming issue
I apologise if this has been addressed before, but I've been unable to locate the specific instruction to rename an EFI volume. I initially installed Big Sur on a volume called "macOS Big Sur". Subsequently I upgraded to Monterey and changed the Volume from "macOS Big Sur" to "macOS Monterey" in a hope to change the icon name in OCLP picker screen. However, it still shows "macOS Big Sur" even though the icon has changed to Monterey. I've read somewhere mentioning a program called disklabel in
here. But I don't see this program in my OCLP EFI (v0.3.3) and also not sure what to do with it anyway.
Your help will be greatly appreciated. Better still, to add this feature in the future OCLP release.
I was in the same situation (BS -> OTA Monterey), but Intel Power Gadget doesn't work with my *DP* MP5,1 ?
Searching for Preboot re-construction, I found an article from 2019 discussing APFS problems.
After converting your MacOS hard disk to APFS, you could run into a situation where your Mac is no longer bootable and you get errors like "Building boot
www.tecklyfe.com
The author suggested entering Recovery, then (in terminal) use:
Code:
# diskutil apfs updatePreboot /Volumes/Macintosh\ HD/
The thought of waiting for the Recovery to boot gave me chills (and I don't have 'Macintosh\ HD/'), so, let me have some fun...
In a regular User Terminal session, I elevated my terminal to an admin account:
Code:
% diskutil apfs
Usage: diskutil [quiet] ap[fs] <verb> <options>
where <verb> is as follows:
[...]
updatePreboot (Update a macOS Volume's related APFS Preboot Volume)
[...]
Further:
Code:
% diskutil apfs updatePreboot
Usage: diskutil apfs updatePreboot <apfsVolumeDisk> [-noGlobalEFIGraphics]
[-od <overrideODFullPath> | "/"]
where <apfsVolumeDisk> = APFS Volume DiskIdentifier
-noGlobalEFIGraphics overrides for-all-users localized rendering
<overrideODFullPath> = use this path instead of on-APFS-Volume
Examine the given APFS Volume for macOS and Open Directory (OD) database files,
correlate the Volume's APFS crypto users with OD users, and update the related
Preboot Role Volume's Subject Directory with data such as EFI login graphics.
Specifying "/" for <overrideODFullPath> will use /var/db/dslocal/nodes/Default.
No crypto passdata is needed, but ownership of the affected disks is required.
Example: diskutil apfs updatePreboot disk5s1
This is IT! Hmmm . . . where is IT?
Code:
% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 2.0 TB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +2.0 TB disk1
Physical Store disk0s2
1: APFS Volume Monterey - Data 370.5 GB disk1s1
2: APFS Volume Monterey 15.8 GB disk1s2
3: APFS Snapshot com.apple.os.update-... 15.8 GB disk1s2s1
4: APFS Volume Preboot 355.9 MB disk1s3
5: APFS Volume Recovery 1.1 GB disk1s4
6: APFS Volume VM 1.1 MB disk1s5
APFS splits the default "Macintosh HD" into two, distinct Volumes:
A) The SSV (Sealed/Signed System Volume); a mounted snapshot of the unmounted read-only System volume named "Macintosh HD"
B) The writable Data volume named "Macintosh HD – Data"
In Monterey, these haven’t changed much since Big Sur. However, those small differences are significant, particularly on M1 Macs.
eclecticlight.co
My /dev/disk1 (synthesized) Container has a "Monterey - Data" Volume @ /dev/disk1s1, which was my intended target.
I then ran:
Code:
% diskutil apfs updatePreboot /dev/disk1s1
Started APFS operation
UpdatePreboot: Commencing operation to update the Preboot Volume for Target Volume disk1s1 (Monterey - Data)
UpdatePreboot: Commanded forwarding to System-role regardless of target input = InhibitAutoGroupTarget = 0; ForwardingEnabled
UpdatePreboot: Commanded moving Preboot/etc UUID dirs from old to modern = MigrateSubjectDir = 1; MigrationEnabled
UpdatePreboot: The Target Volume is part of APFS Container disk1
UpdatePreboot: The Data-sibling or self of the target is disk1s1 err=0
UpdatePreboot: The Target (normalized to Data-role) Volume's non-special-kind-probably-OD user count is 2 and the Recovery (any of 4 kinds) user count is 0
UpdatePreboot: There are OpenDirectory user(s) but no Recovery user(s)
UpdatePreboot: The above is an abort condition for some purposes but not UpdatePreboot; continuing
UpdatePreboot: The Target Volume is part of APFS Volume Group AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE
UpdatePreboot: Explicit macOS and OD source paths given to the UP core
UpdatePreboot: Sourcing VAR directory relative to source macOS
UpdatePreboot: Sourcing USR directory relative to source macOS
UpdatePreboot: Search Path For macOS Source Files = (nil=NotMounted) = /
UpdatePreboot: Directory That macOS "var" Is Searched To Be In = (nil=NoMacOS) = /
UpdatePreboot: Directory That macOS "usr" Is Searched To Be In = (nil=NoMacOS) = /
UpdatePreboot: Open Directory Database Search Path = (nil=MacOSSearchPathNotMounted) = /var/db/dslocal/nodes/Default
UpdatePreboot: Preserve EncryptedRootPList When No-OD = 0
UpdatePreboot: Successfully opened Open Directory database; setting AuthODNodeOrNil accordingly
UpdatePreboot: Mounting and ensuring as mounted the related Preboot Volume
UpdatePreboot: Preboot Volume = disk1s3 (Preboot)
UpdatePreboot: Preboot Volume Target Directory (currently in use; no migration, if any, yet) = /System/Volumes/Preboot/AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE
UpdatePreboot: Taking mount hold on Preboot Volume
UpdatePreboot: Migrating UUID Folder name as necessary
[...]
UpdatePreboot: Exiting Update Preboot operation with overall error=(ZeroMeansSuccess)=0
Finished APFS operation
I did not have to re-bless, or select System Startup.
Now I can re-boot to "Monterey" in the OC booter
hth