-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace rpmfusion Obsoletes with Conflicts, add auto-fallback to nouveau systemd service #20
Conversation
|
I think this is not enough. I'm upgrading from RPMFusion, elrepo and Nvidia CUDA repositpories, this is only a bit of it. For example, one of the latest bugs opened on Fedora's bugzilla (don't have the ticket number at hand, sorry, it's the one where Leigh helped) where the user had left overs from both RPMFusion and CUDA repositories would have not happened with the Obsoletes/Provides in place. I guess I will just remove all Obsoletes/Provides and put everything into Conflicts. Would it be better if I just leave the base driver and modules/tools in the repository? Being an interim solution I can leave CUDA and all the rest in the other repository (multimedia). Most of the universities use those. |
nvidia-driver.spec
Outdated
| %global _dracutopts nouveau.modeset=0 rdblacklist=nouveau | ||
| %global _dracutopts_rm nomodeset vga=normal | ||
| %global _dracutopts rdblacklist=nouveau | ||
| %global _dracutopts_rm nomodeset vga=normal nouveau.modeset=0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Further down in the SPEC file I just check for the whole string of options, and the other two have been there for quite a while, so I guess all users will not have those and the nouveau.modeset=0 parameter would not get removed.
I guess I need to remove the old Dracut options and just leave that, or iterate on each of one in the SPEC file.
|
Looks fine for me, as written in the email I would have actually preferred to have the kernel locked into place until all modules are available. Someone who installs the Nvidia drivers would definitely give priority to the drivers being available than updating the kernel. I think users will be pretty vocal about this just after we enable it. |
|
I've added the fallback service and made sure that the I'm going to make some test (hopefully this evening) and write a blog post/change the docs to announce that the packages no longer upgrade ELRepo, RPMFusion and Nvidia packages. I have also a couple of pending items to explain so this is a good moment. After that, so I guess this weekend or next week, I'll push the ones with Conflicts in place. I need to also make the same changes to the CUDA and NVENC packages to avoid errors in solving dependencies when you have/want the other packages. |
|
Hi,
On 09-05-17 10:17, Simone Caronni wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
In nvidia-driver.spec <#20 (comment)>:
> @@ -4,15 +4,15 @@
%if 0%{?rhel} == 6
# RHEL 6 does not have _udevrulesdir defined
%global _udevrulesdir %{_prefix}/lib/udev/rules.d/
-%global _dracutopts nouveau.modeset=0 rdblacklist=nouveau
-%global _dracutopts_rm nomodeset vga=normal
+%global _dracutopts rdblacklist=nouveau
+%global _dracutopts_rm nomodeset vga=normal nouveau.modeset=0
Further down in the SPEC file I just check for the whole string of options, and the other two have been there for quite a while, so I guess all users will not have those and the |nouveau.modeset=0| parameter would not get removed.
I guess I need to remove the old Dracut options and just leave that, or iterate on each of one in the SPEC file.
Ah good point, I would prefer to iterate and remove then one-by-one,
to make sure we get things right on upgrade too and not just on a
clean install.
Regards,
Hans
|
|
Hi,
On 09-05-17 10:20, Simone Caronni wrote:
Looks fine for me, as written in the email I would have actually preferred to have the kernel locked into place until all modules are available.
We also need the fallback for people who install the nvidia driver on
systems where it cannot work because e.g. the nvidia GPU is too old and
since we are doing dkms/akmods we should basically never not have the
module available. I know that major kernel version bumps may cause
the build too fail, but we can see those coming long before hand
and normally we should have fixed dkms/akmods packages available
in time for things to just work when the new kernel hits the updates
repository.
Someone who installs the Nvidia drivers would definitely give priority to the drivers being available than updating the kernel. I think users will be pretty vocal about this just after we enable it.
See above, the fallback is intended for when things are seriously
broken or simply just cannot work. Almost all kernel updates or
in the .z part of the x.y.z version number and there akmods/dkms
should just work.
Regards,
Hans
|
|
Hi,
On 11-05-17 16:47, Simone Caronni wrote:
I've added the fallback service and made sure that the |nouveau.modeset=0| parameter is removed on Fedora 25+.
Thank you.
***@***.*** <6b3bf32>
In this one you also removed "blacklist nouveau" from nvidia.conf,
we actually do still need that, since nvidia.ko is always loaded
post initrd, otherwise udev will modprobe both and which one we
get is unknown, so that needs to be fixed.
The fallback service will work regardless because an explicit
modprobe (rather then one from udev) will ignore the blacklist.
***@***.*** <df32483>
This one looks good.
I'm going to make some test (hopefully this evening) and write a blog post/change the docs to announce that the packages no longer upgrade ELRepo, RPMFusion and Nvidia packages. I have also a couple of pending items to explain so this is a good moment.
After that, so I guess this weekend or next week, I'll push the ones with Conflicts in place. I need to also make the same changes to the CUDA and NVENC packages to avoid errors in solving dependencies when you have/want the other packages.
Ok, as always thank you for your work on this.
Regards,
Hams
|
Add dracut.conf.d/99-nvidia.conf file enforcing that the nvidia modules never get added to the initramfs. This is necessary because the userspace bits and the kernel modules must be 100% in sync, otherwise things might break. Normally we build the initrd before building the dkms / akmod so this issue will only happen if the initrd somehow gets re-generated afterwards, still this is something which we should avoid.
|
Hmm, my latest push was meant for a new pull-req really, since 2 of the 3 commits from this pull-req have been merged and the other one is going to get a different fix. So lets close this pull-req. |
No description provided.