bsherman is there a differnce between
@bsherman is there a differnce between kmod for v4l2loopback and our kmods? mainly asking would using kmods directly from rpmfusion circumvent these issues you are trying to solve
96 Replies
not 100% sure what you mean...
our
akmods repo just pre-builds the akmods from rpmfusion for the specific kernel on the image version we are deploying and stages them so we can later installhmm, so why could i layer v4l2loopback in past even tho out akmods were already applied
but you are saying that after we make an image users cant apply new ones
v4l2loopback was the very first kmod added to main images, so I'm not sure when you could have done so
nvidia was the first one ever
i had it in an nvidia image
true, i was just referring to main, not nvidia
interesting question.
I'd have to sift through commits... another side of the problem is the inclusion of kernel-devel packages, i'm not sure if they were part of nvidia way back then
but, regardless, the problem trying to solve has more to do with simplifiying the overall build process and incidentally makes the main images simpler/better for layering akmods
ok looked at when i had added v4l2 akmod to my image it was mid april so i layered it before that as i was testing if that is enought to enable obs virtual cam(and it was)
that was not coming across well in the chat discussion
ok, i'm going to look at nvidia from that time frame, interesting
what does it simplify?
just curious
did you read my proposal?
the problem with the local layering seems to be that basically we freeze the dev dependencies at the build time and when a user tries to do
rpm-ostree install some-akmod then the kernel version it tries to pull in will be whatever is available in the repos and not what we set at build time
Hence dep conflictfrom proposal 🙂
- Reduce complexity of builds and number of images maintained
- Provide a single foundational image for all downstream Universal Blue images/users
- Prevent artificial restrictions on downstream usage
the single foundational image is confused today because of both nokmods and main existing
i didnt even know nokmods image existed so
yeah, it's getting confusing as we try to make workarounds
that's part of what i'm trying to address before it gets worse
that doesnt seem to be a problem if you update the image daily
but main with kmods can't be the base for all of ublue today we had to hack a workaround
It may be a problem depending on which mirrors are hit, time frame of the kernel release and which mirrors have which versions
Basically the same problem we were having of Rpmfusion being out of sync
eh, it's different, becasue by adding a kmod to main it prevents downstreams from changing kernels
I mean the root cause of why the kmods get that dependency conflict
k
it shouldnt
i mean 🙂 there's a lot of things i think shouldn't work a certain way... i agree with you it should work better but RJ Kyle and I were all certainly stuck on this
better question would have been why
so im asking why now
because i dont see a reason why it wouldnt work
I am happy for you to find the answer and share. I would appreciate it.
first i would like to know why you think it doesnt work
or point me to discussion of why it doesnt work
GitHub
[Bug] you can't install akmod-wl · Issue #85 · ublue-os/main
When I install akmod-wl on my laptop using the silverblue-main:37 image, I get the following error. It works fine on the official silverblue image but this error apears on ublue. To reproduce, inst...
It’s linked in the proposal I think
At least in the original ticket it was
i think this was for the original question where i said that i could install akmods in past even if there were akmods present, now we are talking about adding kmod prevents downstream from changing kernel which seems not how it should work if you remove all kmods and kernel you should be able to add new kernel
I feel like you're asking me to document months of intermittent effort here... not all done by me.
Yeah I think the problem with that is that you need to know what to remove, I think bazzite did that before nokmods existed - you can check their issue tracker
yes becuase you are essentially saying trust me bro, i have a hard time making such a decision without being properly informed
wow
Asking for such level of documentation seems completely unwarranted - that takes a lot of time to do… Possibly more than making the changes themselves
@Bigpod it doesn't work. I've confirmed it as well
I suppose I'm more saying I trust @EyeCantCU and @KyleGospo ... maybe that's an appeal to authority, but they were the ones blocked on asus/surface support and this is related to how we resolved that issue.
You can't install akmods on OCI, I tested this with the upstream fedora images
It's a limitation
here's a thread where the asus/surface stuff was discussed and covers how we got to having nokmods, etc...
https://discord.com/channels/1072614816579063828/1072617059265032342/1146281167327338606
but yeah, i really don't feel like I need to document this at such a level. not like this has been done in secret
So we have to install them during the image creation
wait what
great thats enough
That's why we do this at all
End users can't layer kmods themselves
i think we are talking in circles, again in mid april i layered a v4l2loopback(and installed via oci for actual deployment) kmod from rpmfusion while nvidia was already installed unless at the time nvidia wasnt installed as kmod something must have changed between now and then
Can you reproduce that?
That is against my entire knowledge on this subject
idk, i guess its been a while i would need to find a kmod for soemthing that i can test in rpmfusion to install since v4l2loopback is shipped with main now
Don't test main, test the image main depends on
You should be unable to successfully layer an akmod
ok let me spin up a vm
give me half an hour im creating a clean VM
ima point out some fun here 🙂
no matter the outcome, we all win!
If Bigpod's test shows we're doing something wrong, that's great becasue we get to improve it for the whole poject and (arguably) can drop the
If Bigpod's test shows we're doing something wrong, that's great becasue we get to improve it for the whole poject and (arguably) can drop the
*-nokmods and i'm mostly happy (because my bigger issue is keeping the sope narrow and supporting clean set of "base" images on which everything can rely)
if not, at least we'll be more confident in the rationale for the proposal.
thanks for digging in, @Bigpodhonestly im doing it just as much to see if im an idiot becuase i remember having it for few weeks layered before i got of my ass and added it to my image
lol that's totally fair
yup, ty for the test
I've been braindead before
@bsherman @KyleGospo i loaded original oci image(quay.io/fedora-ostree-desktops/kinoite:38 used kionite as was first one that i clicked on) into my clean new install of fedora kinoite added obs-studio from flatpak and rpmfusion after reboot i installed akmod-v4l2loopback package from rpmfusion it installed without any errors or warnings and i have virtual cam support in obs-studio
modinfo v4l2loopback works?i get back stuff bunch of lines of text back like filename alias version license
hmmm..
It's nice that layering them appears to work but I think removing them is still an issue for custom kernels. unfortunately. We had tried doing this over in ASUS but never got anywhere
well now i know i might not be an idiot
haha
If you try with a ublue main image it will probably fail with a dependency error
well some error will occur since v4l2loopback akmod is already installed
Yeah you need a different one
Idk what Rpmfusion has
Virtual box drivers?
akmod-VirtualBox
Seems to exist maybe that
ill rebase to main and try
ok its rebasing
GitHub
[Critical bug] Unable to layer
akmod-wl · Issue #229 · ublue-os/b...This is what I typed sudo rpm-ostree install akmod-wl on bazzite kde (not nvidia or deck version) Checking out tree 161ccab... done Enabled rpm-md repositories: fedora-cisco-openh264 fedora-modular...
from prior to us shipping WL
so this wasn't a conflict
@akdev @KyleGospo @bsherman ok i rebased to kinoite main and first tried installing akmod-VirtualBox which had this same error output as above bug report i also tried akmod-wireguard which installed normally modinfo has proper output, so at the end of it all im up for this change as it appears some akmod packages for whatever reasons arent working
weird v4l2 works
but I'm glad we're not on dumb dumb juice over here
it's this way for a reason
well both v4l2 and wireguard work
wireguard is built into the kernel now, should be no kmod at all
you're just getting the CLI
I've just installed akmods-VirtualBox on bluefin-dx and bluefin-dx-framework without problems
hmmm plot thickens
yeah i will now go to bluefin, because i started on silverblue-main where it didn't work
did you layer it or in containerfile
i'm layering it
hmm plot thickens
becuase when i install akmod-VirtualBox i get smae looking error as above akmod-wl does
yep that error i've seen too
i'm on bluefin:38 and i got that error
but its installed
?
nope
so if you seen the eror then you had problems
it wants to install 3packages, where on bluefin-dx-framework installed 58
why does it work on bluefin-dx and dx-framework, but not on bluefin
If my theory is correct that the root cause is due to mismatching versions on base image vs mirrors
i reset everything before rebasing btw
You would see intermittent failures like we did on nvidia kmods for that reason too
But maybe it is not that though
there is a reason i hate mirrors just like i hate cache
and this just compounds it
oke so now i go back into bluefin-dx and see whats happends lol
on dx it just installs
🤔 🤯 !🤔
akmod-wl on bluefin-dx without problems, i will go to bluefin now
on bluefin akmod-wl errors out
i try akmod-VirtualBox one more time
errors out
Well i have no clue why, but that is what's happening lol
tried swapping a kernel on bluefix-dx? 🙂
let me reset and rebase back to bluefin-dx 😄
getting those pull numbers up 😄
you don't have to, but it's probably more of a blocker than the akmods since that's needed for asus/surface
i will try
as far as the errors from the akmod "post" phase... there could possibly be some variety based on how the different rpms are configured
we already have a solution for the kernel swap on asus/surface... i'm just curious
but isn't it strange that it happends on bluefin only, but not on dx? could it be that some strange dependancy is installed in dx or something?
you say you get this error still?
Unable to open sqlite database /usr/share/rpm/rpmdb.sqlite: unable to open data?sorry i don't know which one exactly, a post install(bwrap something something)
yeah something like
error: Running %post for akmod-wl: bwrap(/bin/sh): Child process killed by signal 1; run journalctl -t 'rpm-ostree(akmod-wl.post)' for more informationyep thats the one
i will get a specific one if you need, from journalctl, but i first do the surface thing
yep that's one of the problems we've seen
well haha, i'm clueless about anything else. It is some strange stuff
need some error output from the bluefin version install akmod-wl?
verified was still working on bluefin-dx, and on bluefin i got the famous error
jep its the sql one
https://paste.centos.org/view/1b2e7f96
this is wierd