GNOME Boxes / libosinfo improvements

[fidencio]

• Distinguish between intel and nvidia ISOs:

  • libosinfo / osinfo-db reads the first few mega bytes of the media in order to read the ISO's header and, from there, get the following information:
  • Volume ID;
  • Publisher ID;
  • Vendor ID;
  • System ID;
  • Currently (at least on 18.10) both nvidia and intel ISOs have the " Pop_OS 18.10 amd64" Volume ID.
  • Would be really helpful if we could just append a "nvidia" or "intel" to the name;

• Link to the latest ISO for a specific release:

  • This would be really useful as GNOME Boxes could read this information and properly recommend it to users who want to play with the distro;

• Unattended installing / preseed file:

  • libosinfo provides APIs for apps as virt-install & GNOME Boxes to perform unattended installations. In order to do so, we generate the needed file, with the proper kernel command line. As PopOS can be "preseeded", having an example of a working preseed, with its respective kernel command line argument, would be enough for having us (libosinfo) supporting it.

• End of life of each release:

  • What's the release policy? Once a new major release is out, the previous one becomes unsupported / reaches its EOL? Or do you follow the very same policy as Ubuntu? This is something that we'd need to update on osinfo-db in order to only recommend the user releases which are being supported;

• Could we make the addition of new entries automated?

  • This is the something that would be really cool to have as manually adding new entries is quite error prone and may end up with not up-to-date entries as contributors may just forget to do so. Here's one example of a MR (opened by Endless' people) which introduces the first script to automated the process. In case you guys have a similar JSON file, something similar could be done: https://gitlab.com/libosinfo/osinfo-db/merge_requests/27

And, last but not least, here's a link for libosinfo / osinfo-db repos: https://gitlab.com/libosinfo/

[mmstick]

Currently, we have a release API at https://api.pop-os.org/

• Information about the latest ISO for 19.04 NVIDIA ISO: https://api.pop-os.org/builds/19.04/nvidia
• Information about the latest ISO for 18.04 Intel ISO: https://api.pop-os.org/builds/18.04/intel

The JSON response will look like so:

{"version":"19.04","url":"https://pop-iso.sfo2.cdn.digitaloceanspaces.com/19.04/amd64/nvidia/10/pop-os_19.04_amd64_nvidia_10.iso","size":2516582400,"sha_sum":"457223bcfb3f5ad4a64205439064bad3ea019152fba89bc33414b024a4c83541","channel":"nvidia","build":"10"}

It provides the URI for the ISO to fetch it, the checksum of the ISO, and the build number. You can periodically check a link to know when a new release has been made, either a new build for an existing release, or an entirely new release.

The distinst CLI included in the ISO can be used to preseed a user, and there's an example test script. I would also mention that we do prefer UEFI installs when possible, so it would be best to configure it with ovmf.

[fidencio]

Currently, we have a release API at https://api.pop-os.org/

• Information about the latest ISO for 19.04 NVIDIA ISO: https://api.pop-os.org/builds/19.04/nvidia
• Information about the latest ISO for 18.04 Intel ISO: https://api.pop-os.org/builds/18.04/intel

The JSON response will look like so:

{"version":"19.04","url":"https://pop-iso.sfo2.cdn.digitaloceanspaces.com/19.04/amd64/nvidia/10/pop-os_19.04_amd64_nvidia_10.iso","size":2516582400,"sha_sum":"457223bcfb3f5ad4a64205439064bad3ea019152fba89bc33414b024a4c83541","channel":"nvidia","build":"10"}

It provides the URI for the ISO to fetch it, the checksum of the ISO, and the build number. You can periodically check a link to know when a new release has been made, either a new build for an existing release, or an entirely new release.

Would be possible to expand the info in order to also have the minimum / recommended resources (RAM, Storage, CPU)?

Another question here is, would be possible for you guys to provide us a script we could use to periodically run and update the distros entries? The main reason I'm asking for that is the time limitation (mixed with the lack of a better knowledge of the distros) on my side to take care of this for each one of the distros we support.

The distinst CLI included in the ISO can be used to preseed a user, and there's an example test script.

Okay, I can take a look at that.

I would also mention that we do prefer UEFI installs when possible, so it would be best to configure it with ovmf.

Although UEFI installs are not supported by GNOME Boxes yet, there's already a MR opened and a discussion ongoing.

[mmstick]

Unsure which project is providing the release API. @jackpot51 or @btkostner may have know.

Which scripting language would you prefer, or would a binary (Rust) be okay?

UEFI support is the main reason we use virt-manager. There are many features that are exclusive with UEFI installs, which also receives much more testing than legacy boot environments. systemd-boot, kernelstub, recovery partition, etc.

[fidencio]

Which scripting language would you prefer, or would a binary (Rust) be okay?

No language preference. Endless OS provided their script in python, but that's not a requirement from our side.

A script (or even a program) would be better than a binary, to be honest ... even if we have to build it on our side and then run it. :-)

UEFI support is the main reason we use virt-manager. There are many features that are exclusive with UEFI installs, which also receives much more testing than legacy boot environments. systemd-boot, kernelstub, recovery partition, etc.

Indeed. https://gitlab.gnome.org/GNOME/gnome-boxes/merge_requests/199 is the MR adding UEFI support for Boxes. We still need to decide how we present that to the users (if we do) and so on.

So, it's something that's going to be fixed sooner than later as, by now, we finally have all the needed pieces in different projects just waiting for review.

[mmstick]

We have Rust crates for all of our stuff, and we're better at that than Python, so that would be preferred. Building should be as simple as cargo build --release, which dumps a release binary in target/release/.

[jackpot51]

I would like to write the script to keep Pop entries up to date. Where can I see the Endless OS one?

[fidencio]

I would like to write the script to keep Pop entries up to date. Where can I see the Endless OS one?

Their script is not merged yet (sorry about that, GUADEC and a few other things consuming a lot of time), but you can take a look here: https://gitlab.com/libosinfo/osinfo-db/merge_requests/27

More specifically: https://gitlab.com/libosinfo/osinfo-db/merge_requests/27/diffs?commit_id=ad4a39621fe473244e8b204e7da75c26f05eb0e3#63401585bc18753138a6ac2e8f1f2d4b2182d324

I'll have some time to have it merged by the end of this week, beginning of the next week at latest.

[jackpot51]

Thanks! I will make a similar MR

[fidencio]

People,

Would be possible to get a review on https://gitlab.com/libosinfo/osinfo-db/merge_requests/57 ?