dustymabe reported a new issue against the project: `atomic-wg` that you are following:
``
CoreOS has a project called [ignition](https://github.com/coreos/ignition) that hooks into early boot processes in the initramfs (i.e. before and after the root filesystem is mounted) and allows for configuration of the system. This is an alternative to cloud-init, that is focused on specific tasks. Let's investigate this for Fedora and Atomic Host.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/450
jdoss reported a new issue against the project: `atomic-wg` that you are following:
``
There seems at least one thread [1] on the mailing list that talks about getting kernel modules built on Atomic, but nothing that I could find has been created here to figure out the best path forward on supporting kernel modules.
The use case that I am personally trying to fix is getting WireGuard working on Atomic. I maintain the RHEL/CentOS/Fedora Copr for WireGuard [2] and DKMS works pretty well for providing the WireGuard kernel module on non-atomic based installs. I have had some WireGuard users try and use the Copr RPMs on Atomic Host which resulted in failure. One of them was manually copying the .ko file over to get things working [3] and this isn't a really good solution long term. I now find myself in the same situation where I would like to use Wireguard on Atomic, so I am trying to figure out how to come up with a short term solution to this issue as the WireGuard devs work on getting WG pushed upstream into the mainline kernel. Even if that does happen somewhat soon, this problem will still impact others that need third party kernel modules working such as Nvidia drivers or third party monitoring services such as Sysdig [4]
I started looking at creating a system container / systemd unit file that builds a new container on boot if a new kernel is detected. The current idea is it would do the following:
1) Check to see if a new kernel module is needed
2) Bind mount the `kernel-devel` source from the Atomic Host into the container
3) Check out the current WireGuard source and build the module (manually or via DKMS)
4) Enable's the newly built kernel module via system container [5]
Some issues with this idea come to light quickly as the current Fedora Atomic Host snapshot has mismatching `kernel` and `kernel-devel` packages so building the module this way might not always work. I haven't fully figured out if this is the right path forward on getting kernel modules built. It seems that some folks have done somewhat similar things for CoreOS to get kernel module support for Nvidia based GPUs. [6] [7]
I turned to IRC to get some pointers on my above idea to solve this problem and @walters recommended that I start an issue.
[1] https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2017-Nov…
[2] https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/
[3] https://lists.zx2c4.com/pipermail/wireguard/2017-August/001656.html
[4] https://sysdig.com/blog/dig-into-atomic-host/
[5] https://github.com/giuseppe/hellomod
[6] https://github.com/ryanolson/CoreOS-GPU
[6] https://github.com/src-d/coreos-nvidi7
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/493
On Wed, 2019-01-16 at 02:34 +0000, Fedora compose checker wrote:
> No missing expected images.
>
> Failed openQA tests: 2/2 (x86_64)
>
> ID: 345338 Test: x86_64 AtomicHost-dvd_ostree-iso install_default@uefi
> URL: https://openqa.fedoraproject.org/tests/345338
> ID: 345339 Test: x86_64 AtomicHost-dvd_ostree-iso install_default
> URL: https://openqa.fedoraproject.org/tests/345339
Note - these mails should really go to the Atomic list (rather than
test@ and devel@), but I need to update some things to make this happen
(it worked when we had 'Fedora-Atomic' composes, but now those went
away and we have these updates composes instead, it doesn't).
It seems the Atomic installer images from the nightly 'updates' and
'updates-testing' composes for F29 started failing as of 20190115.n.0
and still failed in 20190116.n.0. Failure looks like:
https://openqa.fedoraproject.org/tests/345339#step/_do_install_and_reboot/4
not sure what the cause is.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net