Nvidia binary drivers fail to install on Fedora 32

[Ty Young]

Either no one is testing Fedora 32 on Nvidia hardware or Fedora has 
entered an entirely new level of salt. Attempting to install from 
RPMFusion results in:


Mar 28 22:32:44 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[10990]: Building 
/usr/src/akmods/nvidia-kmod-440.64-2.fc33.src.rpm for kernel 
5.6.0-0.rc7.git1.1.fc33.x86_64
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:   { echo 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-uvm/uvm_utils.o

/tmp/akmodsbuild.6qACAcgU/BUILD/nv>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:    ./tools/objtool/objtool orc 
generate  --module --no-fp --retpoline --uaccess 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:   ld -m elf_x86_64  -z 
max-page-size=0x200000   -r -o 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-drm.o

>  
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:   { echo 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/nvidia-drm/nvidia-drm.o

/tmp/akmodsbuild.6qACAcgU/BUILD/n>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: make -f ./scripts/Makefile.modpost
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:   sed 's/ko$/o/' 
/tmp/akmodsbuild.6qACAcgU/BUILD/nvidia-kmod-440.64/_kmod_build_5.6.0-0.rc7.git1.1.fc33.x86_64/modules.order

| scripts/mod/modpost   -i ./Module.>
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: FATAL: modpost: GPL-incompatible 
module nvidia-drm.ko uses GPL-only symbol 'mutex_lock_nested'
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: make[2]: *** 
[scripts/Makefile.modpost:93: __modpost] Error 1
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: make[1]: *** [Makefile:1596: 
modules] Error 2
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: make[1]: Leaving directory 
'/usr/src/kernels/5.6.0-0.rc7.git1.1.fc33.x86_64'
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: make: *** [Makefile:81: modules] 
Error 2
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: error: Bad exit status from 
/var/tmp/rpm-tmp.BkO4oE (%build)
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]: RPM build errors:
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     cannot open Packages database 
in /var/lib/rpm
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     user mockbuild does not exist 
- using root
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     group mock does not exist - 
using root
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     user mockbuild does not exist 
- using root
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     group mock does not exist - 
using root
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     user mockbuild does not exist 
- using root
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     group mock does not exist - 
using root
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     cannot open Packages database 
in /var/lib/rpm
Mar 28 22:33:45 localhost.localdomain 
rpm-ostree(akmod-nvidia.post)[16484]:     Bad exit status from 
/var/tmp/rpm-tmp.BkO4oE (%build)


No issues with Arch Linux. The driver is being blocked from being 
installed purely for ideological reasons.

[Neal Gompa]

On Sat, Mar 28, 2020 at 11:57 PM Ty Young <youngty1997(a)gmail.com&gt; wrote:
>  Either no one is testing Fedora 32 on Nvidia hardware or Fedora has
>  entered an entirely new level of salt. Attempting to install from
>  RPMFusion results in:
>
>  
[snip error spew from rpm-ostree]

>  No issues with Arch Linux. The driver is being blocked from being
>  installed purely for ideological reasons. 
Okay, no. This is actually a fundamental technical flaw with
RPM-OSTree. In fact, *zero* DKMS or AKMod based packages will work
with RPM-OSTree based systems, and has been known for at least three
years: https://github.com/coreos/rpm-ostree/issues/1091

It has nothing to do with any ideological hatred for NVIDIA. It's just
the RPM-OSTree developers have so far been pushing to force containers
in every little nook and cranny, even when unneeded or unwanted,
instead of solving the problem to support akmods.

You can use regular kmod packages with Fedora Silverblue (rpm-ostree
install kmod-nvidia). You can also use regular Fedora Workstation and
have akmods work perfectly.



--
真実はいつも一つ！/ Always, there's only one truth!

[Leigh Scott]

>  On Sat, Mar 28, 2020 at 11:57 PM Ty Young
> <youngty1997(a)gmail.com&gt; wrote: 
>  You can use regular kmod packages with Fedora Silverblue (rpm-ostree
>  install kmod-nvidia). You can also use regular Fedora Workstation and
>  have akmods work perfectly.
>   
We don't supply compiled kmod packages at rpmfusion, using akmod-nvidia is the only
option that provides nvidia kernel modules.

> 
> 
> --
> 真実はいつも一つ！/ Always, there's only one truth!

[Neal Gompa]

On Sun, Mar 29, 2020 at 2:51 AM Leigh Scott <leigh123linux(a)gmail.com&gt; wrote:
>  > On Sat, Mar 28, 2020 at 11:57 PM Ty Young <youngty1997(a)gmail.com&gt;
> wrote:
>
>  > You can use regular kmod packages with Fedora Silverblue (rpm-ostree
>  > install kmod-nvidia). You can also use regular Fedora Workstation and
>  > have akmods work perfectly.
>  >
>
>  We don't supply compiled kmod packages at rpmfusion, using akmod-nvidia is the only
> option that provides nvidia kernel modules.
>  
That's going to become a major thorn in everyone's side over time. The
Workstation WG generally needs kmod-* packages for Silverblue and to
fix the problems with NVIDIA kmods on Secure Boot systems. Without
pre-made kmod-* packages tracking Fedora kernels, all of that goes up
in smoke.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Leigh Scott wrote:
>  We don't supply compiled kmod packages at rpmfusion, 
Since when? Why? Where was this discussed?

A compiler has no business being on end users' systems. Fedora is not 
Gentoo. The akmod approach is flawed, independently of Silverblue etc.

RPM Fusion used to provide compiled kmod packages for years, and those just 
worked. (Well, for the proprietary ones, they only worked as well as 
proprietary drivers work to begin with, but that was no fault of the kmod 
packages.) So why and when did that stop?

And the way Silverblue works, it is just not possible for them to support 
akmod packages, by design. I consider this a major design flaw in
rpm-ostree. But RPM Fusion refusing to provide binary kmod packages does not 
help, either.

        Kevin Kofler

[Vitaly Zaitsev]

On 29.03.2020 18:24, Kevin Kofler wrote:
>  RPM Fusion used to provide compiled kmod packages for years, and
> those just 
>  worked. (Well, for the proprietary ones, they only worked as well as 
>  proprietary drivers work to begin with, but that was no fault of the kmod 
>  packages.) So why and when did that stop? 
Not enough human resources for this useless work. Do you want to volunteer?

-- 
Sincerely,
  Vitaly Zaitsev (vitaly(a)easycoding.org)

[Ty Young]

On 3/29/20 3:04 PM, Vitaly Zaitsev via devel wrote:
>  On 29.03.2020 18:24, Kevin Kofler wrote:
> > RPM Fusion used to provide compiled kmod packages for years, and those just
> > worked. (Well, for the proprietary ones, they only worked as well as
> > proprietary drivers work to begin with, but that was no fault of the kmod
> > packages.) So why and when did that stop?
>  Not enough human resources for this useless work. Do you want to volunteer?
>  
Honest question here: Why does Fedora/RPMFusion have to have someone 
constantly package, watch over and/or fix packages? Surely it'd be 
easier to just automate(download source from upstream and package) 
everything as much as possible and only step in when things break?

[Dominik 'Rathann' Mierzejewski]

On Sunday, 29 March 2020 at 22:20, Ty Young wrote:
>  
>  On 3/29/20 3:04 PM, Vitaly Zaitsev via devel wrote:
>  > On 29.03.2020 18:24, Kevin Kofler wrote:
>  > > RPM Fusion used to provide compiled kmod packages for years, and
>  > > those just worked. (Well, for the proprietary ones, they only
>  > > worked as well as proprietary drivers work to begin with, but that
>  > > was no fault of the kmod packages.) So why and when did that stop?
>  > Not enough human resources for this useless work. Do you want to
>  > volunteer?
>  
>  Honest question here: Why does Fedora/RPMFusion have to have someone
>  constantly package, watch over and/or fix packages? Surely it'd be
>  easier to just automate(download source from upstream and package)
>  everything as much as possible and only step in when things break? 
I don't maintain an kmods, but from what I observe in the package
commits, they break with each new Fedora kernel release and the
maintenance burden is even higher for older nVidia driver versions.

You're welcome to help with automation, but I'm afraid hunting for
patches or writing them yourself will be a constant manual job in this
case.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
>  I don't maintain an kmods, but from what I observe in the
> package
>  commits, they break with each new Fedora kernel release and the
>  maintenance burden is even higher for older nVidia driver versions.
>
>  You're welcome to help with automation, but I'm afraid hunting for
>  patches or writing them yourself will be a constant manual job in this
>  case. 
Well, if the kmod breaks, the akmod almost certainly breaks too, the same 
way, you just don't notice it (at least until the end user bug reports start 
coming in). That is another reason why the akmod approach is flawed.

