On one install, dnf managed to upgrade that kernel. On a newer machine (installed and upgraded today), it fails. Not sure why…

Here is a full run:

; sudo dnf upgrade -y
Last metadata expiration check: 5:42:13 ago on Wed 06 Mar 2019 10:56:30 GMT.
Dependencies resolved.

 Problem 1: cannot install both kernel-3.10.0-957.5.1.el7.x86_64 and kernel-3.10.0-957.5.1.el7.x86_64
  - cannot install the best update candidate for package kernel-3.10.0-957.5.1.el7.x86_64
  - cannot install the best update candidate for package kernel-3.10.0-957.el7.x86_64
 Problem 2: cannot install both kernel-devel-3.10.0-957.5.1.el7.x86_64 and kernel-devel-3.10.0-957.5.1.el7.x86_64
  - cannot install the best update candidate for package kernel-devel-3.10.0-957.5.1.el7.x86_64
  - cannot install the best update candidate for package kernel-devel-3.10.0-957.el7.x86_64
 Package            Arch         Version                    Repository     Size
 kernel             x86_64       3.10.0-957.5.1.el7         updates        48 M
 kernel-devel       x86_64       3.10.0-957.5.1.el7         updates        17 M
     replacing  kernel-devel.x86_64 3.10.0-957.5.1.el7

Transaction Summary

Total size: 65 M
Downloading Packages:
[SKIPPED] kernel-3.10.0-957.5.1.el7.x86_64.rpm: Already downloaded
[SKIPPED] kernel-devel-3.10.0-957.5.1.el7.x86_64.rpm: Already downloaded
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1
  Reinstalling     : kernel-devel-3.10.0-957.5.1.el7.x86_64                 1/4
  Running scriptlet: kernel-devel-3.10.0-957.5.1.el7.x86_64                 1/4
  Reinstalling     : kernel-3.10.0-957.5.1.el7.x86_64                       2/4
  Running scriptlet: kernel-3.10.0-957.5.1.el7.x86_64                       2/4
  Obsoleting       : kernel-devel-3.10.0-957.5.1.el7.x86_64                 3/4
  Running scriptlet: kernel-3.10.0-957.5.1.el7.x86_64                       4/4
  Cleanup          : kernel-3.10.0-957.5.1.el7.x86_64                       4/4
  Running scriptlet: kernel-3.10.0-957.5.1.el7.x86_64                       4/4
  Verifying        : kernel-3.10.0-957.5.1.el7.x86_64                       1/5
  Verifying        : kernel-3.10.0-957.5.1.el7.x86_64                       2/5
  Verifying        : kernel-devel-3.10.0-957.5.1.el7.x86_64                 3/5
  Verifying        : kernel-devel-3.10.0-957.el7.x86_64                     4/5
  Verifying        : kernel-devel-3.10.0-957.5.1.el7.x86_64                 5/5
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Traceback (most recent call last):
  File "/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 179, in user_main
    errcode = main(args)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 64, in main
    return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 99, in _main
    return cli_run(cli, base)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 123, in cli_run
    ret = resolving(cli, base)
  File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 154, in resolving
  File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 240, in do_transaction
    tid = super(BaseCli, self).do_transaction(display)
  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 872, in do_transaction
    tid = self._run_transaction(cb=cb)
  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 1021, in _run_transaction
  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 1059, in _verify_transaction
    self.history.end(rpmdbv, 0)
  File "/usr/lib/python2.7/site-packages/dnf/db/history.py", line 504, in end
  File "/usr/lib64/python2.7/site-packages/libdnf/transaction.py", line 758, in endTransaction
    return _transaction.Swdb_endTransaction(self, dtEnd, rpmdbVersionEnd, state)
RuntimeError: TransactionItem state is not set: kernel-devel-3.10.0-957.el7.x86_64

As per commenter's request:

; dnf repolist
Extra Packages for Enterprise Linux 7 - x86_64  3.6 MB/s |  16 MB     00:04    
CentOS-7 - Base                                 5.6 MB/s |  10 MB     00:01    
CentOS-7 - Updates                              4.1 MB/s | 5.2 MB     00:01    
IUS Community Packages for Enterprise Linux 7 - 3.9 MB/s | 941 kB     00:00    
slack                                            29 kB/s |  33 kB     00:01    
CentOS-7 - Extras                               1.2 MB/s | 339 kB     00:00    
repo id      repo name                                                    status
base         CentOS-7 - Base                                              10,019
*epel        Extra Packages for Enterprise Linux 7 - x86_64               13,008
extras       CentOS-7 - Extras                                               382
ius          IUS Community Packages for Enterprise Linux 7 - x86_64          570
slack        slack                                                            47
updates      CentOS-7 - Updates                                            1,457


