- 31 May, 2021 2 commits
-
-
Santosh Mahto authored
backend: kvm: Add virtio_pci_modern_dev kernel module See merge request !2
-
Santosh Mahto authored
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
-
- 19 Mar, 2021 1 commit
-
-
Gaël PORTAY authored
-
- 27 Nov, 2020 13 commits
-
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
Implement the UML backend to allow machines to be created using this new backend. Signed-off-by:
Christopher Obbard <chris.obbard@collabora.com>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
The backend should choose which kernel modules are copied to the initrd. Signed-off-by:
Christopher Obbard <chris.obbard@collabora.com>
-
Christopher Obbard authored
The kernel path should be chosen under the backend. Signed-off-by:
Christopher Obbard <chris.obbard@collabora.com>
-
Christopher Obbard authored
Move all backend-related functionality from Machine startup function into the backend implementation. Signed-off-by:
Christopher Obbard <chris.obbard@collabora.com>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
- 14 Aug, 2020 8 commits
-
-
Corentin Noël authored
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>
-
- 05 Aug, 2020 3 commits
-
-
Arnaud Rebillout authored
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>
-
Arnaud Rebillout authored
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>
-
Arnaud Rebillout authored
This is Debian-specific, it doesn't exist in other distributions. Signed-off-by:
Arnaud Rebillout <arnaud.rebillout@collabora.com>
-
- 28 May, 2020 2 commits
-
-
Christopher Obbard authored
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>
-
Christopher Obbard authored
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>
-
- 27 May, 2020 4 commits
-
-
Andrej Shadura authored
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>
-
Arnaud Rebillout authored
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>
-
Arnaud Rebillout authored
(this is to prepare upcoming commits) Signed-off-by:
Arnaud Rebillout <arnaud.rebillout@collabora.com>
-
Arnaud Rebillout authored
Also rename usrpath to moddir ie. "modules directory". Signed-off-by:
Arnaud Rebillout <arnaud.rebillout@collabora.com>
-
- 05 Dec, 2019 3 commits
-
-
Branen Salmon authored
-
Tobias Klauser authored
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>
-
Tobias Klauser authored
Run gofmt on machine.go to keep it formatted properly. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch>
-
- 05 Mar, 2019 1 commit
-
-
Sjoerd Simons authored
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>
-
- 06 Feb, 2019 2 commits
-
-
Arnaud Rebillout authored
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>
-
Denis Pynkin authored
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>
-
- 05 Nov, 2018 1 commit
-
-
Sjoerd Simons authored
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>
-