Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

watkipet

macrumors member
Original poster
Aug 11, 2018
42
22
I'm attempting to try out Next Loader. However I've run into a problem with the `bless` command (not with Next Loader itself). `bless` can't seem to change or read the efi-boot-device NVRAM variable.

This is on a MacPro4,1 flashed to a 5,1 running macOS 10.13.6 from a SATA SSD formatted as APFS.

So far, I've:
  1. Erased all my nvram variables with `nvram -c`
  2. Rebooted
  3. Read them back out with `nvram -p`:
    Code:
    Hostname:~ user$ sudo nvram -p
    Password:
    EFIBluetoothDelay    %b8%0b
    bluetoothActiveControllerInfo    %15%82%ac%05%00%00%00%00%11Z%00&J%9bE$
    SystemAudioVolumeDB    %00
    SystemAudioVolume    @
    bluetoothInternalControllerInfo    %15%82%ac%05%00%00%11Z%00&J%9bE$

  4. Notice `efi-boot-device`. OK. I haven't set it yet with `bless`. I do that:
    Code:
    Hostname:~ user$ sudo bless --folder "/Volumes/UEFI Boot Manager/loader" --file "/Volumes/UEFI Boot Manager/loader/loader.efi" --label "UEFI Boot Manager"
    Password:
    Hostname:~ user$ sudo bless --verbose --mount "/Volumes/UEFI Boot Manager" --setBoot
    EFI found at IODeviceTree:/efi
    Mount point for /Volumes/UEFI Boot Manager is /Volumes/UEFI Boot Manager
    Mount point is '/Volumes/UEFI Boot Manager'
    No BootX creation requested
    No boot.efi creation requested
    found ioreg "FirmwareFeaturesMask"; featureMaskValue=0xFF1FFF3F
    found ioreg "FirmwareFeatures"; featureFlagsValue=0xC00C5403
    isPreBootEnvironmentUEFIWindowsBootCapable=0
    preboot environment is not UEFI boot capable
    isDVDWithElToritoWithUEFIBootableOS=0
    Checking if disk is complex (if it is associated with booter partitions)
    Other partition scheme detected
    No auxiliary booter partition required
    Preferred system partition found: disk0s1
    Preferred system partition found: disk2s1
    Preferred system partition found: disk3s1
    Returning booter information dictionary:
    <CFBasicHash 0x7fc434e00530 [0x7fff9fe9baf0]>{type = mutable dict, count = 3,
    entries =>
        0 : <CFString 0x101c93be0 [0x7fff9fe9baf0]>{contents = "System Partitions"} = (
        disk0s1,
        disk3s1,
        disk2s1
    )
        1 : <CFString 0x101c943c0 [0x7fff9fe9baf0]>{contents = "Data Partitions"} = (
        disk4s1
    )
        2 : <CFString 0x101c943e0 [0x7fff9fe9baf0]>{contents = "Auxiliary Partitions"} = (
    )
    }
    
    Path to mountpoint given: /Volumes/UEFI Boot Manager
    IOMedia disk4s1 does not have a partition UUID
    DADiskRef disk4s1 has Volume UUID 6CDDF66A-D8C3-3F75-967E-275492CECC8D
    IOMedia disk4s1 has path IODeviceTree:/PCI0@0/EHC1@1D,7/@1:1
    Setting EFI NVRAM:
        efi-boot-device='<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPathMatch</key><string>IODeviceTree:/PCI0@0/EHC1@1D,7/@1:1</string></dict><key>BLVolumeUUID</key><string>6CDDF66A-D8C3-3F75-967E-275492CECC8D</string><key>BLLastBSDName</key><string>disk4s1</string></dict></array>'
    
    Could not set boot device property: 0xe00002bc

    If I read the variables back out, indeed, nothing changed:
    Code:
    Hostname:~ user$ nvram -p
    EFIBluetoothDelay    %b8%0b
    bluetoothActiveControllerInfo    %15%82%ac%05%00%00%00%00%11Z%00&J%9bE$
    SystemAudioVolumeDB    %00
    SystemAudioVolume    @
    bluetoothInternalControllerInfo    %15%82%ac%05%00%00%11Z%00&J%9bE$

    Whoah! It almost looks as if some part of my EFI NVRAM variables can't be accessed. Has anyone else run into this? Anything else I can check?
[doublepost=1536853387][/doublepost]Nevermind. I think I have SIP enabled. Let me disable it and try again.
 
Try using the "bless_volume.sh" script inside the "scripts" folder. It works even with SIP enabled.
 
Try using the "bless_volume.sh" script inside the "scripts" folder. It works even with SIP enabled.

Like this I assume:

Code:
Hostname:scripts user$ pwd
/Volumes/UEFI Boot Manager/scripts
HOstname:scripts user$ sudo ./bless_volume.sh
finderinfo[0]:    206 => Blessed System Folder is /Volumes/UEFI Boot Manager/loader
finderinfo[1]:    290 => Blessed System File is /Volumes/UEFI Boot Manager/loader/loader.efi
finderinfo[2]:      0 => Open-folder linked list empty
finderinfo[3]:      0 => No alternate OS blessed file/folder
finderinfo[4]:      0 => Unused field unset
finderinfo[5]:    206 => OS X blessed folder is /Volumes/UEFI Boot Manager/loader
64-bit VSDB volume id:  0x8485041A56303F9D

I gave that a try. I'm doing this over SSH through the soon-to-be-abandoned BTMM, so I'll give the machine a reboot once I actually get home.
 
Here's what I've learned so far:

  1. Running `bless --folder` instead of `bless --mount --setBoot` doesn't require SIP to be disabled. However, on my machine, `bless --folder` doesn't appear to change the efi-boot-device or efi-boot-device-data NVRAM variables.
  2. If I disable SIP and run the `bless --mount --setBoot` version of the command, I no longer get an error, `Could not set boot device property: 0xe00002bc`.
I also tried using bootoption to list my EFI boot variables:

Using `bless --folder`:

Code:
Hostname:bin user$ ./bootoption LIST
BootCurrent: Boot0080
BootNext: Not set
Timeout: Not set
  1: Boot0080                             
Hostname:bin user$ ./bootoption INFO Boot0080
Name: Boot0080
Description:
Device path: \ACPI_DP\HW_PCI_DP\MSG_SATA_DP\MEDIA_HARDDRIVE_DP\MEDIA_VENDOR_DP\MEDIA_FILEPATH_DP
Partition UUID: 58639E9C-CD23-459B-8FE7-AA4748365F2B
Loader path: \50D246E3-FA16-394D-9AB7-0A61A08AF3BE\System\Library\CoreServices\boot.efi

After using `bless --mount --setBoot`:
Code:
Hostname:bin user$ ./bootoption LIST
BootCurrent: Boot0080
BootNext: Not set
Timeout: Not set
  1: Boot0080 Mac OS X                   
Hostname:bin user$ ./bootoption INFO Boot0080
parseHardDriveDevicePath(): Only GPT is supported at this time
Error parsing hard drive device path (74)

The drive isn't GPT:
Code:
Hostname:~ user$ diskutil list
/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *30.0 GB    disk5
   1:                  Apple_HFS UEFI Boot Manager       30.0 GB    disk5s1

So my takeaway from this is that if I want to modify my default boot loader location in NVRAM I need to disable SIP first. If I want to just bless a loader and EFI find it automatically (assuming it's first in the boot order), I can use the `bless --folder` option which doesn't require disabling SIP.
 
  • Like
Reactions: Petri Krohn
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.