Interest in a nvidia installer module?
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
20 Replies
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 😠.
Any contribution like this would be very welcome!
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?
I meant the closed source ones (which still support some legacy cards).
So @fiftydinar is the mastermind behind that module so he'd probably know better
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 anymoreI 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
GitHub
GitHub - franute/blue-build-modules at nvidia-akmods
BlueBuild standard modules used for building your Atomic Images - GitHub - franute/blue-build-modules at nvidia-akmods
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?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 NvidiaTo 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 🤔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 lostCorrect, 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-automaticWell, 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 workCool, 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.are kargs needed for it too, or just for proprietary?
there's power saving karg I think for
openI think they are too
oh, is it? I had no idea
that's
nouveau actually
just rememberedlet me do something, I'll create a draft PR and track any comments there maybe?
sounds good