So, sure, there is work that cannot be automated, but that is exactly the 
part of the work that has to be done for akmods as well, and an automated 
kmod build process would automatically alert you as soon as the kernel gets 
released. (Ideally, as soon as it gets built in Fedora Koji, or at least as 
soon as it hits updates-testing, whereas most users will only notice the 
akmod breaking after it hits the stable updates.)

        Kevin Kofler

[Neal Gompa]

On Sun, Mar 29, 2020 at 6:18 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Dominik 'Rathann' Mierzejewski wrote:
>  > I don't maintain an kmods, but from what I observe in the package
>  > commits, they break with each new Fedora kernel release and the
>  > maintenance burden is even higher for older nVidia driver versions.
>  >
>  > You're welcome to help with automation, but I'm afraid hunting for
>  > patches or writing them yourself will be a constant manual job in this
>  > case.
>
>  Well, if the kmod breaks, the akmod almost certainly breaks too, the same
>  way, you just don't notice it (at least until the end user bug reports start
>  coming in). That is another reason why the akmod approach is flawed.
>
>  So, sure, there is work that cannot be automated, but that is exactly the
>  part of the work that has to be done for akmods as well, and an automated
>  kmod build process would automatically alert you as soon as the kernel gets
>  released. (Ideally, as soon as it gets built in Fedora Koji, or at least as
>  soon as it hits updates-testing, whereas most users will only notice the
>  akmod breaking after it hits the stable updates.)
>  
This goes back to the thing I've been talking about in other threads
for years: unnecessary grunt work to force people to manually do
rebuilds which could be triggered via automation.

