https://github.com/ahgencer/podmod
Containerized build system for kernel modules on Fedora.
https://github.com/ahgencer/podmod
fedora kernel-module linux podman silverblue
Last synced: 4 days ago
JSON representation
Containerized build system for kernel modules on Fedora.
- Host: GitHub
- URL: https://github.com/ahgencer/podmod
- Owner: ahgencer
- License: gpl-2.0
- Created: 2022-10-01T09:57:37.000Z (over 3 years ago)
- Default Branch: v1.x
- Last Pushed: 2022-11-20T19:07:16.000Z (about 3 years ago)
- Last Synced: 2025-02-12T07:00:32.335Z (12 months ago)
- Topics: fedora, kernel-module, linux, podman, silverblue
- Language: Rust
- Homepage:
- Size: 123 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
- License: COPYING
Awesome Lists containing this project
README
Podmod
*podmod provides a containerized method for building kernel modules on Fedora, mainly targeting immutable operating
systems such as Silverblue / Kinoite and CoreOS.*
*podmod* builds kernel modules from source inside a [Podman](https://podman.io/) container and allows you to load it
without modifying any part of the filesystem on the host. It provides a [Rust](https://rust-lang.org/) frontend that can
sources the build steps of a module from a Containerfile, and then load and unload the module. The process is:
- You call `podmod build` with the name of the kernel module.
- *podmod* reads the configuration file (default: `/etc/podmod.conf`) for build and kernel arguments.
- *podmod* searches `share/modules/` for the module and builds it as part of a new container image.
- You can then load or unload the module with `podmod load` or `podmod unload`. *podmod* will
call [insmod(8)](https://manpages.org/insmod/8) or [rmmod(8)](https://manpages.org/rmmod/8) from **inside** the
container to load or unload the module on the host.
Interested? [Here's how to get started.](#getting-started)
## FAQ
### Isn't this super hacky?
**Not really.** Containers aren't virtual machines, where the guest operating system has its own kernel, gets assigned
its own memory space to manage, and may be completely unaware that it's being virtualized. Instead, container engines
such as Podman or [Docker](https://docker.com/) use [Linux namespaces](https://en.wikipedia.org/wiki/Linux_namespaces)
to make a sort of [chroot(1)](https://manpages.org/chroot) with an isolated process and network space. Otherwise, its no
different from running the same command directly on the host. The kernel module is built the same way, and the kernel is
the same inside and outside the container.
Building kernel modules this way is not a brand-new concept,
either. [jdoss/atomic-wireguard](https://github.com/jdoss/atomic-wireguard) takes the same approach. There's even
an [article](https://projectatomic.io/blog/2018/06/building-kernel-modules-with-podman/) on building kernel modules with
Podman on the [Project Atomic](https://projectatomic.io/) website (which is now deprecated in favor of CoreOS). However,
the usual restrictions for kernel modules still apply. Mainly, the module needs to be built for a **specific** kernel
version, and must be rebuilt with every update.
### Will this work on other editions of Fedora?
This has only been tested on Silverblue / Kinoite (36 to 37), but **will theoretically work** on other editions as well,
including Workstation, Server, and CoreOS. Think of it as an alternative to [dkms(8)](https://manpages.org/dkms/8), for
cases where the module in question is either not packages for Fedora yet, or when the root filesystem is not writable.
### Wil this work on distributions other than Fedora?
**No.** The modules are built against Fedora's kernel packages from [Koji](https://koji.fedoraproject.org/koji/) and are
incompatible with other distributions. This restriction also excludes distributions that are downstream from Fedora,
such as [CentOS](https://centos.org/) and [RHEL](https://redhat.com/en/technologies/linux-platforms/enterprise-linux).
You are, of course, welcome to adapt *podmod* to use different Containerfiles targeting other distributions. If you do,
please consider [upstreaming your changes](#contributing) so that everyone can benefit from them!
## Getting started
### Installation
Installation instructions, as well as instructions for building *podmod* from source, can be
found [here](docs/INSTALL.md).
The latest additions to *podmod* are outlined in the changelog found [here](docs/CHANGELOG.md).
### Basic Usage
To get help on using *podmod*, run:
# podmod --help
You may also refer to the manpage [podmod(8)](docs/podmod.8).
To build a kernel module, run:
$ podmod build -m
Afterwards, you can load it with:
$ podmod load -m
*podmod* also ships with a [systemd](https://systemd.io/) service file to load and unload a module at boot time:
$ systemctl enable podmod@.service
> **Note:** The module must have already been built manually on the system using `podmod build`. Otherwise, the unit
> will fail.
## Contributing
Found a bug or a missing feature? You can report it at the [issue tracker](https://github.com/ahgencer/podmod/issues).
Please keep in mind that *podmod* is still in the early alpha stages, and large changes are often made without warning.
It is not meant for public use yet. The source code is made available mostly only as a preview.
## License
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation, either version 2 of the License, or (at your option) any later
version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not,
see .