Incorrect device identified as "booted EFI"

[brianlamb]

I'm hoping this is worthy of an 'issue' report. Please let me know if there is a better/preferred way to report something like this. Thanks!

I believe I boot from the "Sab256" disk's EFI and in this case macOS 11.5.2 is installed and running from Kingston120 (an external USB3 ssd)

Any other info helpful?

  #######################################################
 #                     MountEFI                        #
#######################################################

1. Kingston120 (disk9s1s1)
2. Sab256 (disk6s5)
3. Sab256 - Data (disk6s1)
4. SanDisk256 (disk11s1) *
5. None (disk4s4)
6. WDBlue1TB (disk7s5)
7. WDBlue1TB - Data (disk7s1)

S. Switch to Full Output
L. Set As Default Layout (Current: Slim)
B. Mount the Boot Drive's EFI

D. Pick Default Disk (None Set)
M. After Mounting: Return to Menu
R. Toggle Window Resizing (Currently Enabled)
Q. Quit

(* denotes the booted EFI (Clover/OC))
Pick the drive containing your EFI:

Selecting option 4

  #######################################################
 #                 No EFI Partition                    #
#######################################################

There is no EFI partition associated with disk11s1!

Press returning in 3 seconds...

nvram -p output: nvram.txt

diskutil list output: diskutil.txt

Kingston120 (OS Boot) OC Log: opencore-2021-08-25-042711(Kingston120-EFI).txt

Sab256 (UEFI Boot Device) OC Log: opencore-2021-08-25-052334 - SAB256 - UEFI Boot Device.txt

=== I could be mistaken about the EFI drive but this is my usual preferred EFI boot partition. I was indeed trying to figure out a definitive way myself to identify the actual EFI drive used when encountering this error. I checked and indeed the current Kingston EFI drive does not have the custom USBMap that the Sab256 drive does and they show up in my System Profiler and IORegistry Explorer.

[corpnewt]

Hey there - thanks for the info and thorough explanation of the issue you're experiencing. MountEFI determines the "booted EFI" by checking NVRAM for OpenCore's boot-path or by querying ioreg for Clover's SelfDevicePath. Both of these are stored as UUIDs - which makes them likely unique.

Could you run the following commands in terminal and show me the output?

1. nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.*GPT,\([^,]*\),.*/\1/'
2. diskutil list $(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.*GPT,\([^,]*\),.*/\1/')
3. diskutil info $(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.*GPT,\([^,]*\),.*/\1/')

That may shed some light on the issue. It's also worth noting that in order to properly reveal the boot-path via OpenCore, you must ensure your ExposeSensitiveData includes 0x1 per the following description of the setting (listed in the Security Properties located here):

• 0x01 — Expose the printable booter path as an UEFI variable.
• 0x02 — Expose the OpenCore version as an UEFI variable.
• 0x04 — Expose the OpenCore version in the OpenCore picker menu title.
• 0x08 — Expose OEM information as a set of UEFI variables.

Hopefully that will shed some light on what's going on.

-CorpNewt

[brianlamb]

Yes, I saw that call to the nvram command and tried it before:

nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path': (iokit/common) data was not found

I have "ExposeSensitiveData" at the default level of 6.

I changed it to 15.

Several reboots later I updated this on the Sab256-nvme drive and booted back to the Kingston120 (USB3-SSD) I will say that running mountEFI many times I don't always(usually?) see the little star next to the purported EFI booted drive.

It seems however this ExposeSensitiveData makes that nvram variable visible.

What would mountefi have tried to do to guess the EFI drive absent this as I don't think it was exposed before?

Thanks

nvram-updated-ExposeSensitiveData.txt

rocketmanblamb@BriansicKing120 ~ % nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.GPT,([^,]),.*/\1/' F9EF4E49-3C91-469D-A833-32F6703168CE

rocketmanblamb@BriansicKing120 ~ % diskutil list $(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.GPT,([^,]),.*/\1/') /dev/disk0 (internal, physical):

: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *256.1 GB disk0 1: EFI ⁨EFI⁩ 209.7 MB disk0s1 2: Apple_APFS ⁨Container disk2⁩ 255.9 GB disk0s2

rocketmanblamb@BriansicKing120 ~ % diskutil info $(nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:boot-path | sed 's/.GPT,([^,]),.*/\1/') Device Identifier: disk0s1 Device Node: /dev/disk0s1 Whole: No Part of Whole: disk0

Volume Name: EFI Mounted: Yes Mount Point: /Volumes/EFI

Partition Type: EFI File System Personality: MS-DOS FAT32 Type (Bundle): msdos Name (User Visible): MS-DOS (FAT32)

OS Can Be Installed: No Media Type: Generic Protocol: PCI-Express SMART Status: Verified Volume UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B Disk / Partition UUID: F9EF4E49-3C91-469D-A833-32F6703168CE Partition Offset: 20480 Bytes (40 512-Byte-Device-Blocks)

Disk Size: 209.7 MB (209715200 Bytes) (exactly 409600 512-Byte-Units) Device Block Size: 512 Bytes

Volume Total Space: 206.5 MB (206472192 Bytes) (exactly 403266 512-Byte-Units) Volume Used Space: 69.2 MB (69205504 Bytes) (exactly 135167 512-Byte-Units) (33.5%) Volume Free Space: 137.3 MB (137266688 Bytes) (exactly 268099 512-Byte-Units) (66.5%) Allocation Block Size: 512 Bytes

Media OS Use Only: No Media Read-Only: No Volume Read-Only: No

Device Location: Internal Removable Media: Fixed

Solid State: Yes Hardware AES Support: No

[brianlamb]

it seems to find it successfully given that NVRAM variable - this is helpful as I will remember to enable that feature - I often have 4 or more versions of EFIs on different disks as I try to debug issues and then forget which disk I last booted from.

Thanks for your attention.

[corpnewt]

Yep - looks like it was just an issue of missing NVRAM data. I'm guessing something, somewhere wrote a UUID to that var which was leftover after another boot, and as such - MountEFI got the wrong target. I'm glad that it was an easy fix - but as this seems to be more of an issue with the ExposeSensitiveData configuration than with MountEFI itself, I'll close the issue. If other information comes to light that MountEFI may be the culprit, I'll reopen it though.

-CorpNewt