Skip to content

Improve collection of os-release(5) info

Simon McVittie requested to merge wip/smcv/os-info into main

/cc @denittis

  • !611 (merged)

  • !612 (merged)

  • os: Parse os-release into a hash table, then from there into SrtOsRelease

    This will make it easier to convert SrtOsRelease into an object that can store arbitrary fields.

  • os: Factor out a function to populate SrtOsRelease from a data blob

    This will make it easier to unit-test.

  • tests: Unit-test SrtOsRelease

  • os: Apply Steam Runtime special cases earlier

    In future we'll want to track the complete set of fields, not just the ones we have high-level accessors for.

  • os: Collect diagnostic messages about discovery/parsing of os-release

    We will want this in order to be able to report whether we have found the "right" os-release when running under FEX-Emu.

    steamrt/tasks#342

  • tests: Assert that parsing SrtOsRelease has the diagnostic messages it should

  • os: Convert SrtOsRelease into a public object SrtOsInfo

    Unlike SrtOsRelease and its accessors in SrtSystemInfo, this keeps track of everything we might want to add to the JSON report: all os-release(5) fields (not just the important ones), the source path from which we got the information, and any diagnostic messages we logged while collecting it.

    Because this is a separate object, it'll be more suitable for representing the various contexts that might have an os-release(5).

    When using FEX-Emu and pressure-vessel, we can have up to four os-release(5) files: the one that is read by native ARM code, the one in the interpreter root pseudo-overlayfs that is read by x86 code, the one that would be read by native ARM code outside the pressure-vessel container, and the one that would be read by x86 code outside the pressure-vessel container. Representing these as four objects with the same API will result in much less duplication.

  • tests: Expand assertions about OS info

  • system-info: Use SrtOsInfo to serialize os-release(5)

    In a subsequent commit this will let us serialize additional fields.

  • system-info: Save/load additional fields from os-release(5) if --verbose

    In the load/save round-trip test, this requires re-saving the file with --verbose, otherwise these fields will be lost.

  • system-info: Save and load a SrtOsInfo for the container host OS

    Previously, s-r-system-info would inspect the live system looking for host OS information, even if it was meant to be parsing a JSON report and not looking at any live data.

    This needs to be fixed before we can add diagnostic messages to the OS info part of the JSON report, otherwise diagnostic messages from failing to find information about the host OS would become part of the loaded and re-serialized report, causing the round-trip test to fail.

  • system-info: Save and load source path and messages for SrtOsInfo

  • virtualization: Add host OS to virtualization info

    Now that we correctly read the emulated /etc/os-release in a FEX-Emu environment, we should also report the real OS somewhere.

  • os: Record the resolved (physical) source path in SrtOsInfo

Merge request reports