While these days, we say the reason why Fedora doesn't do kmod
packages is because we'd rather have all the stuff in the upstream
kernel, I remember that much of the original reasoning for yanking
them out was that it was too troublesome for everyone trying to
maintain kmod packages to do rebuilds each time the kernel was bumped.
The user experience sucked because we didn't have (and still don't
have) a good mechanism for ensuring kmods were built and submitted
along with every kernel update.

Funnily enough, this same problem has manifested in a different, more
annoying and critical form: the gcc <-> annobin issue. Every single
gcc update has managed to break briefly whenever they forget to
rebuild annobin along with it.

Maybe one day we'll get smart dependency rebuilding that actually
submits to the build system. Koschei is just a few steps shy of being
able to do just that...




--
真実はいつも一つ！/ Always, there's only one truth!

[Ty Young]

On 3/29/20 3:25 PM, Dominik 'Rathann' Mierzejewski wrote:
>  On Sunday, 29 March 2020 at 22:20, Ty Young wrote:
> > On 3/29/20 3:04 PM, Vitaly Zaitsev via devel wrote:
> >> On 29.03.2020 18:24, Kevin Kofler wrote:
> >>> RPM Fusion used to provide compiled kmod packages for years, and
> >>> those just worked. (Well, for the proprietary ones, they only
> >>> worked as well as proprietary drivers work to begin with, but that
> >>> was no fault of the kmod packages.) So why and when did that stop?
> >> Not enough human resources for this useless work. Do you want to
> >> volunteer?
> > Honest question here: Why does Fedora/RPMFusion have to have someone
> > constantly package, watch over and/or fix packages? Surely it'd be
> > easier to just automate(download source from upstream and package)
> > everything as much as possible and only step in when things break?
>  I don't maintain an kmods, but from what I observe in the package
>  commits, they break with each new Fedora kernel release and the
>  maintenance burden is even higher for older nVidia driver versions.
>
>  You're welcome to help with automation, but I'm afraid hunting for
>  patches or writing them yourself will be a constant manual job in this
>  case. 

It was just a general question, not even specific to Nvidia really.


If the source code isn't being modified and no one wants to look after 
it(which is 100% fine, not everything does, really), then why not just 
ship it as-is from upstream?


Does Fedora/RPMFusion really need to modify every open source game, 
library, or application in their repos or something?


With Java specifically, most library deps can be downloaded via Maven or 
other online repo hosts. If not, the required jar files can most likely 
be downloaded from *somewhere* at least. The only requirement is the 
base build systems(gradle, ant, maven).


Maybe there are good answers to all of these, but looking in from the 
outside it seems like madness to have someone maintain every package, 
most of which probably aren't even being modified.


>
> Regards,
> Dominik

[Daniel Smith]

>  If the source code isn't being modified and no one wants to look
> after 
>  it(which is 100% fine, not everything does, really), then why not just 
>  ship it as-is from upstream? 
There is no "upstream" Nvidia packages for F32 (or even F31). The nvidia drivers
need to be packaged for Fedora. If you're looking for someone to blame, blame Nvidia.

akmods under Silverblue have a slight advantage over normal Workstation in that rpm-ostree
won't deploy the update if there's an error in the akmod build process, which goes
a long way of preventing people from waking up with a broken desktop.

[Vitaly Zaitsev]

On 30.03.2020 10:45, Daniel Smith wrote:
>  The nvidia drivers need to be packaged for Fedora. 
This is absolutely impossible. No proprietary software are allowed.

-- 
Sincerely,
  Vitaly Zaitsev (vitaly(a)easycoding.org)

[Emmanuel Seyman]

* Vitaly Zaitsev via devel [30/03/2020 12:42] :
>  This is absolutely impossible. No proprietary software are allowed. 
I believe OP means that NVidia must provide a third-party repo for Fedora.

