Include UEFI info in the submission.json

Bug #1854862 reported by Sheila Miguez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Checkbox Provider - Base
Fix Released
High
Sylvain Pineau

Bug Description

On certification.ubuntu.com we display "(Legacy)" or "(UEFI)" next to the bios. Currently we are showing "(Legacy)" for everything (lp:1853191) due to some missing information in the submission.json. For now I'm going to suppress display of that until we work out what to have in the submission.json.

Here is background for what the xml reports had:

Back when we used xml reports, checkbox_support had a parser that turned the xml into json for us, and we'd extract bios information from the "set-devices" element. C3 would check for the existence of devices with "EFI" or "BIOS" as a category.

I am not recommending we go back to those days. What I would prefer is an element that is just for bios information that includes whether it is UEFI or Legacy. We already do get an element with bios information in raw-devices-dmi. Maybe the UEFI bit could go there. Or, instead of flags we could perhaps add the characteristics from teh dmi data as a list.

Anyway, for reference, this an example of the part of the device set that the old checkbox_support generated from the old xml submission:
[
  {
    "category": "BIOS",
    "subproduct_id": null,
    "product": "F.40",
    "vendor": "Insyde",
    "product_id": null,
    "bus": "dmi",
    "path": "/devices/virtual/dmi/id/bios",
    "vendor_id": null,
    "driver": null,
    "subvendor_id": null
  },
  {
    "category": "EFI",
    "subproduct_id": null,
    "product": "/var/log/kern.log:EFI v2.40",
    "vendor": "INSYDE Corp.",
    "product_id": null,
    "bus": "dmi",
    "path": "/sys/class/dmi/id/bios_version",
    "vendor_id": null,
    "driver": null,
    "subvendor_id": null
  },
  {
    "category": "EFI",
    "subproduct_id": null,
    "product": "/var/log/kern.log.1:EFI v2.40",
    "vendor": "INSYDE Corp.",
    "product_id": null,
    "bus": "dmi",
    "path": "/sys/class/dmi/id/bios_version",
    "vendor_id": null,
    "driver": null,
    "subvendor_id": null
  }
]

I do not know how the entries in the xml got populated.

Related branches

Changed in checkbox-support:
importance: Undecided → Medium
Changed in checkbox-support:
status: New → In Progress
assignee: nobody → Maciej Kisielewski (kissiel)
importance: Medium → High
Revision history for this message
Sheila Miguez (codersquid) wrote :

Since we get bios info in raw-devices-dmi (no where else, right?) could

Could the device dict about bios have an element with the UEFI bit?

Or, instead of a flag we could perhaps add the characteristics from the dmi data as a list - on the c3 side we'd check the list to see if UEFI is a member.

We still don't capture whether something is UEFI right now.

Changed in checkbox-support:
status: In Progress → New
assignee: Maciej Kisielewski (kissiel) → nobody
Revision history for this message
Sheila Miguez (codersquid) wrote :

Could we get this fixed? For months now we haven't been able to collect information on bios type. It means we can't show the user anything about whether the system was certified with Legacy vs. UEFI. I can try to see how to do this, but I honestly have no clue. I can start by looking at how raw-devices-dmi is populated and work from there.

Changed in checkbox-support:
assignee: nobody → Sylvain Pineau (sylvain-pineau)
Revision history for this message
Sheila Miguez (codersquid) wrote :

I can see that non-keywords get skipped in the dmidecode output, which means that the "UEFI is supported" string isn't doable for adding the the raw dmi output json.

Handle 0x000B, DMI type 0, 24 bytes
BIOS Information
        Vendor: LENOVO
        Version: R0SET39W (1.23 )
        Release Date: 12/07/2018
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 16 MB
        Characteristics:
                PCI is supported
                PNP is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                3.5"/720 kB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 1.23
        Firmware Revision: 1.23

In parsers/dmidecode.py line 38 the KEY_VALUE_RE is defined and over at line 124 it is skipped. I don't know if it's at all reasonable to have a step where the entire output is checked for "UEFI" in the output. That seems pretty janky to me.

I don't know how things worked in the xml days. It must have been looking at a different file.

Revision history for this message
Sheila Miguez (codersquid) wrote :

Here Jeff talks about a different command and suggests that system_info_json has info on it. I don't know offhand if that's in submission.json. If it is then I could check that, I guess. But, I'd prefer to have a flag with the bios dict in raw devices dmi if that's possible.

Revision history for this message
Sylvain Pineau (sylvain-pineau) wrote :

Here's a sample json report including the new boot_mode preperty in the BIOS dict of raw-devices-dmi.

affects: checkbox-support → plainbox-provider-checkbox
Changed in plainbox-provider-checkbox:
milestone: none → 0.56.0
status: New → In Progress
Revision history for this message
Sheila Miguez (codersquid) wrote :

That looks good to me.

Changed in plainbox-provider-checkbox:
status: In Progress → Fix Committed
Changed in plainbox-provider-checkbox:
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

Bug attachments

Remote bug watches

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