| Summary: | xorg-x11-drv-nvidia-304xx breaks Xorg startup on QXL-equipped VM guest | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | L. Gabriel Somlo <somlo> |
| Component: | nvidia-304xx-kmod | Assignee: | leigh scott <leigh123linux> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | hans, kwizart, negativo17, sergio, somlo |
| Priority: | P1 | ||
| Version: | 26 | ||
| Hardware: | x86_64 | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
L. Gabriel Somlo
2017-07-12 21:28:29 CEST
Everything is right and accurate in this report. It's just two days late... But thanks for reporting. The F26 GA repo was frozen on Monday. This is exactly the kind of report I'd like to have in the development phase. Please consider using development releases earlier. The 304xx packages needs update about the nvidia-xorg.conf file. But indeed, no nvidia drivers should be in the @hardware-support group since it's default installed (even on Server or Minimal install). Please have a look on theses and submit a PR in github to remove the drivers for each maintained release, it will be taken into account on the next package push. https://github.com/rpmfusion-infra/rpmfusion-nonfree-comps A next step is probably a need to create a dedicated @nvidia-driver group. (In reply to Nicolas Chauvet from comment #1) > Everything is right and accurate in this report. > It's just two days late... > But thanks for reporting. > > The F26 GA repo was frozen on Monday. This is exactly the kind of report I'd > like to have in the development phase. Please consider using development > releases earlier. Sorry, I read about F26 being released on lwn.net and decided to rebuild one of my VMs to check it out. You're right of course, but still, better late than never :) > The 304xx packages needs update about the nvidia-xorg.conf file. > But indeed, no nvidia drivers should be in the @hardware-support group since > it's default installed (even on Server or Minimal install). > > Please have a look on theses and submit a PR in github to remove the drivers > for each maintained release, it will be taken into account on the next > package push. > https://github.com/rpmfusion-infra/rpmfusion-nonfree-comps https://github.com/rpmfusion-infra/rpmfusion-nonfree-comps/pull/2 > A next step is probably a need to create a dedicated @nvidia-driver group. Thanks much, --Gabriel Thx for the PR. Let's verify everything is working as expected before to close. If you ever still have the broadcom-wl package, I would rename the group as @proprietary-hardware-support or something. We would need a dedicated group for nvidia support (only the last serie would worth it). I will handle this. (In reply to Nicolas Chauvet from comment #3) > Thx for the PR. > > Let's verify everything is working as expected before to close. Will the comps file shipping with the rpmfusion-nonfree (for f26) reflect this change? If so, that's great, as I won't need any local workarounds. I'll update this bug if/when I see that change propagate. > If you ever still have the broadcom-wl package, I would rename the group as > @proprietary-hardware-support or something. I am probably using it on some of my hardware (or will, when I upgrade to f26). I think "@hardware-support-nonfree" would nicely match the repo name, and people asking for Fedora's @hardware-support won't experience any surprises. Actually, if you rename the package group, the presence or absence of the nvidia drivers in it would not even be a problem for me at all! > > We would need a dedicated group for nvidia support (only the last serie > would worth it). I will handle this. (In reply to L. Gabriel Somlo from comment #4) .. > > Let's verify everything is working as expected before to close. > > Will the comps file shipping with the rpmfusion-nonfree (for f26) reflect Nope, the current fix will only be found in the development/rawhide and f2?-nonfree-updates repositories... (the push was done few minutes ago). Is the fix working as appropriate in the current f26 tree ? (In reply to Nicolas Chauvet from comment #6) > Is the fix working as appropriate in the current f26 tree ? Is it expected to? Earlier you said: >>> Let's verify everything is working as expected before to close. >> >> Will the comps file shipping with the rpmfusion-nonfree (for f26) reflect >> > Nope, the current fix will only be found in the development/rawhide and > f2?-nonfree-updates repositories... (the push was done few minutes ago). So I figured it'd be fixed for f27, and never went back to re-testing f26. (In reply to L. Gabriel Somlo from comment #7) .. > So I figured it'd be fixed for f27, and never went back to re-testing f26. f26-nonfree GA will be broken, but I expect that using f26-nonfree-updates should update (or not) to the fixed comps groups. (In reply to Nicolas Chauvet from comment #8) > (In reply to L. Gabriel Somlo from comment #7) > .. > > So I figured it'd be fixed for f27, and never went back to re-testing f26. > f26-nonfree GA will be broken, but I expect that using f26-nonfree-updates > should update (or not) to the fixed comps groups. Unfortunately, the removal of the nvidia packages from the nonfree-updates comps @hardware-support group will not prevent them from being pulled in (i.e. the updates comps file doesn't fully override the one in the main repo). Not sure what the policy is on modifying the main repo comps file -- I think that'd be the only way to make the fix retroactively work in any f26 kickstart, even when the nonfree-updates repo is required as part of the install... This bug is fixed in 27+ (despite reported on f26). No plan to fix the f26 GA repo, the workaround is to not use nonfree during installation or explicitely remove the -xorg-x11-drv-nvidia304xx from the default set of package to intall |