Emmanuel

[Leigh Scott]

>  Leigh Scott wrote:
>  
>  Since when? Why? Where was this discussed? 
It will 4 years in July.

https://pkgs.rpmfusion.org/cgit/nonfree/nvidia-kmod.git/commit/?id=52cadb...

I believe there may have been a brief discussion between kwizart and me on IRC.
They were dropped due to workload and lack of active maintainers' look at the stats.

https://koji.rpmfusion.org/koji/buildsbyuser

The infra and release tasks add additional workload.

>  
>  A compiler has no business being on end users' systems. Fedora is not 
>  Gentoo. The akmod approach is flawed, independently of Silverblue etc.
>   
Users would still need a compiler to install the nvidia.run file if we stopped providing
nvidia or all other kmods.

>  RPM Fusion used to provide compiled kmod packages for years, and
> those just 
>  worked. (Well, for the proprietary ones, they only worked as well as 
>  proprietary drivers work to begin with, but that was no fault of the kmod 
>  packages.) So why and when did that stop?
>  
>  And the way Silverblue works, it is just not possible for them to support 
>  akmod packages, by design. I consider this a major design flaw in
>  rpm-ostree. But RPM Fusion refusing to provide binary kmod packages does not 
>  help, either. 
I don't have any spare time due infra and release tasks, you can do the kmod rebuild
tasks if you want them back?

> 
>         Kevin Kofler

[Kevin Kofler]

Leigh Scott wrote:
>  It will 4 years in July.
>  
>
> https://pkgs.rpmfusion.org/cgit/nonfree/nvidia-kmod.git/commit/?id=52cadb...
For the record, you link only the nvidia-kmod change here, but the same 
change was also applied around the same time to all the other kmod packages, 
in both free and nonfree.

>  I believe there may have been a brief discussion between kwizart and
> me on
>  IRC. They were dropped due to workload and lack of active maintainers'
>  look at the stats. 
That is very intransparent. Was the decision even announced to the user 
community?

(I do not currently use any kmod or akmod packages, so I might not be fully 
up to date on the documentation. I have used some kmod packages from the 
free section in the past, at least kmod-qc-usb and kmod-kqemu, which are now 
both obsolete and removed. But at least I do not remember the change having 
been announced.)

>  Users would still need a compiler to install the nvidia.run file if
> we
>  stopped providing nvidia or all other kmods. 
Of course. That goes for all packages, not just kernel modules. It is not a 
valid argument against having a binary package. The whole point of having 
binary packages is that we do not all need to compile the same unmodified 
software ourselves, wasting time and energy, and leading to errors being 
detected only on end user machines.

It is great that Free Software allows us to recompile it at any time, so 
that we can make any changes we want, but if we are not going to change the 
software, why do we want to recompile it? And non-Free modules such as 
nvidia cannot even be meaningfully modified to begin with, making it even 
more pointless to recompile the glue code on the user's machine.

>  I don't have any spare time due infra and release tasks, you can
> do the
>  kmod rebuild tasks if you want them back? 
I'm with Ty Young there, this needs to be automated. This is really a 
textbook case of continuous delivery.

        Kevin Kofler

[Marius Schwarz]

Am 29.03.20 um 18:24 schrieb Kevin Kofler:
>  RPM Fusion used to provide compiled kmod packages for years, and those just 
>  worked. (Well, for the proprietary ones, they only worked as well as 
>  proprietary drivers work to begin with, but that was no fault of the kmod 
>  packages.) So why and when did that stop? 
The precompiled kmod-nvidia packages where hell, because they sometimes
needed days to get online.
While people where waiting, the system did not boot into the newest
kernel as the needed driver was missing.

akmod is the much better solution for this.

best regards,
Marius

[Richard Shaw]

On Mon, Mar 30, 2020 at 1:54 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt;
wrote:

>  Am 29.03.20 um 18:24 schrieb Kevin Kofler:
>  >
>  > RPM Fusion used to provide compiled kmod packages for years, and those
>  just
>  > worked. (Well, for the proprietary ones, they only worked as well as
>  > proprietary drivers work to begin with, but that was no fault of the
>  kmod
>  > packages.) So why and when did that stop?
>
>  The precompiled kmod-nvidia packages where hell, because they sometimes
>  needed days to get online.
>  While people where waiting, the system did not boot into the newest
>  kernel as the needed driver was missing.
>
>  akmod is the much better solution for this.
>  
Yes, some sort of automated solution would only work if the kernel stopped
breaking the builds so often, requiring manual intervention. Lately I've
gotten a new kernel on my Fedora 31 install almost every update. It's just
too much to deal with. RPM Fusion has a small fraction of both the
infrastructure and volunteers as Fedora.

