52 Replies
https://github.com/ublue-os/akmods/pull/394
Note: I want to see the builds look good before I un-draft, but it's promising.
ok what are we thinking support wise?
like I'm not looking for ARM/nvidia builds
I'm thinking stable/latest for bluefin
The most obvious issue seems to be with nivida
The only machines I care about in that config are not consumer ones, hence GDX
i thought you use NVidia on GDX?
ok, you don't need nvidai
so for CentOS, you don't even need common akmods
but for coreos-stable you do
(eg bluefin:stable)
i kinda think bazzite is going to be a problem with the various kmods
but hah CentOS worked fine: https://github.com/ublue-os/akmods/actions/runs/17158302502?pr=394
right, what I mean to say is bluefin fedora doesn't need any nvidia arm, don't need the builds there
but i will probably make the build work so it's generic and available... since it's uCore will want those drivers too
yeah and I don't think we pulled in zfs to gdx either, so this is useful, thanks
yep
welcome
.
OK... good progress on the ARM build PR @M2 and @j0rge
https://github.com/ublue-os/akmods/pull/394
and this run demonstrates that we can build for ARM on some releases (eg F42) but not others (F41) https://github.com/ublue-os/akmods/actions/runs/17482839878?pr=394
and other runs show no ARM builds (bazzite and main) while all the CentOS 10 builds have both ARM and x86_64
all this is defined by our
images.yaml and workflows generate properly with the Justfile ...we won't need 41 soon
Sorry for the confusion on the PR. I saw aarch64 building in the centoskmodsig CI job so assumed it was running already
gotcha
no worries
For the record I did review your modifications to the Justfile regarding manifest creation and I don’t believe they work as written, though I get the idea of what you were trying to do.
I hope to get back to this late tonight or tomorrow.
@M2 if you have a chance to weigh in you are welcome to contribute to my PR above.
My goals:
Ideally I want to run manifest if either an arm or x86 kernel is cached, but right now the workflow assumes the x86 kernel existing is enough, which is probably adequate.
Beyond that, the Justfile should probably check if the expected image with arch specific tag exists before adding to manifest.
I think we could do that with skopeo, but not podman-manifest or podman-image since those look at local state not remote.
So I’ll probably do the latter first, and make a note regarding the former.
ok!
GitHub
feat: enable ARM builds for akmods by bsherman · Pull Request #394...
The good @m2 recently refactored akmods in a most excellent way, and included ready-to-test aarch64 build support.
It's time to give it a try.
i added this to the PR
I'm pretty confident with this PR at this point. The conditional manifest generation was the last hurdle, but since we use just variables to allow generation of a full script, we can see it should be working quite nicely. In a nutshell, this enables ARM for akmods builds of: CentOS kernel CentOS Kmods SIG kernel CoreOS kernels longterm 6.12 fedora kernel NOT for: bazzite kernels "main" (latest fedora) kernels anything on Fedora 41 the images.yaml format and workflow/justfile support building: x86_64 only, aarch64 only, or both. Currently we have x86_64 only and both building. When merging, the primary thing to be watching will be that manifests generate correctly as that should be the only thing which impacts current x86_64 builds.and I'lm looking for approvals
... and my axe
@Kyle Gospo around nerd?
i would really like more than 2 approvals... especially would prefer at least a glance over by @M2 given he's the mastermind of the current akmods build structure... though, i think i've done him proud on this one
ok turn the automerge off
i got a second approval.. i'm going to merge
ugh
centos and centos-kmodsig broke
and they were both fine a day ago
might be getting rate limited
builders are saturated too
it'll be a hot minute
yeah, it's fine
picked a bad time to merge i guess
bah
manifest stuff doesn't work anyway
looks like the entire project is rebuilding rn
dangit, found the mistake for manifest
ok, i'm going to force merge now
well, t hat's not relaly what i wanted
bleh
our ISO thing is such a disaster
installers are a mistake 😉
just use
dd 😉
@j0rge
tada!
https://github.com/ublue-os/akmods/pkgs/container/akmods-nvidia-open/510863967?tag=coreos-testing-42
a multiarch akmods image!!!!
all akmods built properly and multi-arch except i waited to run CentOS and CentOS KMODSIG... those builds are going now
it is finished
arm64 akmods for CentOS too
ok now what do I do?
lol
this needs a full rebuild: https://github.com/ublue-os/bluefin-lts/pull/689
GitHub
feat: ZFS and Nvidia AKMODS for LTS, DX, GDX, and HWE variants. by ...
This PR makes the following changes:
Adds ZFS akmods to all x86_64 variants
There are no ZFS akmods for ARM64, and I don't have a place to test it.
Change Nvidia from DKMS to Akmods
Do ...
ok
they appear to be rebuilding fine!
i've got to sleep... can chat about this tomorrow
I'm finishing up too, got ISOs werkin'
this happened so I don't know if it's related
I'm off work this week so doing ublue
what kernel pin?
I don't think we have it yet, I'm just going by what the log says
unless this needs the existing PR to merge to go green?
what log, sorry, i'm not sure where this is coming from
GitHub
chore(deps): update quay.io/centos-bootc/centos-bootc:c10s docker d...
Bluefin LTS, built on CentOS with bootc. Contribute to ublue-os/bluefin-lts development by creating an account on GitHub.
oh this?
pin-kernel.sh will not even exist any more after the above PR merges... I'll comment on issueah ok, so a transitory bug, my favorite. 😄
Hey @bsherman what the tldr on what's wrong with the sb key on the kmods sig kernel?
I'd love to see if I can make something happen this week, but honestly I probably don't have time
He explained it to me last night it's complicated
But I think an option is to see if we can get that kernel signed?
like how they sign 6.12.x? I don't see why they would do that though
I think there is a plan for CentOS SIGs to get to use Fedora's keys, once they are all colocated in the same datacenter. I think they are now co-located but it's still a few months away when they could use fedora's stuff
yeah
RH wants to maintain complete custody of CentOS' key I think, which makes sense
There's plent of other distros that have SB keys that might screw up and leak it and make Microsoft mad. But for RH that would be a multi-million dollar kerfuffle
I think waiting on them is fine
should I be asking shaun about this?
idk, seems like the SIGs are eager to get this. it's been a re-occuring topic in their board minutes for a couple years
oh ok
so another +1
this would be ideal
the CentOS Kmods SIG provided packages do not have signed kernel/modules.
the ublue-os/akmods kernel-cache process signs the the
vmlinuz the "ublue kernel" key, but NOT the associated modules...
Thus, SecureBoot works if the "ublue kernel" key is enrolled as a MOK, but only until the kernel tries to load a required, unsigned module.
It's possible we could extend the kernel-cache signing function in akmods to sign modules, too...
there's a nice example here https://wiki.debian.org/SecureBoot#Manually_signing_kernels_and_kernel_modules
It would have to happen after signing the vmlinuz file, and then the appropriate kernel-modules RPMs would need to be rebuilt... which we do for kernel already.looks like we're still doomed?
Latest status was I got all the kmods signed from kernel-modules package
But then rpm rebuild failed.
That’s where it sits until I can pick it up again