GitLab

backend: kvm: Add virtio_pci_modern_dev kernel module

See merge request !2

Without this kernel module, kvm backend fails to load virtio_pci module
as it looks like virtio_pci has dependency on it.
This is snapshot of error which is fixed by this patch:

  # modprobe: module 'virtio_pci_modern_dev' not found
  # [    1.027439] Module has invalid ELF structures
  # modprobe: 'kernel/drivers/virtio/virtio_pci.ko.xz': unknown symbol in module or invalid parameter

Currently the auto backend defaults to kvm, and if kvm is unsupported
then the auto backend is unsupported. With this patch the auto backend
chooses kvm first if supported, falling back to uml if kvm is
unsupported.

If neither backend is supported, a combined error message is shown to
the user.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Implement the UML backend to allow machines to be created using this new
backend.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

The initscript requires the modules and extra mountpoints from the
backend, the cleanest way to do this is to treat the initscript like a
template and pull things in that way.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Each backend mounts the host volumes differently, so the filesystem
type and mount options can be different depending on which backend has
been chosen.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Each backend should have its own udev rules, most likely for creating
the image symlinks under /dev. Allow the backend to create its own rules
and by default create image symlink rules for the kvm backend.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Each backend will have a different tty for the job output to be
redirected to; allow the backend to choose that information.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Different backends may bringup different network interfaces; allow the
backend to inject its own match string into the networkd configuration.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

The backend should choose which kernel modules are copied to the initrd.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

The kernel path should be chosen under the backend.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Move all backend-related functionality from Machine startup function
into the backend implementation.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

The initrdpath is built up per instance of a machine; so it can be
stored in the machine object.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

The Machine object allows the backend name to be set using the
NewMachineWithBackend method. The backend is used when starting the
machine and allows the implementation detail of the particular
virtualisation technology to be hidden from the user.

Also for the fakemachine binary accept a cmdline parameter --backend
which allows the user to set a specific backend when calling
fakemachine manually.

By default the backend name is set to "auto" which should choose the best
supported virtualisation technology on this machine, making sure we log
the backend used. No breaking API changes are introduced.
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

The fakemachine CreateImage and CreateImageWithLabel functions expose an
external image to the internal machine. These functions return a
speculative path which the fakemachine must expose the images to once it
starts.

Currently images exposed to the fakemachine are exposed to a speculative
path which takes into account the virtualisation technology, which may
not be decided at the stage these functions are called. This patch allows
the functions to return a generic path which is implemented once the
machine starts running, allowing the virtualisation technology to be
decoupled.

The images and their partitions are exposed by their label under
/dev/disk/by-fakemachine-label/
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Fixes warnings like:

```
9p: Multiple devices detected in same VirtFS export, which might lead to file
ID collisions and severe misbehaviours on guest!
You should either use a separate export for each device shared from host or
use virtfs option 'multidevs=remap'!
```

Requires QEMU >= 4.2.0

Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

Implementation roughly copy-pasted from debos.

https://github.com/go-debos/fakemachine/issues/40

Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

This directory is not necessarly present.

In recent kernels, ArchLinux no longer compiles some of the virtio
drivers as modules; they are compiled built-in in the kernel image
instead. This seems to be also true for Ubuntu.

This commit adds support for the `modules.builtin` file. We now read
this file, and skip the builtin modules.

Note that we can't assume that the file `modules.builtin` exist. On
Debian, modules.builtin doesn't exist at least on the 4.19 kernels it
does however exist on the 5.3 packaging
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

Up to now, the assumption was that, given a kernel release `KREL`, the
kernel was installed under `/boot/vmlinuz-$KREL`.

While this is true at least on Debian and Ubuntu, this doesn't work for
distributions like ArchLinux or Manjaro. For those distributions, there
is no obvious way to match module directories and kernel filenames.

In order to support these distributions, we need to do more than that.

The solution chosen here is simply to look into the kernel binaries for
the kernel release as a static string, followed by a space. It works on
all the distos tested so far:

  # Debian
  $ strings /boot/vmlinuz-4.19.0-6-amd64 | grep '4.19.0-6-amd64 '
  4.19.0-6-amd64 (debian-kernel@lists.debian.org) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
  4.19.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

  # Ubuntu
  $ strings /boot/vmlinuz-4.15.0-72-generic | grep '4.15.0-72-generic '
  4.15.0-72-generic (buildd@lcy01-amd64-026) #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019
  4.15.0-72-generic (buildd@lcy01-amd64-026) (gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)) #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019

  # ArchLinux
  $ strings /boot/vmlinuz-linux | grep '5.4.2-arch1-1 '
  5.4.2-arch1-1 (linux@archlinux) #1 SMP PREEMPT Thu, 05 Dec 2019 12:29:40 +0000
  5.4.2-arch1-1 (linux@archlinux) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Thu, 05 Dec 2019 12:29:40 +0000

  # Manjaro
  $ strings /boot/vmlinuz-4.19-x86_64 | grep '4.19.88-1-MANJARO '
  4.19.88-1-MANJARO (builder@8898125bf991) #1 SMP PREEMPT Thu Dec 5 11:04:44 UTC 2019
  4.19.88-1-MANJARO (builder@8898125bf991) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Thu Dec 5 11:04:44 UTC 2019

For reference, here's how Arch and Manjaro look like:

