https://blue-build.org/ logo
Powered by
Interest in a nvidia installer module?
# questions
f
Hi there, I've recently run into some issues with the nvidia drivers and realised that because I'm using Ublue's base images I need to install the drivers myself like it's done for Bluefin and other images. My question is: now that I'm working on it, would people find it useful as a module? Can't promise immediate results, but will try to do my best 🥲 Cheers
a
message has been deleted
e
Yes, I would love that module please! I need legacy drivers and have no idea how to proceed, so I'm using nouveau drivers for now 😭 .
g
Any contribution like this would be very welcome!
f
Do you mean legacy legacy? I think unfortunately the can't be built anymore with recent levels 😰
What I had in mind was enabling only what Ublue provides: the Nvidia and Nvidia-open drivers
Now, another doubt I had in mind was: should it be a separate module or would it make sense to extend the existing akmods? @gmpinder any thoughts?
e
I meant the closed source ones (which still support some legacy cards).
g
So @fiftydinar is the mastermind behind that module so he'd probably know better
f
I think that extending it through 
akmods
is cleaner, but Ublue is constantly changing, so I'm not sure if they're reliable to base from their work anymore
f
I finally had little time to look into this and I have "something" 😅 working. It seem to be able to generate images with what seem to be the correct drivers installed
Now, I realised there's an issue with the akmods module when using 42 as a base. The CLI breaks because it tries to pull from 
akmods-extra
but, apparently, from 42 that's only available for 
bazzite
and not for base images (based on ublue's repo docs).
Then I dug into the CLI and found the place where this seems to be happening: 
module.rs
(not a huge Rust expert I must say) and saw quite a few references to basically do the same thing I'm doing in the script. Which is basically pull from the specific image.
More findings, I've found some comments from you guys talking about using 
nvidia: true
with the akmods module but also saying that it wasn't enabled in the end. Maybe it would be better to just try that out? Add the flag to the module's schema and debug from there? What do you think?
f
At the time I made the 
akmods
module, I thought that you can't pull files from container in a bash script, but I see that you're using 
skopeo
for that, which is smart. And that makes me realize, that maybe we can even decouple 
akmods
module from the 
CLI
, so that maintaining it becomes easier as a bash module.
I think we should enable it once it's assured that it's working correctly I couldn't test it, as I don't have Nvidia & others couldn't as they already used Ublue nvidia image
bootc
kernel arguments only work if 
bootc
is installed & used for updates btw, so it won't work on 
rpm-ostree
systems, which Ublue images utilize, except Bluefin LTS I think
yes, that was also the another reason why we didn't enable it, as we couldn't determine a way to set necessary kernel arguments in build-time for Nvidia
f
To be honest I'm just mimicking what Ublue people do when building their images 😅 Are you saying maybe we could get rid of that section in the CLI and just do it in the module directly?
I have a lenovo P50 in which the install is borked, so I'm testing with that. If someone else could test the 
nvidia-open
it would be awesome
Correct. I tried that out and I had to manually add the parameters on a 41 based build. On the other hand, a fresh 42 based install did inject the parameters correctly and I had to do nothing. I think Ublue regenerates the initramfs at the end of the build. Not sure if it's worth though as it seems to be working fine with 
bootc
and there's always their 
just
script to enable nvidia 🤔
f
yeah, exactly that
Hmm, you installed from the ISO or rebased? Because I think that Fedora 42 ISOs use 
bootc install
, so it can insert the kernel arguments. However, last time I tested, when you do 
rpm-ostree update
, those kargs would get lost
f
Correct, it was a new ISO built from 42, that's why it worked. I tried upgrading from 41 to 42 with 
rpm-ostree
and, as you said, it did nothing reg the kargs.
That reminded me to change my image to use the 
bootc-fetch-apply-service
instead of 
rpm-ostreed-automatic
f
Well, we can document that for 
rpm-ostree
images would need to apply kargs manually, while with 
bootc
there's no need
so I think we can make this work
f
Cool, I think it looks a bit rough around the edges though, so any comments are welcome.
I have also verified a 
nvidia-open
image on a VM and it at least the correct module was set in 
/etc/nvidia/kernel.conf
, but I'd prefer is someone else could test it out.
f
are kargs needed for it too, or just for proprietary?
f
I think they are too
f
there's power saving karg I think for 
open
f
oh, is it? I had no idea
f
that's 
nouveau
actually
just remembered
f
let me do something, I'll create a draft PR and track any comments there maybe?
f
sounds good
f
Quick update. After the last fix in the CLI reg akmods, it looks like I can build an image based on F42 with the Nvidia proprietary 🥳 I'll try to test it tomorrow with titanoboa and, if all goes well, I could try to accelerate this a bit 🤞
5 Views
PreviousNext
Powered by