38 Replies
ok, i'm looking into why the fail: https://github.com/ublue-os/akmods/actions/runs/17447735449 after: https://github.com/ublue-os/akmods/pull/398
oh shit
I see what I did
😄
it's cool, i'll help
omg, that's not what I thought I did at all
dude, I have been so busy ... but it's pretty cool that today i was actually thinking "Hey! I think i can get into ublue stuff tonight" and then you pinged 🙂
that's my bad, I must have seen the usual red for some other bs check and been like I'm tired of that broken
no worries
the unpin still needed to happen
anyway, I still don't understand the xx1 convention
see how my gross neglicence has found another bug
that's just what fedora does for release numbering
we can make our matching be more aware of it
but also did you see what the kids are pulling off in that zfs hwe test branch on lts?
i haven't had much time to look at that part
amazing
i'm kinda hoping to get this kernel match fixed and get the akmods ARM branch cleaned up
i saw @James had a PR for centos-kmods-SIG kernel improve in akmods
well then sherman get a case of beer lets go
i think i'm out of beer
unfortunate
what do you want me to do
I can make kyle do push ups or something if you want
🙂
@j0rge i pushed a PR ... going on a quick walk while that runs
I’m still walking, but I just thought of something that I was looking at before I pushed go. I definitely need to fix something.
Yeah, I see it failed where I thought it would
hmm... i think the failures now are just repo mirror crap
We actually want to cache the same major.minor.minor kernel as coreos. Is that possible? I see that it still pulls latest
i'm happy to help with that
i thought someone else had picked that up, but i never heard back
Yeah, just got akmods kernel swapping now. But the kmods kernel isn't signed right for sb, haven't gotten too far into it.
hmm...
I think if we are caching the kernel in akmods, we're also signing it with the universal blue key...
this is like using the bazzite kernel though... there's no upstream signature on the kernel so it won't even boot without the universal blue key added as MOK
want me to try to get the centos kmods SIG kernel pulling the coreos version and verifiy signing?
i can start with your PR
Yeah I booted the normal kernel signed with akmods, enrolled the key, then when I rebase its busted. But I think that's due to the bleeding edge ness not the lack of SB since it actually starts the boot
hmm
Now that I think about it it is working with sb. But wiring up the verification would be nice
ok , i'll take a closer look at your PR
so, the trick is...
we need to read the latest version from centos:stable image. but ignore the release info and somehow determine
1) IF centos-kmodsSIG has this version and if so
2) what the release is for it
I was doing this kinda in a script
GitHub
bluefin-lts/build_scripts/scripts/pin-kernel.sh at main · ublue-os...
Bluefin LTS, built on CentOS with bootc. Contribute to ublue-os/bluefin-lts development by creating an account on GitHub.
But now we have to curl koji 🙁
This has all the kernel versions available
https://cbs.centos.org/kojifiles/packages/kernel/
Look like there's only 1 release
there are sometimes more than 1
https://cbs.centos.org/kojifiles/packages/kernel/6.15.9/. the most recent builds of ucore still have 6.15.9 because the PR you approved for me hasn't merged yet...
and you can see here, this has a secondary release
this usually happens when there's a rerelease of the pacakge for a packaging fix or something
maybe we do something kinda silly, like, check for
9.el10 8.el10 ... as a countdown until 1.el10? to find if it's valid?Looks like it was release 2 only once in 9 months
Actually it could have been a typo since they merge in ELN kernel spec
well, the naive approach is just use
1.elN
and that'll usually be correct
it's what we did for coreos-stable for a long time... a naive approach
i'm going to try to connect this with the coreos kernel version lookup now
I think I have something that "should" work
i'm a little concerned though... when i check the centos-kmods-sig repo... its not showing the kernel version from CoreOS... it's already aged out
though clearly it's in kojifiles
https://cbs.centos.org/kojifiles/packages/kernel/6.15.9/1.el10/x86_64/
so... as long as we are caching all the required packages we install (that is, if we don't end up needing other things in this directory) i think we'll be fine@James and @j0rge I added some stuff to https://github.com/ublue-os/akmods/pull/400
trying to help get that in shape.
GitHub
feat: update kernel download method for centos-kmodsig to allow for...
Kmods SIG inlynkeeps a few of the latest kernels in their repo. We need to pull the from CBS (Koji) for older ones
looks like it's working!
looks like aarch64 isn't getting added to the manifests, the lines were commented out
I’m not sure what you are doing here
aarch64 isn’t in akmods yet.
I’m working on that in this PR
https://github.com/ublue-os/akmods/pull/394
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.
Also, I welcome feedback on the PR or in this thread
https://discord.com/channels/1072614816579063828/1408468804551442602/1413366006633463878