Fake ubuntu drivers

[Chris-Peterson444]

This wraps the ubuntu-drivers calls with the fake-devices-wrapper script from ubuntu-drivers-common. In the future it would probably be nice to copy/transplant some of the code we have in scripts/umockdev-wrapper.py to facilitate this instead of calling fake-devices-wrapper, but I think this keeps it pretty simple for now. (We could probably provide the config via autoinstall somehow but getting it to the target would be slightly more difficult I think?).

Two related questionable things here:

1. Currently, only install models are able to specify packages to be installed into the live system. I've changed this to allow post install models to specify these as well. I suppose post install models aren't really given a chance to be configured and change this before packages are set to be installed, but in the ubuntu-drivers case we need to have gir1.2-umockdev-1.0 and umockdev installed before the list drivers command is called and we know early on if it's needed or not.

2. I moved installation of live packages up a step. Particularly we were waiting to do the steps to configure apt before installing live packages, but I don't see any reason live packages have to wait for apt configuration (I'm assuming on the target system). The problem I was running into is that ubuntu drivers waits on apt to be configured and then calls the ubuntu-drivers list command as soon as it's ready. This makes sense normally (ubuntu-drivers list is normally called in the target system) but when doing MOK enrollment testing we need the packages in the live environment before this.

If these changes are more dangerous than I suspect, we could remove all of the live_packages logic and get away with using autoinstall and specifying that these packages are installed in early commands. Although I think remembering a few debug flags is better than having to keep around an autoinstall file, it might be good motivation to start a "how-to-test X" doc somewhere to keep this type of information which would be good. Opinions please.

If you want to test out these changes: Build the snap as normal, but when injecting it into an ISO, make sure to add umockdev and gir1.2-umockdev-1.0 to the pool on the ISO as well:

  sudo python3 -m livefs_edit <bash-iso-path> <new-iso-dest> --inject-snap <snap-path> --add-packages-to-pool umockdev gir1.2-umockdev-1.0

Then you can launch the VM with:

./scripts/kvm-test.py --install -o --iso <iso-path> --secure-boot --fake-pci-devices --server-force-no-gpgpu

The quickest way to check if drivers were installed on the secure boot system is check for MOK.der in /target/var/lib/shim-signed/mok/ (created by dmks on install)

If you want to do it with autoinstall you can do that too. Just use

drivers:
  install: true

[Chris-Peterson444]

Draft because I'm still uncertain about the live packages behavior. I just did some tests before opening the PR and I found when doing autoinstall and installing live packages I get an extraneous Continue with autoinstall continues (yes|no) prompt during the package installation, even though the installation is still continuing without interaction.

start:  subiquity/Install/install/live-packages: installing packages to live system
Confirmation is required to continue.
Add 'autoinstall' to your kernel command line to avoid this



Continue with autoinstall? (yes|no)
start: subiquity/Meta/status_GET:
start: subiquity/Meta/status_GET:
start: subiquity/Meta/status_GET:
start: subiquity/Meta/status_GET:
finish:  subiquity/Install/install/live-packages: installing packages to live system
start:  subiquity/Install/install/configure_apt: configuring apt

Feels like a bug with the client code, but my changes probably don't help. Needs some investigation if keeping it around sounds like a good idea.