Thanks,
Richard

[Kevin Kofler]

Richard Shaw wrote:
>  Yes, some sort of automated solution would only work if the kernel
> stopped
>  breaking the builds so often, requiring manual intervention. Lately I've
>  gotten a new kernel on my Fedora 31 install almost every update. It's just
>  too much to deal with. RPM Fusion has a small fraction of both the
>  infrastructure and volunteers as Fedora. 
But how do akmods solve that? What will happen with the akmod if the kernel 
breaks the build is that the akmod will fail to build on the user's machine! 
How does that resolve the issue? IMHO, it makes it worse!

        Kevin Kofler

[Leigh Scott]

>  Richard Shaw wrote:
>  
>  But how do akmods solve that? What will happen with the akmod if the kernel 
>  breaks the build is that the akmod will fail to build on the user's machine! 
>  How does that resolve the issue? IMHO, it makes it worse!
>  
>          Kevin Kofler 
I can guarantee akmod-nvidia will always build on stable releases as I use it.
Your kmod idea is flawed, the new kernel builds will always be at least 7 days behind
fedora kernel.
This is due to 2 pushes being required to get the new akmods to stable repo, I haven't
got enough time  to do more pushes (sign, mash and sync repo's).

[Kevin Kofler]

Leigh Scott wrote:
>  Your kmod idea is flawed, the new kernel builds will always be at
>  least 7 days behind fedora kernel. This is due to 2 pushes being required
>  to get the new akmods to stable repo, I haven't got enough time  to do
>  more pushes (sign, mash and sync repo's). 
That also really calls for more automation. Also, an automated rebuild 
against a kernel that is already in Fedora stable updates should go directly 
to stable and so require only 1 push, not 2.

But ideally, the automated rebuild would already happen when the kernel is 
in Fedora updates-testing and the kmod would then end up in testing. Then, 
when the Fedora update goes stable, the RPM Fusion kmod should also (ideally 
automatically) go to stable. So you would always be at most 1 push behind, 
and the goal is to ensure that the push happens in a timely manner through 
better automation. (The push should just be a matter of you clicking on a 
button or running a ./push.sh script and not consume your time as it seems 
to do right now, judging from your description. And the kmod rebuilds should 
really be completely automatic and not require you to do anything at all.)

As for the inevitable synchronization issue that will happen anyway (also 
due to mirroring), have you seen my boolean Requires proposal? I think that 
implementing that correctly should guarantee that the kernel and the kmod 
are only upgraded together (without requiring special handling in DNF as in 
the old experimental Yum plugin). In principle, that should even work if the 
kmod is 7-14 days behind depending on schedule alignment.

        Kevin Kofler

[Gary Buhrmaster]

On Tue, Mar 31, 2020 at 3:57 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  But ideally .... 
You seem to have a lot of thoughts about changes
and improvements to the process.

When should the RPMFusion community expect
you to complete those improvements?

[Kevin Fenzi]

...snip...

Perhaps you all could take this to the rpmfusion mailing lists?

kevin

[Kevin Kofler]

Marius Schwarz wrote:
>  The precompiled kmod-nvidia packages where hell, because they
> sometimes
>  needed days to get online.
>  While people where waiting, the system did not boot into the newest
>  kernel as the needed driver was missing. 
DNF just needs to prevent the upgrade as long as the kmod is not available. 
I think that this can actually be enforced through boolean dependencies 
nowadays, without requiring any special handling in DNF: the kmod-nvidia 
metapackage should not just have a:
Requires: kmod-nvidia-%{latest_kernel_version}
as in the past, but also a:
Requires: (kmod-nvidia-bin > %{latest_kernel_version} if kernel > 
%{latest_kernel_version})
where kmod-nvidia-%{latest_kernel_version}:
Provides: kmod-nvidia-bin = %{latest_kernel_version}
Requires: kernel = %{latest_kernel_version}

So this will forbid installing a newer kernel unless there is also a newer 
kernel module to go with it (and the Requires in the module enforces that 
the versions also have to actually correspond).

        Kevin Kofler

[Ty Young]

> Okay, no. This is actually a fundamental technical flaw with
> RPM-OSTree. In fact, *zero* DKMS or AKMod based packages will work
> with RPM-OSTree based systems, and has been known for at least three
> years: https://github.com/coreos/rpm-ostree/issues/1091 
> It has nothing to do with any ideological hatred for NVIDIA. It's
> just
> the RPM-OSTree developers have so far been pushing to force containers
> in every little nook and cranny, even when unneeded or unwanted,
> instead of solving the problem to support akmods. 
> You can use regular kmod packages with Fedora Silverblue (rpm-ostree
i>nstall kmod-nvidia). You can also use regular Fedora Workstation and
> have akmods work perfectly. 

Interesting. I’ve used Fedora 30 Silverblue before and it worked(yes, using AKMod). Maybe
this is a regression?

Anyway, when I looked up the error I got a result from Nvidia’s forum wherein a user
pointed to a kernel issue. Apologies if that isn’t the case.


> --
> 真実はいつも一つ！/ Always, there's only one truth!

[Ty Young]

> Interesting. I’ve used Fedora 30 Silverblue before and it worked(yes,
> using AKMod). Maybe this is a >regression? 
> Anyway, when I looked up the error I got a result from Nvidia’s forum
> wherein a user pointed to a >kernel issue. Apologies if that isn’t the case. 
Wait, nevermind. It’s kmod, got them confused:


rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia

[Leigh Scott]

>  Wait, nevermind. It’s kmod, got them confused:
>  
>  
>  rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia 
You need to use the nodebug kernel

https://fedoraproject.org/wiki/RawhideKernelNodebug

>  rpm-ostree(akmod-nvidia.post)[16484]: FATAL: modpost:
> GPL-incompatible 
>  module nvidia-drm.ko uses GPL-only symbol 'mutex_lock_nested'

[Ty Young]

On 3/29/20 1:46 AM, Leigh Scott wrote:
> > Wait, nevermind. It’s kmod, got them confused:
> >
> >
> > rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
>  You need to use the nodebug kernel
>
>  https://fedoraproject.org/wiki/RawhideKernelNodebug 

Wiki doesn't say how to install nondebug on Silverblue. How do you do 
it? Last time I tried with Fedora 31 beta it just threw errors since 
Silverblue's repo tends to be out of sync with the rest of Fedora for 
whatever reason, among other issues.


>
>> rpm-ostree(akmod-nvidia.post)[16484]: FATAL: modpost: GPL-incompatible
>> module nvidia-drm.ko uses GPL-only symbol 'mutex_lock_nested'
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Gerald Henriksen]

On Sun, 29 Mar 2020 06:46:17 -0000, you wrote:

> > Wait, nevermind. It’s kmod, got them confused:
> > 
> > 
> > rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
>
> You need to use the nodebug kernel
>
> https://fedoraproject.org/wiki/RawhideKernelNodebug
>  
And just how wise is it putting Rawhide kernels into a Fedora 32
system?

[Kevin Fenzi]

On Sun, Mar 29, 2020 at 11:31:13AM -0400, Gerald Henriksen wrote:
>  On Sun, 29 Mar 2020 06:46:17 -0000, you wrote:
>  
>  >> Wait, nevermind. It’s kmod, got them confused:
>  >> 
>  >> 
>  >> rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
>  >
>  >You need to use the nodebug kernel
>  >
>  >https://fedoraproject.org/wiki/RawhideKernelNodebug
>  >
>  
>  And just how wise is it putting Rawhide kernels into a Fedora 32
>  system? 
Should work fine. In general the kernel is one of the easier things to
install/use on other releases. If it doesn't work you can just boot the
previous one, and in general it doesn't often change it's requirements
from userspace. 

That said, you can also just boot the first f32 kernel in each rc, as
those are non debug enabled. Ie, the first rc1, rc2, rc3, etc)