; dnf repolist -v | grep "^Repo-filename" | awk '{print $2}' | sort ; ls /etc/yum.repos.d
total 60K
4.0K CentOS-Base.repo       8.0K CentOS-Vault.repo      4.0K ius-archive.repo
4.0K CentOS-CR.repo         4.0K CentOS-fasttrack.repo  4.0K ius-dev.repo
4.0K CentOS-Debuginfo.repo  4.0K epel.repo              4.0K ius-testing.repo
4.0K CentOS-Media.repo      4.0K epel-testing.repo      4.0K slack.repo
4.0K CentOS-Sources.repo    4.0K ius.repo
  • 1
    I'm seeing a similar symptom on my Scientific Linux 7.6 setup. For some odd reason, my problem appears to be that the main sl7 repo is disabled. Could you please share the output of dnf repolist and then dnf repolist -v | grep "^Repo-filename" | awk '{print $2}' | sort ; ls /etc/yum.repos.d ?
    – Kalvin Lee
    Mar 22 '19 at 5:20
  • 1
    Thanks for sharing. Unfortunately, at a glance, seems likely that I am chasing a red herring. For context, I share the same dependency error as you do - specifically, dnf says cannot install both <kernel> and <same-kernel> and offers to reinstall 3.10.0-957.5.1. (I'm currently running 3.10.0-957.10.1 and it still offers the same... But my copy of dnf is very likely ignoring the main sl7 repo, whereas from your question update, I don't think your copy is ignoring the base Centos repo(s). So the commonality is reduced somewhat.
    – Kalvin Lee
    Mar 22 '19 at 13:42
  • For reference, the cannot install both string appears to originate from libdnf (Goal.cpp, ctrl+F "cannot install both")...peeking at the CentOS vault, I think I observe a dnf upgrade in mid-February (need to check my Scientific box - don't have the upgrade history handy). I wonder if that broke something in the dependency resolution?
    – Kalvin Lee
    Mar 22 '19 at 13:44
  • 1
    I'll check later to see if I can roll back dnf - that behavior is probably worth investigating.
    – Kalvin Lee
    Mar 22 '19 at 13:53
  • 1
    I downgraded dnf from 4.0.9 to 2.7.5 by issuing dnf downgrade --allowerasing dnf. This makes both of my problems go away - the sl7 base repo becomes functional and upgrading no longer prints the bizarre complaint about unable to install <kernel> and <same-kernel>. I'll try looking for a mailing list or bug tracker to ask about this.
    – Kalvin Lee
    Mar 23 '19 at 8:32

As far as Sardathrion and I can tell, we're jointly hitting a dnf breakage in the version currently shipped in our respective distributions of EL7. Sardathrion gets a Python traceback while I get a basic_string::_S_construct null not valid, ignoring this repo (which I cannot place in the dnf code). In both cases, we see that dnf confuses itself with the cannot install both <kernel> and <same-kernel> message and does unexpected things.

For my part, my symptoms go away when I downgrade dnf by issuing

dnf downgrade --allowerasing dnf

which lowers dnf from 4.0.9 to 2.7.5 on Scientific Linux 7.6. I see the same SRPMs in the CentOS vault, suggesting CentOS users should be able to do the same.

Since I don't observe any such issue in Fedora 29 shipping dnf 4.1.0, our first line of follow-up should be with our distribution maintainers before we ping the libdnf maintainers.

EDIT: TUV is aware of the issue where dnf offers to reinstall a stale kernel. It doesn't address my disabled sl repo and I don't know if it fixes Sardathrion's big traceback, either.

  • Are you going to report the issue or should I? Mar 25 '19 at 7:54
  • 1
    I'll gather information from my side and send the SL users mailing list a ping. I'll add a comment here if it posts.
    – Kalvin Lee
    Mar 25 '19 at 14:52
  • Thank you very much indeed. Mar 25 '19 at 15:13
  • 2
    Sardathrion, I didn't send an email out, but I did browse the Red Hat bug tracker and found this: bugzilla.redhat.com/show_bug.cgi?id=1668256 - It looks as though upstream is aware of the problem and has a fix coming. I don't see the referenced libsolv RPM in the CentOS or Scientific repos, but it hasn't been all that long. I reckon we can sit tight and wait for an update.
    – Kalvin Lee
    Mar 26 '19 at 4:53
  • I used the maintainer's copr to get the updated libsolv with decent success - it might help you, too, if you're okay with trying it: copr.fedorainfracloud.org/coprs/jmracek/rhel7-libsolv
    – Kalvin Lee
    Mar 26 '19 at 5:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.