feat: support CoreOS Kernel by m2Giles ·...
https://github.com/ublue-os/akmods/pull/206
Adding coreOS kernel to the build matrix for akmods
GitHub
feat: support CoreOS Kernel by m2Giles · Pull Request #206 · ublue-...
Thank you for contributing to the Universal Blue project!
Please read the Contributor's Guide before submitting a pull request.
49 Replies
lets chat yo
i'm happy to see this building...
becaue i'm getting failues on ucore-kmods
GitHub
build-ucore · ublue-os/ucore-kmods@6f22d5a
A caching layer for pre-built CoreOS kmod RPMs . Contribute to ublue-os/ucore-kmods development by creating an account on GitHub.
Yeah. I was trying to use ucore-kmods directly and the negativo17 Nvidia repos were giving me issues
well, the failure i'm seeing is realted to
akmods package wanting kernel-devel-matched i think?I was saying even to just consume. Negativo17 was wanting really random old versions
hmmm
Zfs would install no issue.
so what you are saying is... i have been wise to wait on negativo17 nivida?
I believe so.
It was saying no matched versions for the coreOS kernel
While rpmfusion was willing to build
well, that kinda sucks, since rpmfusion's packaging really is too heavy for server use IMHO
That's unfortunate
it pulls in a lot of stuff beyond just the driver... eg, xorg and wayland
this is why i used negativo17 for ucore
That makes sense.
I'll redig into ucore-kmods to see if I can gleen anything more from negativo17.
I agree that having the full Xorg and Wayland stack is overkill for ucore.
They were receptive to our displaylink quirk so I'm hopeful to move over to them for hopefully a more consistent experience
still don't think negativo17 is the cause of the ucore-kmods failures though, it's failing in
build-prep.shHmmm
The build prep failure is similar to what I was seeing with negativio17
It wants to install any other dependency and then says it conflicts with something newer than the coreOS kernel
There are bluefin images on ghcr using the coreOS kernel with the akmods.
bluefin:gts-testing-coreos
bluefin-nvidia:gts-testing-coreos
Zfs from Ucore is included.
On ToDo is reworking the COPY --from since right now the coreOS Ucore/Nvidia module is copied on every container build which is a slowdown (200 MB of unneeded download)
Nvidia install is being done as part of container build using the hwe Nvidia install script. Much like Bazzite does (but we don't have a separate target)
Does Ucore use a different key? I would like to not copy the Ucore-akmods step.
Zfs is not working. I'm also wondering if this should or shouldn't be included since coreOS is still a relatively recent kernel