kevin

[Ty Young]

On 3/29/20 1:32 PM, Kevin Fenzi wrote:
>  On Sun, Mar 29, 2020 at 11:31:13AM -0400, Gerald Henriksen wrote:
> > On Sun, 29 Mar 2020 06:46:17 -0000, you wrote:
> >
> >>> Wait, nevermind. It’s kmod, got them confused:
> >>>
> >>>
> >>> rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
> >> You need to use the nodebug kernel
> >>
> >> https://fedoraproject.org/wiki/RawhideKernelNodebug
> >>
> > And just how wise is it putting Rawhide kernels into a Fedora 32
> > system?
>  Should work fine. In general the kernel is one of the easier things to
>  install/use on other releases. If it doesn't work you can just boot the
>  previous one, and in general it doesn't often change it's requirements
>  from userspace.
>
>  That said, you can also just boot the first f32 kernel in each rc, as
>  those are non debug enabled. Ie, the first rc1, rc2, rc3, etc) 

So does Fedora have a non debug kernel available in the repo that is 
useable in Silverblue right now?


>  kevin
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Daniel Smith]

Both F31 and F32 have non-debug kernels that work with the Nvidia drivers from rpmfusion.

Source: Using F32 Silverblue with the Nvidia akmods.

[Ty Young]

On 3/29/20 2:29 PM, Daniel Smith wrote:
>  Both F31 and F32 have non-debug kernels that work with the Nvidia
> drivers from rpmfusion.
>
>  Source: Using F32 Silverblue with the Nvidia akmods. 

