I just ran a dnf update on my fedora 26 box and the build and install of the nvidia akmod failed:
2017/08/28 07:28:04 akmods: Installing newly built rpms 2017/08/28 07:28:04 akmods: DNF detected error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm Error: Error: rpmdb open failed 2017/08/28 07:28:04 akmods: Could not install newly built RPMs. You can find them and the logfile 2017/08/28 07:28:04 akmods: 375.66-3-for-4.12.8-300.fc26.x86_64.failed.log in /var/cache/akmods/nvidia/
After getting the system back up, I manually installed the rpm it built via dnf install and it seemed to install fine.
What the heck happened during the initial dnf update?
On Mon, Aug 28, 2017 at 6:42 AM, Tom Horsley horsley1953@gmail.com wrote:
I just ran a dnf update on my fedora 26 box and the build and install of the nvidia akmod failed:
2017/08/28 07:28:04 akmods: Installing newly built rpms 2017/08/28 07:28:04 akmods: DNF detected error: db5 error(-30969) from dbenv->open: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db5 - (-30969) error: cannot open Packages database in /var/lib/rpm Error: Error: rpmdb open failed 2017/08/28 07:28:04 akmods: Could not install newly built RPMs. You can find them and the logfile 2017/08/28 07:28:04 akmods: 375.66-3-for-4.12.8-300.fc26.x86_64.failed.log in /var/cache/akmods/nvidia/
Was RPM being updated in the same transaction? This bug[1] seems to indicate that the database being updated can cause this problem...
Thanks, Richard
On Mon, 28 Aug 2017 07:11:59 -0500 Richard Shaw wrote:
Was RPM being updated in the same transaction? This bug[1] seems to indicate that the database being updated can cause this problem...
Yep, looks like rpm shows up in the log as being updated, though I have never actually figured out what the heck akmod does and if it is part of the same transaction or not. If I poke around on the system during the dnf update, I see akmod build the new nvidia driver while dnf update is still running, so I'm not sure how an rpm that didn't exist at the start of the dnf update could be part of the same transaction :-).
Thanks for the info. Looks like it won't be a problem I see very often.
On Mon, 2017-08-28 at 08:46 -0400, Tom Horsley wrote:
On Mon, 28 Aug 2017 07:11:59 -0500 Richard Shaw wrote:
Was RPM being updated in the same transaction? This bug[1] seems to indicate that the database being updated can cause this problem...
Yep, looks like rpm shows up in the log as being updated, though I have never actually figured out what the heck akmod does and if it is part of the same transaction or not. If I poke around on the system during the dnf update, I see akmod build the new nvidia driver while dnf update is still running, so I'm not sure how an rpm that didn't exist at the start of the dnf update could be part of the same transaction :-).
Thanks for the info. Looks like it won't be a problem I see very often.
This or similar problems do show up quite often. I think it's because the akmod update builds a new rpm and tries to install it while dnf itself is still running, so there's race condition on the rpm database. If you run the rpm install after dnf finishes it will work.
poc
On 08/28/2017 08:55 PM, Patrick O'Callaghan wrote:
On Mon, 2017-08-28 at 08:46 -0400, Tom Horsley wrote:
On Mon, 28 Aug 2017 07:11:59 -0500 Richard Shaw wrote:
Was RPM being updated in the same transaction? This bug[1] seems to indicate that the database being updated can cause this problem...
Yep, looks like rpm shows up in the log as being updated, though I have never actually figured out what the heck akmod does and if it is part of the same transaction or not. If I poke around on the system during the dnf update, I see akmod build the new nvidia driver while dnf update is still running, so I'm not sure how an rpm that didn't exist at the start of the dnf update could be part of the same transaction :-).
Thanks for the info. Looks like it won't be a problem I see very often.
This or similar problems do show up quite often. I think it's because the akmod update builds a new rpm and tries to install it while dnf itself is still running, so there's race condition on the rpm database. If you run the rpm install after dnf finishes it will work.
I've not seen that behavior in a long time. I will watch, from time to time, the output in /var/cache/akmods/akmods.log while doing a "dnf update".
These lines
2017/08/28 14:30:20 akmods: Checking kmods exist for 4.12.9-300.fc26.x86_64 2017/08/28 14:30:21 akmods: Building and installing nvidia-kmod
don't appear until the last "clean up" line appears in the update process.
Then I would see...
2017/08/28 14:31:12 akmods: Installing newly built rpms 2017/08/28 14:31:12 akmods: DNF detected
And not until the last "verify" is finished will I see....
2017/08/28 14:32:03 akmods: Successful.
And you'll notice the time difference.
On Mon, Aug 28, 2017 at 7:46 AM, Tom Horsley horsley1953@gmail.com wrote:
On Mon, 28 Aug 2017 07:11:59 -0500 Richard Shaw wrote:
Was RPM being updated in the same transaction? This bug[1] seems to indicate that the database being updated can cause this problem...
Yep, looks like rpm shows up in the log as being updated, though I have never actually figured out what the heck akmod does and if it is part of the same transaction or not. If I poke around on the system during the dnf update, I see akmod build the new nvidia driver while dnf update is still running, so I'm not sure how an rpm that didn't exist at the start of the dnf update could be part of the same transaction :-).
It's not part of the same transaction unfortunately. To do that would require a dnf plugin that no one has written yet.
akmods basically runs dnf in nohup so it will sit there and wait until the current transaction completes, which is why you have to be careful to wait for a while before you reboot.
Thanks, Richard
On Mon, 28 Aug 2017 08:04:40 -0500 Richard Shaw wrote:
akmods basically runs dnf in nohup so it will sit there and wait until the current transaction completes, which is why you have to be careful to wait for a while before you reboot.
You'd think that if it really waited long enough, it wouldn't have had the problem I saw with the rpm version though :-).
In any case, I always run top when doing an update and wait till all the akmod and dnf stuff seems to have been finished for a while before I reboot.
On 08/28/2017 09:47 PM, Tom Horsley wrote:
On Mon, 28 Aug 2017 08:04:40 -0500 Richard Shaw wrote:
akmods basically runs dnf in nohup so it will sit there and wait until the current transaction completes, which is why you have to be careful to wait for a while before you reboot.
You'd think that if it really waited long enough, it wouldn't have had the problem I saw with the rpm version though :-).
In any case, I always run top when doing an update and wait till all the akmod and dnf stuff seems to have been finished for a while before I reboot.
But all you really have to do is check for
2017/08/28 14:32:03 akmods: Successful.
in /var/cache/akmods/akmods.log
kOn Mon, Aug 28, 2017 at 9:02 AM, Ed Greshko ed.greshko@greshko.com wrote:
On 08/28/2017 09:47 PM, Tom Horsley wrote:
On Mon, 28 Aug 2017 08:04:40 -0500 Richard Shaw wrote:
akmods basically runs dnf in nohup so it will sit there and wait until
the
current transaction completes, which is why you have to be careful to
wait
for a while before you reboot.
You'd think that if it really waited long enough, it wouldn't have had the problem I saw with the rpm version though :-).
In any case, I always run top when doing an update and wait till all the akmod and dnf stuff seems to have been finished for a while before I reboot.
But all you really have to do is check for
2017/08/28 14:32:03 akmods: Successful.
in /var/cache/akmods/akmods.log
So a good option might be something like:
# tail -f /var/cache/akmods/akmods.log
Thanks, Richard
-
Ed Greshko -
Patrick O'Callaghan -
Richard Shaw -
Tom Horsley