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
same key
what I thought
zfs "not working" what does this mean? kmod won't load?
didn't even install
i still haven't resolved the current build issues in ucore/ucore-kmods so the kernels could be out of sync now
It's probably kernel drift
the package is in the rpm database
yeah, zfs was built for 6.8.9
Since that isn't in sync with akmods, I'm going to drop it.
Unless we add zfs to akmods, Not building directly against the used kernel is a fail.
I'm more curious why we're able to build on akmods
yeah, i share this curiosity... what's different about
akmods repo with the CoreOS kernel vs ucore-kmods with the CoreOS kernelI guess on akmods, it's using fedora's unfiltered repos and it can find a version
Hmmm, I thought i was adding what was needed, like the archive repos etc. I’ll look at the repo config closer
it's right now not finding a match for 6.8.11. It only has up to 6.8.10
but that's bizarre given the coreOS image HAS 6.8.11 LOL
I think this is the fix: https://github.com/ublue-os/ucore-kmods/pull/18
i think after PR ucore-kmods#18 merges, you should be able to use the zfs from it again
however, you raise a good point... if we are building akmods for CoreOS kernels in akmods repo... perhaps we should be building zfs there too?
We build with podman in akmods so we'll have issues until 24.04 drops
But I can put something in there today. And then only build for coreOS kernel
i literally fel asleep working on this... and just woke up... and want to sleep more... we can discuss after a nap ? 😉
build with podman? not buildah?
is this workaround (fixing the tar issue, right?) valid for zfs, too?
i solved it in ucore-kmods by using docker-buildx
sorry, buildah. You used docker-buildx to avoid the issue in ucore. I believe it still an issue until the ubuntu 24.04 builders are ready
ok, since we are still waiting on 24.04, lets not rush it
and i did not experience the issue you mentioned about package issues with negativo17's nvidia
so i'm back to thinking we should try it
at the very least, i can keep going in a branch
and ucore-kmods DOES use it... and is providing 555... so technically, you could use that from ucore for bluefin/aurora now 😉
Yeah, I have this right now:
https://github.com/ublue-os/akmods/pull/207
But, maybe not the best method? It needs 24.04 and literally is just curling from Ucore-akmods
GitHub
feat: Use ucore zfs build script for coreos kernel by m2Giles · Pul...
chore(ci): Proper Excludes
chore: workaround Tar Bug
Thank you for contributing to the Universal Blue project!
Please read the Contributor's Guide before submitting a pull request.
and... looks like we have nega17 nv 555 now in akmods
https://github.com/ublue-os/akmods/pull/173
Surface didn't like this
i assume this is getting fixed now per: https://discord.com/channels/1072614816579063828/1255929616439185541/1255932834724712559
I have a matched kernel for GTS images. Currently now working through getting zfs to build
i mean, for the moment, i still think it's fine to pull zfs from ucore-kmods
Won't work for gts.
GTS is using a 200 kernel
oh....
It's figuring out which kernel version. Then switches to that
i didn't know there was a different kernel for GTS, i thought it would be using CoreOS kernel since even Fedora Release-1 is often pushing newer kernels than CoreOS
And matches GTS version.
So a F39 kernel on F39
yeah, that'll be weird... getting into a situation where "gts" is F39 but has a newer kernel than latest/F40 with CoreOS kernel
Yeah that's what we're moving away from in bluefin is the idea.
Latest -> current distro kernel
Stable -> coreOS kernel
GTS -> coreOS major-minor but from distro. So basically a downgraded kernel.
Make sense?
i don't understand where you are getting and older than stable kernel for GTS
Kojipkgs
it'll simply be... "unpatched"
no?
Yepp the patch number will just be behind. And minor version will be delayed
So GTS on bluefin would be 6.8.11-200.fc39 right now
oh, so you are saying... Even though CoreOS is F40 and 6.8.11-300.fc40 right now... fedora is still building -200.fc39 ?
or they DID build it and it's still there
i think i see your plan now
sorry i was slow on the uptake
Yepp it's still there
We are merged