Bug 3481

I've been thinking about this one... Do we really need to be using yum (or dnf)? 

Looking at the requirements of the kmod-nvidia package in particular, should any of these NOT already be installed if you properly setup an akmod package and didn't bork things up yourself?

$ rpm -q --requires kmod-nvidia-3.19.1-201.fc21.x86_64-346.47-2.fc21.1.x86_64
/bin/sh
/bin/sh
/usr/sbin/depmod
/usr/sbin/depmod
kernel-uname-r = 3.19.1-201.fc21.x86_64
nvidia-kmod-common >= 1:346.47
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

Couldn't we just do a force install via RPM? I don't see why internet access for yum metadata or downloads should really be required or supported.

(In reply to comment #1)
> I've been thinking about this one... Do we really need to be using yum (or
> dnf)? 
We need to use yum or dnf because theses are the appropriates 'high level' tools to use over using rpm directly:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=3350#c0

So we need to test for dnf and if not available drop back to yum.

Ok, for F21 the default package package manager is yum so I think it's reasonable to expect yum to be installed.

If you really don't want to have yum installed try installing the package "dnf-yum" which redirects yum calls to DNF and let me know if that works.

When we eventually branch for F22, where DNF is the default, I'll update the script to use it instead.

Note: The script could be updated to detect and use either, but I'm not a bash expert and don't have time at the moment to do the work, but if a patch is supplied I will evaluate and test it for inclusion.

Created attachment 1444 [details]
Patch to use dnf over yum if dnf command is available

Either that, or just add a dependency on %{_bindir}/yum to akmods for the time being so dnf-yum gets pulled in where necessary.

*** Bug 3699 has been marked as a duplicate of this bug. ***

(In reply to comment #5)
> Created attachment 1444 [details]
> Patch to use dnf over yum if dnf command is available

Thanks for the patch, I've never used the "type" command before. I'm concerned that it may return true with the yum compat package which creates a symbolic link from /usr/bin/yum to /usr/bin/dnf so I've modified it to use the more traditional bash test, if [ -f /usr/bin/dnf ]; then...


(In reply to comment #6)
> Either that, or just add a dependency on %{_bindir}/yum to akmods for the time
> being so dnf-yum gets pulled in where necessary.

This looks to be a problem for dnf right now...

https://bugzilla.redhat.com/show_bug.cgi?id=1223478

Preliminary tests are good, I did a "dnf erase kmod-nvidia.." and reran akmods manually and dnf was detected and used to install the kmod.

To pull in part of the discussion from the mailing list, I'm not sure this fixes the problem where the previous dnf instance doesn't release the lock on the rpm database prior to the install of the kmod.

Technically that's the failure mode that the two systemd service files address but they are not enabled by default, it seems there is now a special file to list what services are enabled by default so the old scripts no longer seem to work.

That did get me thinking though, should all *automated* executions of akmods/akmodsbuild be run through systemd?

This would make the logging less obscure since it would be in the journal instead of /var/cache/akmods... and someday systemd may get the ability to notify users of a service failure which would be nice to know before you reboot!

Hello,

I'm not sure if I am in the right bug. I have both DNF and YUM installed on my system, and when upgrading kernel versions, the "build" fails with:

"Could not install newly built RPMs". Before that, I saw something about the RPMDB being locked:


RPMDB already locked by 7495
  Die Anwendung mit Prozess-ID 7495 ist: dnf
    Speicher : 128 M RSS (690 MB VSZ)
    Gestartet: Sat Jul 18 10:35:37 2015 - vor 08:54
    Status : Schläft


What's annoying is that this actually works perfectly well if I do `akmods --force` manually.


I tried using the akmods.patch (attachment 1444 [details]) from Comment #5, but this has the same result.

Can anybody help me out here? How can I get akmods running automagically?


(In reply to comment #9)
> That did get me thinking though, should all *automated* executions of
> akmods/akmodsbuild be run through systemd?
> 
> This would make the logging less obscure since it would be in the journal
> instead of /var/cache/akmods... and someday systemd may get the ability to
> notify users of a service failure which would be nice to know before you
> reboot!
This sounds like a great idea!

Created attachment 1464 [details]
Log of failed installation

From http://www.spinics.net/linux/fedora/fedora-users/msg460981.html :

> Here's a clue. I just booted my f22 partition and ran dnf update, which did
> update the kernel and caused akmods to build a new nvidia driver. It worked
> fine for me, it installed the nvidia driver with no problem, so perhaps it is
> a timing issue and depends on how long various update activities take.

I just checked and it turns out the install failure didn't actually happen during the reboot. Instead it happened during the `dnf update` invocation!

This kinda makes sense, because calling dnf during an invocation of dnf seems rather weird.

Would it be possible to install the newly-built package with rpm directly instead of yum?

(In reply to comment #12)
> I just checked and it turns out the install failure didn't actually happen
> during the reboot. Instead it happened during the `dnf update` invocation!

Yes, yum tries to wait for a rpmdb lock, dnf does not. It's a rather annoying change in behavior.


 
> This kinda makes sense, because calling dnf during an invocation of dnf seems
> rather weird.
> 
> Would it be possible to install the newly-built package with rpm directly
> instead of yum?

No, that's actually how it used to work but was changed for a good reason I can't remember right at the moment. I'm working on a solution so that when the RPM builds, but just can't be installed it's not marked as a failure so it will try again on shutdown or reboot (if the appropriate service is enabled).

This should be fixed in the current release. Closing.