Machine resource discovery does not work for PPC

Bug #2028156 reported by SCORE Lab
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Medium
Anton Troyanov

Bug Description

(started from discourse: https://discourse.maas.io/t/machine-resource-discovery-does-not-work-for-ppc/7284)

Hi Team

Context: the general “machine info” for our PPC nodes is empty, compared to x86_64 machines, where infromation is visible

Yak-shave:

1. The `20-maas-03-machine-resouces` commissioning script comes back empty for the general system info (compared to the `maas-lshw script, which contains useful info)
2. The above script comes from a (go-)binary (see `src/host-info/pkg/info/info.go`).
3. This binary uses the lxd/resources packages
4. The `system.go`-componend in the `lxd/resources`-package in the `canonical/lxd` repo explicitely searches `/sys/class/dmi/id`.

On PowerPC, DMI and such does not exists.
`lshw`, however, can retrieve the necessary information without problem.
It aparently uses the POWER device-tree (located at `/proc/device-tree` or `/sys/firmware/devicetree/base`)
which seems to be a tad more complex than the DMI-interface exposes in sysfs.

Fortunately, the `machine-resources`-info seems to be purely informational, as things like actual devices, storage, network, and dynamic tags seems to rely on the `lshw`-info anyways.

Related branches

Revision history for this message
Bill Wear (billwear) wrote :

thanks for this. could you please use https://maas.io/docs/how-to-review-and-report-bugs to get us a few more pieces of information? not sure how to triage this one atm.

Changed in maas:
status: New → Incomplete
Revision history for this message
SCORE Lab (score) wrote :

Context:

* Maas via Debs:
maas-cli/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]
maas-common/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]
maas-dhcp/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]
maas-dns/jammy 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all
maas-proxy/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]
maas-rack-controller/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]
maas-region-api/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed,automatic]
maas-region-controller/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]
maas/jammy,now 1:3.3.4-13189-g.f88272d1e-0ubuntu1~22.04.1 all [installed]

* CLI/UI/API?
Irrelevant, since the result is from a commission script.

* What happens?
Commissioning or enlisting a POWER machine does not fill the machine info, as exposed in the GUI as "Hardware Information" on the "Summary" page or or the "hardware_info" json part of 'maas $USER machine read $MACHINE' :

  "hardware_info": {
    "system_vendor": "Unknown",
    "system_product": "Unknown",
    "system_family": "Unknown",
    "system_version": "Unknown",
    "system_sku": "Unknown",
    "system_serial": "Unknown",
    "cpu_model": "POWER8 (architected), altivec supported",
    "mainboard_vendor": "Unknown",
    "mainboard_product": "Unknown",
    "mainboard_serial": "Unknown",
    "mainboard_version": "Unknown",
    "mainboard_firmware_vendor": "Unknown",
    "mainboard_firmware_date": "Unknown",
    "mainboard_firmware_version": "Unknown",
    "chassis_vendor": "Unknown",
    "chassis_type": "Unknown",
    "chassis_serial": "Unknown",
    "chassis_version": "Unknown"
  },

* How to reproduce?
Long way: Commission a PowerPC machine and look at the results.
Short way:
Execute "/usr/share/maas/machine-resources/ppc64el" on a PowerPC host.
The JSON output of that contains:

        "system": {
            "uuid": "",
            "vendor": "",
            "product": "",
            "family": "",
            "version": "",
            "sku": "",
            "serial": "",
            "type": "physical",
            "firmware": null,
            "chassis": null,
            "motherboard": null
        }

In fact, the issue seems to be with the underlying `lxd/resources` script used, which relies on DMI, which in turn, does not exist on POWER.
LSHW, however works fine, as it uses the POWER device tree.

I merely reported here as Anton Troyanov asked me to on the Discourse.

I attach logs from a machine this happened to plus maas logs of tha time..

Changed in maas:
status: Incomplete → Triaged
Revision history for this message
Anton Troyanov (troyanov) wrote :

Thank you for the very detailed bug report!

I am currently in touch with LXD team, we will decide if we should make a change to the LXD package or handle this case inside MAAS by taking values from lshw data.

For the reference, Stéphane mentioned that DMI data might be not available on all the arches
https://github.com/canonical/lxd/issues/7189#issuecomment-613749832

Changed in maas:
assignee: nobody → Anton Troyanov (troyanov)
Revision history for this message
Simon Déziel (sdeziel) wrote :

I've reported https://github.com/canonical/lxd/issues/12112 to get the input from the team about a proposed change to use `lshw`'s output rather than parsing `/sys/class/dmi/id` directly.

Revision history for this message
SCORE Lab (score) wrote :

Welcome!

I think the tough part is that PPC devicetree is more structured but also a bit harder to parse.
It is more versatile, tho.

Changed in maas:
importance: Undecided → Medium
Revision history for this message
Jerzy Husakowski (jhusakowski) wrote :

Once the linked LXD issue is fixed, update the LXD library in MAAS.

Changed in maas:
milestone: none → 3.5.0
Changed in maas:
status: Triaged → Fix Committed
Changed in maas:
status: Fix Committed → Triaged
status: Triaged → Fix Committed
Changed in maas:
milestone: 3.5.0 → 3.5.0-beta1
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.