dnf upgrade kernel on Centos 7…
1
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
asked Mar 6 at 16:44
SardathrionSardathrion
2,51442349
|
show 3 more comments
1
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
asked Mar 6 at 16:44
SardathrionSardathrion
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 ofdnf repolistand thendnf 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 sayscannot install both <kernel> and <same-kernel>and offers to reinstall3.10.0-957.5.1. (I'm currently running3.10.0-957.10.1and 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 issuingdnf 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 aboutunable 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
1
1
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
asked Mar 6 at 16:44
SardathrionSardathrion
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
centos kernel dnf
asked Mar 6 at 16:44
SardathrionSardathrion
2,51442349
asked Mar 6 at 16:44
SardathrionSardathrion
2,51442349
edited Mar 22 at 8:27
Sardathrion
asked Mar 6 at 16:44
SardathrionSardathrion
2,51442349
asked Mar 6 at 16:44
SardathrionSardathrion
2,51442349
asked Mar 6 at 16:44
SardathrionSardathrion
2,51442349
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 ofdnf repolistand thendnf 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 sayscannot install both <kernel> and <same-kernel>and offers to reinstall3.10.0-957.5.1. (I'm currently running3.10.0-957.10.1and 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 issuingdnf 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 aboutunable 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 ofdnf repolistand thendnf 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 sayscannot install both <kernel> and <same-kernel>and offers to reinstall3.10.0-957.5.1. (I'm currently running3.10.0-957.10.1and 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 issuingdnf 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 aboutunable 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
1
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
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
1
@KalvinLee Question updated. Thank you.
– Sardathrion
Mar 22 at 8:27
@KalvinLee Question updated. Thank you.
– Sardathrion
Mar 22 at 8:27
1
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
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
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
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
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 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
1
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.
answered Mar 23 at 16:51
Kalvin LeeKalvin 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 referencedlibsolvRPM 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');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
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.
answered Mar 23 at 16:51
Kalvin LeeKalvin 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 referencedlibsolvRPM 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 |
1
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.
answered Mar 23 at 16:51
Kalvin LeeKalvin 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 referencedlibsolvRPM 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 |
1
1
1
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.
answered Mar 23 at 16:51
Kalvin LeeKalvin Lee
14228
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.
answered Mar 23 at 16:51
Kalvin LeeKalvin Lee
14228
edited Mar 26 at 5:02
answered Mar 23 at 16:51
Kalvin LeeKalvin Lee
14228
answered Mar 23 at 16:51
Kalvin LeeKalvin Lee
14228
answered Mar 23 at 16:51
Kalvin LeeKalvin Lee
14228
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 referencedlibsolvRPM 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 referencedlibsolvRPM 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
Are you going to report the issue or should I?
– Sardathrion
Mar 25 at 7:54
1
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
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
Thank you very much indeed.
– Sardathrion
Mar 25 at 15:13
1
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
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
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');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 repolistand thendnf 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 reinstall3.10.0-957.5.1. (I'm currently running3.10.0-957.10.1and 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 aboutunable 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