OK, so why aren't they installing?


> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Daniel Smith]

"ostree(akmod-nvidia.post)[10990]: Building 
/usr/src/akmods/nvidia-kmod-440.64-2.fc33.src.rpm for kernel 
5.6.0-0.rc7.git1.1.fc33.x86_64"

You're using fc33 kernels which are Rawhide. You'll need to rebase down to F32 or
F31.

rpm-ostree rebase fedora/32/x86_64/silverblue

[Ty Young]

On 3/29/20 2:55 PM, Daniel Smith wrote:
>  "ostree(akmod-nvidia.post)[10990]: Building
>  /usr/src/akmods/nvidia-kmod-440.64-2.fc33.src.rpm for kernel
>  5.6.0-0.rc7.git1.1.fc33.x86_64"
>
>  You're using fc33 kernels which are Rawhide. You'll need to rebase down to F32 or
> F31.
>
>  rpm-ostree rebase fedora/32/x86_64/silverblue 

Well, that's interesting. The site here:


https://silverblue.fedoraproject.org/download


says:


Help us make Silverblue better by testing the*Rawhide*builds of 
Silverblue *that will eventually become Fedora 32*.


So isn't it supposed to be using Fedora 32's repos? The build I 
downloaded was literally from yesterday(March 28).


>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Ty Young]

On 3/29/20 3:01 PM, Ty Young wrote:
>  On 3/29/20 2:55 PM, Daniel Smith wrote:
> > "ostree(akmod-nvidia.post)[10990]: Building
> > /usr/src/akmods/nvidia-kmod-440.64-2.fc33.src.rpm for kernel
> > 5.6.0-0.rc7.git1.1.fc33.x86_64"
> >
> > You're using fc33 kernels which are Rawhide. You'll need to rebase down to
> F32 or F31.
> >
> > rpm-ostree rebase fedora/32/x86_64/silverblue
>
>
>  Well, that's interesting. The site here:
>
>
>  https://silverblue.fedoraproject.org/download
>
>
>  says:
>
>
>  Help us make Silverblue better by testing the*Rawhide*builds of 
>  Silverblue *that will eventually become Fedora 32*.
>
>
>  So isn't it supposed to be using Fedora 32's repos? The build I 
>  downloaded was literally from yesterday(March 28).
>  
tried rebasing and got:


[ty@localhost ~]$ rpm-ostree rebase fedora/32/x86_64/silverblue
1 metadata, 0 content objects fetched; 569 B transferred in 3 seconds
Checking out tree b31d65c... done
Enabled rpm-md repositories: rpmfusion-nonfree-rawhide 
fedora-cisco-openh264 rawhide rpmfusion-free-rawhide
rpm-md repo 'rpmfusion-nonfree-rawhide' (cached); generated: 
2020-03-27T12:02:18Z
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 
2020-03-17T20:10:45Z
rpm-md repo 'rawhide' (cached); generated: 2020-03-28T09:05:42Z
rpm-md repo 'rpmfusion-free-rawhide' (cached); generated: 
2020-03-27T11:47:53Z
Importing rpm-md... done
⠁
Forbidden base package replacements:
   gnome-shell-extension-launch-new-instance 3.36.0-1.fc32 -> 
3.36.0-1.fc33 (rawhide)
   fedora-repos 32-0.7 -> 33-0.3 (rawhide)
   fedora-release-common 32-0.8 -> 33-0.3 (rawhide)
   gnome-shell-extension-horizontal-workspaces 3.36.0-1.fc32 -> 
3.36.0-1.fc33 (rawhide)
   gnome-shell-extension-apps-menu 3.36.0-1.fc32 -> 3.36.0-1.fc33 (rawhide)
   fedora-gpg-keys 32-0.7 -> 33-0.3 (rawhide)
   gnome-shell-extension-places-menu 3.36.0-1.fc32 -> 3.36.0-1.fc33 
(rawhide)
   gnome-shell-extension-window-list 3.36.0-1.fc32 -> 3.36.0-1.fc33 
(rawhide)
   gnome-classic-session 3.36.0-1.fc32 -> 3.36.0-1.fc33 (rawhide)
   fedora-release-silverblue 32-0.8 -> 33-0.3 (rawhide)
   gnome-shell-extension-common 3.36.0-1.fc32 -> 3.36.0-1.fc33 (rawhide)
