Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Darwin Hardware: Imparity between Intel and ARM/M1 (Apple Silicon) Apple devices #1734

Open
ChefAustin opened this issue Feb 17, 2022 · 3 comments
Labels
Status: Untriaged An issue that has yet to be triaged. Type: Bug Does not work as expected.

Comments

@ChefAustin
Copy link

ChefAustin commented Feb 17, 2022

Describe the problem

There seems to be some bug(s) in ohai/lib/ohai/plugins/darwin/hardware.rb which result in Ohai data/keys being incongruous between Intel and M1-chipped Apple devices.

The following Ohai data is pulled from two separate machines running:

  • macOS 12.2.1 (21D62)
  • Chef Infra client v17.9.46 (the only difference being the M1 device is using the aarch64 package while the Intel device is using the x86_64

Ohai Version

$ /opt/chef/bin/ohai --version
Ohai: 17.9.0

Platform Version

 $  sw_vers
ProductName:	macOS
ProductVersion:	12.2.1
BuildVersion:	21D62

Ohai Output

I have made inline comments denoting the deviations between the two output hashes (UUID's have been purposefully altered):
M1:

  "hardware": {
    "activation_lock_status": "activation_lock_disabled",
    "boot_rom_version": "7429.81.3",
    "chip_type": "Apple M1 Max",                             # Note the difference
    "machine_model": "MacBookPro18,2",
    "machine_name": "MacBook Pro",
    "number_processors": "proc 10:8:2",                      # Note the difference
    "os_loader_version": "7429.81.3",
    "physical_memory": "64 GB",
    "platform_UUID": "K666K666-6K66-K6K6-K6K6-K666K666K666",
    "provisioning_UDID": "K666K666-K666K666K666K666K",
    "serial_number": "K666K666K6",
    "operating_system": "macOS",
    "operating_system_version": "12.2.1",
    "build_version": "21D62",
    "architecture": "arm64",
    "storage": [
      {
        "name": "Data",
        "bsd_name": "disk3s5",
        "capacity": 994662584320
      },
      {
        "name": "Macintosh HD",
        "bsd_name": "disk3s1s1",
        "capacity": 994662584320
      }
    ]
  },

Intel:

  "hardware": {
    "activation_lock_status": "activation_lock_disabled",
    "boot_rom_version": "1715.81.2.0.0 (iBridge: 19.16.10744.0.0,0)",
    "cpu_type": "8-Core Intel Core i9",                              # Note the difference
    "current_processor_speed": "2,4 GHz",                            # Note the difference
    "l2_cache_core": "256 KB",                                       # Note the difference
    "l3_cache": "16 MB",                                             # Note the difference
    "machine_model": "MacBookPro16,1",
    "machine_name": "MacBook Pro",
    "number_processors": 8,
    "os_loader_version": "540.80.2~11",
    "packages": 1,                                                   # Note the difference
    "physical_memory": "64 GB",
    "platform_UUID": "C333C333-C333-C333-C333-C333C333C333",
    "platform_cpu_htt": "htt_enabled",                               # Note the difference
    "provisioning_UDID": "C333C333-C333-C333-C333-C333C333C333",
    "serial_number": "C333C333C333",
    "operating_system": "macOS",
    "operating_system_version": "12.2.1",
    "build_version": "21D62",
    "architecture": "x86_64",
    "storage": [
      {
        "name": "Macintosh HD - Data",
        "bsd_name": "disk1s2",
        "capacity": 4001907707904
      },
      {
        "name": "Macintosh HD",
        "bsd_name": "disk1s1s1",
        "capacity": 4001907707904
      },
    ],
    "battery": {                                                     # Note the difference
      "current_capacity": null,                                      # Note the difference
      "max_capacity": 7498,                                          # Note the difference
      "fully_charged": false,                                        # Note the difference
      "is_charging": false,                                          # Note the difference
      "charge_cycle_count": 222,                                     # Note the difference
      "health": "Good",                                              # Note the difference
      "serial": null,                                                # Note the difference
      "remaining": 0                                                 # Note the difference
    }                                                                # Note the difference
  },

Possible Solution

Still working my way through the code to see if I can conjure up a solution proposal but the first thing I noticed was that XML output from system_profiler SPPowerDataType -xml shows that the sppower_battery_charge_info dictionary's keys vary depending on architecture; for example:
M1:

<key>sppower_battery_charge_info</key>
<dict>
	<key>sppower_battery_at_critical_level</key>
	<string>FALSE</string>
	<key>sppower_battery_fully_charged</key>
	<string>TRUE</string>
	<key>sppower_battery_is_charging</key>
	<string>FALSE</string>
	<key>sppower_battery_state_of_charge</key>
	<integer>100</integer>
</dict>

Intel:

<key>sppower_battery_charge_info</key>
<dict>
	<key>sppower_battery_fully_charged</key>
	<string>TRUE</string>
	<key>sppower_battery_is_charging</key>
	<string>FALSE</string>
	<key>sppower_battery_max_capacity</key>
	<integer>7548</integer>
	<key>sppower_battery_state_of_charge</key>
	<integer>100</integer>
</dict>

You'll see that the Intel devices have a sppower_battery_max_capacity kv-pair while M1 devices have a sppower_battery_at_critical_level kv-pair.

@ChefAustin
Copy link
Author

Should this get prioritized, it might also be an opportune time to dig into #1602 and #1603

@ChefAustin
Copy link
Author

FWIW: I've filed Feedback with Apple (FB9921451) about some of the key name discrepancies that exist between the different machine architectures.

@ChefAustin
Copy link
Author

Apple responded to my Feedback submission and suffice it to say that they have no intention (or, in their words, "no obligation") to align output of system_profiler data on M1 and Intel devices. That being said, the general approach to gathering the hardware plugin's data on Darwin devices might need to be reevaluated.

One possible approach could be: Rather than seeking specific key-values from system_profiler's output, one could just target high-level system_profiler data types (like SPHardwareDataType) then have Ohai enumerate all (or almost all; I don't think any Ohai users care about the _name key) underlying keys and coerce them into the Hardware Mash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Untriaged An issue that has yet to be triaged. Type: Bug Does not work as expected.
Projects
None yet
Development

No branches or pull requests

1 participant