dnf upgrade kernel on Centos 7…

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

================================================================================

Reinstalling:

 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

    base.do_transaction(display=displays)

  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

    self._verify_transaction(cb.verify_tsi_package)

  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

    bool(return_code)

  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

and

; dnf repolist -v | grep "^Repo-filename" | awk '{print $2}' | sort ; ls /etc/yum.repos.d

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/epel.repo

/etc/yum.repos.d/ius.repo

/etc/yum.repos.d/slack.repo

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

edited Mar 22 at 8:27

asked Mar 6 at 16:44

Sardathrion

2,51442349

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 at 5:20

1

@KalvinLee Question updated. Thank you.

– Sardathrion
Mar 22 at 8:27

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 at 13:42

1

I'll check later to see if I can roll back dnf - that behavior is probably worth investigating.

– Kalvin Lee
Mar 22 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 at 8:32

|
show 3 more comments

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

================================================================================

Reinstalling:

 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

    base.do_transaction(display=displays)

  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

    self._verify_transaction(cb.verify_tsi_package)

  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

    bool(return_code)

  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

and

; dnf repolist -v | grep "^Repo-filename" | awk '{print $2}' | sort ; ls /etc/yum.repos.d

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/epel.repo

/etc/yum.repos.d/ius.repo

/etc/yum.repos.d/slack.repo

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

edited Mar 22 at 8:27

asked Mar 6 at 16:44

Sardathrion

2,51442349

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 at 5:20

1

@KalvinLee Question updated. Thank you.

– Sardathrion
Mar 22 at 8:27

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 at 13:42

1

I'll check later to see if I can roll back dnf - that behavior is probably worth investigating.

– Kalvin Lee
Mar 22 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 at 8:32

|
show 3 more comments

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

================================================================================

Reinstalling:

 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

    base.do_transaction(display=displays)

  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

    self._verify_transaction(cb.verify_tsi_package)

  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

    bool(return_code)

  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

and

; dnf repolist -v | grep "^Repo-filename" | awk '{print $2}' | sort ; ls /etc/yum.repos.d

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/epel.repo

/etc/yum.repos.d/ius.repo

/etc/yum.repos.d/slack.repo

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

edited Mar 22 at 8:27

asked Mar 6 at 16:44

Sardathrion

2,51442349

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

================================================================================

Reinstalling:

 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

    base.do_transaction(display=displays)

  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

    self._verify_transaction(cb.verify_tsi_package)

  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

    bool(return_code)

  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

and

; dnf repolist -v | grep "^Repo-filename" | awk '{print $2}' | sort ; ls /etc/yum.repos.d

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/CentOS-Base.repo

/etc/yum.repos.d/epel.repo

/etc/yum.repos.d/ius.repo

/etc/yum.repos.d/slack.repo

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

centos kernel dnf

edited Mar 22 at 8:27

asked Mar 6 at 16:44

Sardathrion

2,51442349

edited Mar 22 at 8:27

asked Mar 6 at 16:44

Sardathrion

2,51442349

edited Mar 22 at 8:27

asked Mar 6 at 16:44

Sardathrion

2,51442349

asked Mar 6 at 16:44

Sardathrion

2,51442349

asked Mar 6 at 16:44

Sardathrion

2,51442349

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 at 5:20

1

@KalvinLee Question updated. Thank you.

– Sardathrion
Mar 22 at 8:27

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 at 13:42

1

I'll check later to see if I can roll back dnf - that behavior is probably worth investigating.

– Kalvin Lee
Mar 22 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 at 8:32

|
show 3 more comments

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 at 5:20

1

@KalvinLee Question updated. Thank you.

– Sardathrion
Mar 22 at 8:27

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 at 13:42

1

I'll check later to see if I can roll back dnf - that behavior is probably worth investigating.

– Kalvin Lee
Mar 22 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 at 8:32

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 at 5:20

@KalvinLee Question updated. Thank you.

– Sardathrion
Mar 22 at 8:27

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 at 13:42

I'll check later to see if I can roll back dnf - that behavior is probably worth investigating.

– Kalvin Lee
Mar 22 at 13:53

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 at 8:32

|
show 3 more comments

1 Answer
1

active

oldest

votes

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.

edited Mar 26 at 5:02

answered Mar 23 at 16:51

Kalvin Lee

14228

Are you going to report the issue or should I?

– Sardathrion
Mar 25 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 at 14:52

Thank you very much indeed.

– Sardathrion
Mar 25 at 15:13

1

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 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 at 5:00

add a comment |

Your Answer

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504765%2fdnf-upgrade-kernel-on-centos-7%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

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.

edited Mar 26 at 5:02

answered Mar 23 at 16:51

Kalvin Lee

14228

Are you going to report the issue or should I?

– Sardathrion
Mar 25 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 at 14:52

Thank you very much indeed.

– Sardathrion
Mar 25 at 15:13

1

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 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 at 5:00

add a comment |

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.

edited Mar 26 at 5:02

answered Mar 23 at 16:51

Kalvin Lee

14228

Are you going to report the issue or should I?

– Sardathrion
Mar 25 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 at 14:52

Thank you very much indeed.

– Sardathrion
Mar 25 at 15:13

1

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 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 at 5:00

add a comment |

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.

edited Mar 26 at 5:02

answered Mar 23 at 16:51

Kalvin Lee

14228

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.

edited Mar 26 at 5:02

answered Mar 23 at 16:51

Kalvin Lee

14228

edited Mar 26 at 5:02

answered Mar 23 at 16:51

Kalvin Lee

14228

answered Mar 23 at 16:51

Kalvin Lee

14228

answered Mar 23 at 16:51

Kalvin Lee

14228

Are you going to report the issue or should I?

– Sardathrion
Mar 25 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 at 14:52

Thank you very much indeed.

– Sardathrion
Mar 25 at 15:13

1

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 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 at 5:00

add a comment |

Are you going to report the issue or should I?

– Sardathrion
Mar 25 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 at 14:52

Thank you very much indeed.

– Sardathrion
Mar 25 at 15:13

1

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 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 at 5:00

Are you going to report the issue or should I?

– Sardathrion
Mar 25 at 7:54

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 at 14:52

Thank you very much indeed.

– Sardathrion
Mar 25 at 15:13

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 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 at 5:00

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Unix & Linux Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

c8I8vZRbys

搜尋此網誌

Ytdyklly