This likely means that some of your layered packages have requirements 
on newer or older versions of some base packages. Doing `rpm-ostree 
cleanup Resolving dependencies... done


rpm-ostree strikes again.



> > _______________________________________________
> > devel mailing list --devel(a)lists.fedoraproject.org
> > To unsubscribe send an email todevel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List
> Archives:https://lists.fedoraproject.org/archives/list/[e-mail]...

[Daniel Smith]

You will likely need to reset any mutations you have performed

$ rpm-ostree reset

[Ty Young]

On 3/30/20 3:37 AM, Daniel Smith wrote:
>  You will likely need to reset any mutations you have performed
>
>  $ rpm-ostree reset 

I decided to just download and install Fedora 31 and upgrade to Fedora 
32 as I would as if I was using it(AKA installing Nvidia drivers).


It was a bit rocky, to say the least.


rpm-ostree first gave some error about fedora-release(31) and the 
RPMFusion repos. Why does Fedora not attempt to bump the RPMFusion repo 
version automatically?


So I removed the RPMFusion repo, rebooted, tried again, only for 
rpm-ostree to throw a bogus error that I fixed by running "rpm-ostree 
cleanup -m". Bogus package upgrade errors are common in Silverblue, so 
this wasn't something I didn't already know.


A reboot later and I unknowingly left with a system that couldn't 
perform updates because it couldn't find the origin of the Nvidia GPU 
driver and libs(it said it couldn't driver packages, but the Nvidia 
driver was loaded...). I tried to install the repo via Gnome Software, 
only for it to fail and tell me that I needed to reboot for the changes 
to take affect.


What changes? It failed!?!?


So, I had to remove the Nvidia drivers, rebooted and was left with 
software rendering, installed the Fedora 32 repo, rebooted, installed 
the Nvidia drivers again, rebooted, and was all good.


Is upgrading from one Fedora release to another usually this much of a 
PITA? Asking a user to to uninstall all their third-party repo apps is a 
bit of an issue.


I know people here will probably point the finger at Nvidia or other non 
open source software, but there is a "free" repo that would presumably 
have the same problems if used.


On the bright side, I wasn't dumped to TTY at any point... so that's good.




> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Kalev Lember]

On Thu, Apr 2, 2020 at 9:23 PM Ty Young <youngty1997(a)gmail.com&gt; wrote:

>  rpm-ostree first gave some error about fedora-release(31) and the
>  RPMFusion repos. Why does Fedora not attempt to bump the RPMFusion repo
>  version automatically?
>  
That's https://github.com/coreos/rpm-ostree/issues/1978

-- 
Kalev

[Ty Young]

On 4/2/20 2:30 PM, Kalev Lember wrote:
>  On Thu, Apr 2, 2020 at 9:23 PM Ty Young <youngty1997(a)gmail.com 
>  <mailto:[e-mail]>> wrote:
>
>      rpm-ostree first gave some error about fedora-release(31) and the
>      RPMFusion repos. Why does Fedora not attempt to bump the RPMFusion
>      repo
>      version automatically?
>
>
>  That's https://github.com/coreos/rpm-ostree/issues/1978 

Thanks for the issue link.


It's a real shame rpm-ostree bugs are still such an issue. There seems 
to be a large increase in the amount of Flatpak applications on Flathub, 
making it way more viable. There is even a GUI application for managing 
Flatpak permissions now.


(although some are out of date. Gedit is still on 3.34.2.)


Why are none of these Silverblue issues ever brought up in Fedora <X> 
release blocker emails? It seems like Silverblue can be released in any 
quality state.


>  -- 
>  Kalev
>
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Leigh Scott]

>  On 3/29/20 2:29 PM, Daniel Smith wrote:
>  
>  
>  OK, so why aren't they installing? 
Works fine here on normal fedora

$ inxi -GCS
System:
  Host: leigh Kernel: 5.6.0-0.rc7.git1.2.fc33.x86_64 x86_64 bits: 64 
  Desktop: Cinnamon 4.4.8 Distro: Fedora release 33 (Rawhide) 
CPU:
  Topology: 8-Core model: AMD FX-8350 bits: 64 type: MCP L2 cache: 2048 KiB 
  Speed: 1406 MHz min/max: 1400/4400 MHz Core speeds (MHz): 1: 1410 2: 1414 
  3: 1406 4: 1400 5: 1407 6: 1409 7: 1406 8: 1397 
Graphics:
  Device-1: NVIDIA GP107 [GeForce GTX 1050 Ti] driver: nvidia v: 440.64 
  Display: x11 server: Fedora Project X.org 1.20.7 driver: nvidia 
  unloaded: fbdev,modesetting,nouveau,vesa resolution: 3840x2160~60Hz 
  OpenGL: renderer: GeForce GTX 1050 Ti/PCIe/SSE2 v: 4.6.0 NVIDIA 440.64


I have never had a use for silverblue so have never tried it.


> 
> 
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Daniel Smith]

kmod-nvidia and akmod-nvidia will do the same thing, kmod-nvidia is an empty package that
pulls in akmod-nvidia.