ArchLinux:

  # ls -1 /lib/modules
  4.19.88-1-lts
  5.3.15.a-1-hardened
  5.4.2-arch1-1
  5.4.2-zen1-1-zen

  # ls -1 /boot/vmlinuz-*
  /boot/vmlinuz-linux
  /boot/vmlinuz-linux-hardened
  /boot/vmlinuz-linux-lts
  /boot/vmlinuz-linux-zen

Manjaro:

  # ls -1 /lib/modules
  3.16.78-1-MANJARO
  4.19.72-rt26-MANJARO
  4.19.88-1-MANJARO
  5.2.21-rt14-MANJARO
  5.3.15-1-MANJARO
  5.4.2-1-MANJARO
  extramodules-3.16-MANJARO
  extramodules-4.19-MANJARO
  extramodules-4.19-rt-MANJARO
  extramodules-5.2-rt-MANJARO
  extramodules-5.3-MANJARO
  extramodules-5.4-MANJARO

  # ls -1 /boot/vmlinuz-*
  /boot/vmlinuz-3.16-x86_64
  /boot/vmlinuz-4.19-rt-x86_64
  /boot/vmlinuz-4.19-x86_64
  /boot/vmlinuz-5.2-rt-x86_64
  /boot/vmlinuz-5.3-x86_64
  /boot/vmlinuz-5.4-x86_64
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

We used to look for these libraries in (usr)/lib/x86_64-linux-gnu/, but
this is location is Debian-specific, other distros use different paths.

For example, ArchLinux puts everything in /usr/lib, while Fedora uses
/lib64 apparently.

With this commit, we assume that the libraries are installed in the same
directory as the linker (which itself is installed at a well known-path
per architecture as defined by [1]). This is true for ArchLinux, Fedora,
Debian, Ubuntu, so it seems to be a savfe assumption.

[1]: https://sourceware.org/glibc/wiki/ABIList

Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

Currently, the kernel release is determined by taking the last entry in
/usr/lib/modules. This doesn't work for distributions like ArchLinux,
which has additional entries in /usr/lib/modules:

    $ ls -1 /usr/lib/modules
    5.2.4-arch1-1-ARCH
    extramodules-ARCH

This commit fixes it. We keep the same logic (ie. pick up the last
kernel found in /usr/lib/modules), however we add an additional
constraint: filter out things that don't start with a digit (because
yes, we strongly expect that the kernel release starts with a digit).

(this neat trick was taken from the mkosi source code)
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

For now we only mount /etc/ssl into the fakemachine, however for
distributions like ArchLinux this is not enough, as various entries
under /etc/ssl/ are actually symlinks to /etc/ca-certificates/...:

    $ ls -l /etc/ssl/cert.pem
    lrwxrwxrwx 1 root root 46 Nov  9  2018 /etc/ssl/cert.pem -> ../ca-certificates/extracted/tls-ca-bundle.pem
    $ ls -l /etc/ssl/certs/ca-certificates.crt
    lrwxrwxrwx 1 root root 49 Nov  9  2018 /etc/ssl/certs/ca-certificates.crt -> ../../ca-certificates/extracted/tls-ca-bundle.pem

This commit adds /etc/ca-certificates to the list of directories that
are bind-mounted into the fakemachine.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

This is Debian-specific, it doesn't exist in other distributions.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

busybox is normally located under /bin but in fedora at least, it is located
under /sbin. So search both $PATH for the executable.

Resolves: #48
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Some of the commands used (e.g mkfs.ext4) are normally located under /sbin. It's
not typical for unprivileged users to have /sbin in their $PATH so fakemachine
should add /sbin:/usr/sbin to the $PATH.

Resolves: #21
Signed-off-by: Christopher Obbard <chris.obbard@collabora.com>

Several distributions (including Ubuntu) ship some of the modules we
rely on compiled into the kernel. Since these modules are listed in
modules.builtin, it’s very easy to detect and skip them.

This change fixes #13 and supersedes #36.
Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

This is needed for ArchLinux.

With this commit, if we don't find a `.ko` modules, we re-try with
`.ko.xz`, and if we don't find it, we definitely fail.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

(this is to prepare upcoming commits)
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

Also rename usrpath to moddir ie. "modules directory".
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

unix.Utsname has byte array instead of int8/uint8 array members which
makes it simpler to convert them to strings.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>

Run gofmt on machine.go to keep it formatted properly.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>

busybox in buster depends on libresolve.so.2 so copy it to the
initramfs; Potentially in future fakemachine should move to
busybox-static
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

The OnFailure directive is misplaced, which can be seen by running
`debos --show-boot ...`:

fakemachine systemd[1]: /etc/systemd/system/fakemachine.service:16: Unknown lvalue 'OnFailure' in section 'Service'

This commit brings it back where it belongs, under the unit section.
Signed-off-by: Arnaud Rebillout <arnaud.rebillout@collabora.com>

Set the limit of open files to 4096 for processes inside of Qemu VM.
We have no configuration for limits and kernel's defaults are used.
This leads to different settings on different kernels, hardcoded limit
allow to avoid problems with too strict defaults.
Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>

In systemd syntax an empty rvalue unsets previously set values. Which
meant in case no host environment variables were carried over
`Environment=%[2]s` would cause the previous Environment setting to be
dropped... Which in turn broke the fakemachine.InMachine() detection,
which broke debos when not using proxies...

Simply append the extra environment variables to the existing
Environment= setting to ensure that can happens.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>