Greetings
I am getting kernel panics after recent updates. Strangely, lots of things are also broken (e.g. Python 3.12 getting mixed up with 3.11, virtual environments, etc.). I suspect the update did not conclude properly because dnf5 tends to stop midway when it encounters an issue.
So, I ran a "dnf check".
What do you know? "check" command appears to be absent in dnf5. I think my local repo (RPMs) are in a bad state. I am running Rawhide.
Any ideas?
Regards Onyeibo
On Mon, 24 Jul 2023 08:54:56 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
Greetings
I am getting kernel panics after recent updates. Strangely, lots of things are also broken (e.g. Python 3.12 getting mixed up with 3.11, virtual environments, etc.). I suspect the update did not conclude properly because dnf5 tends to stop midway when it encounters an issue.
So, I ran a "dnf check".
What do you know? "check" command appears to be absent in dnf5. I think my local repo (RPMs) are in a bad state. I am running Rawhide.
Any ideas?
You are experiencing the hiccups that rawhide experiences when major changes are introduced. If you wait for a period of time, the packagers will probably resolve most of these, so it will be easier to put your system back in a coherent state. Not always feasible, so ...
I am not familiar with dnf5, so I don't know if any of the below is applicable, because I have seen comments suggesting that the options available are not the same as for dnf 3/4.
First, try just restarting dnf as usual, using -x to exclude the problematic package on the command line. It used to pick up where it left off in that case. dnf -x [problem package, possibly with * for glob] update You might have to add -x for subsequent problem packages until update completes. An alternative is --skip-broken, but it isn't exactly the same, so I prefer the -x technique because it removes the package from consideration before the calculation of whether it is broken or not.
Then I would run a dnf --distro-sync to ensure that everything is at the latest available version and remove all the older versions. The first command should leave the system in a state that this is redundant, if it succeeds, but belt and suspenders.
If the rpm database needs fixing, rpm --rebuilddb to put it back in sync with what is installed.
On Mon, 24 Jul 2023 08:17:27 -0700 stan via test test@lists.fedoraproject.org wrote:
On Mon, 24 Jul 2023 08:54:56 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
Any ideas?
Then I would run a dnf --distro-sync to ensure that everything is at the latest available version and remove all the older versions.
dnf distro-sync Updating and loading repositories: Fedora - Rawhide - Developmental packages for the next Fedora release 100% | 22.3 KiB/s | 42.3 KiB | 00m02s Repositories loaded. Problem 1: cannot install both python3-3.11.3-2.fc39.x86_64 and python3-3.12.0~b4-1.fc39.x86_64 - cannot install the best update candidate for package python3.11-3.11.4-2.fc39.x86_64 - cannot install the best update candidate for package python3-3.12.0~b4-1.fc39.x86_64 Problem 2: cannot install both python3-libs-3.11.3-2.fc39.x86_64 and python3-libs-3.12.0~b4-1.fc39.x86_64 - cannot install the best update candidate for package python3.11-libs-3.11.4-2.fc39.x86_64 - cannot install the best update candidate for package python3-libs-3.12.0~b4-1.fc39.x86_64 Problem 3: cannot install both python3-tkinter-3.11.3-2.fc39.x86_64 and python3-tkinter-3.12.0~b4-1.fc39.x86_64 - cannot install the best update candidate for package python3.11-tkinter-3.11.4-2.fc39.x86_64 - cannot install the best update candidate for package python3-tkinter-3.12.0~b4-1.fc39.x86_64
Apart from the Kernel Panics,. it appears something went wrong while updating Python.
On Tue, 25 Jul 2023 17:59:46 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
On Mon, 24 Jul 2023 08:17:27 -0700 stan via test test@lists.fedoraproject.org wrote:
On Mon, 24 Jul 2023 08:54:56 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
Any ideas?
Then I would run a dnf --distro-sync to ensure that everything is at the latest available version and remove all the older versions.
Apart from the Kernel Panics,. it appears something went wrong while updating Python.
dnf ls --installed | grep python3
tells me I have the recent Python3 (and Python3-libs, Python3-tkinter) with copies of py3.11 (as Python3.11-libs, Python3.11-tkinter etc) on the list. This should be fine since the packages bear different names
However, when I run: dnf update
I get conflicts as exemplified in my previous reply. The update path goes on to involve python3.11-libs when it should not. Somehow python3, python3-libs, and python3-tkinter picks up both 3.12 and 3.11 while processing the update. The two packages share something in common and dnf is confused.
I can remove the older Python via: dnf remove python3.11-libs
It pulls sudo-python-plugin and python-setuptools-wheel for removal as well. How safe is that?
Regards Onyeibo
Apologies for the late reply. Not sure how helpful my response will be since I haven't direct experience of the issue, like you do.
On Tue, 25 Jul 2023 18:20:25 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
On Tue, 25 Jul 2023 17:59:46 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
On Mon, 24 Jul 2023 08:17:27 -0700 stan via test test@lists.fedoraproject.org wrote:
On Mon, 24 Jul 2023 08:54:56 +0100 Onyeibo Oku onyeibo@schemefusion.com wrote:
Any ideas?
Then I would run a dnf --distro-sync to ensure that everything is at the latest available version and remove all the older versions.
Apart from the Kernel Panics,. it appears something went wrong while updating Python.
dnf ls --installed | grep python3
tells me I have the recent Python3 (and Python3-libs, Python3-tkinter) with copies of py3.11 (as Python3.11-libs, Python3.11-tkinter etc) on the list. This should be fine since the packages bear different names
However, when I run: dnf update
I get conflicts as exemplified in my previous reply. The update path goes on to involve python3.11-libs when it should not. Somehow python3, python3-libs, and python3-tkinter picks up both 3.12 and 3.11 while processing the update. The two packages share something in common and dnf is confused.
I think python3.12 should have removed python3.11, but there are packages that haven't been converted to run with python3.12 still in rawhide, and so it wouldn't allow the removal of python3.11 until those are replaced with a package depending on python3.12 instead. I don't think that it is so much that they share things in common as that they conflict with each other because both are being required by a certain set of packages.
I can remove the older Python via: dnf remove python3.11-libs
It pulls sudo-python-plugin and python-setuptools-wheel for removal as well. How safe is that?
As I understand it, python-setuptools-wheel has become obsolete as of python3.12. But, I am surprised that it would only remove three packages after the conflicts from your other post. If that is in fact the case, if it was my system, I would do the removal. If the two packages pulled in are vital for python3.12, they will have python3.12 versions that you can install *after* removing python3.11. I don't know enough about the python3.11 and python3.12 ABI differences to guarantee that doing that is safe, though, for other packages. Theoretically, if dnf didn't flag a conflict, it is safe. But dnf5 is new, so there might be some rough edges and corner cases. As I said above, I would still do the removal of python3.11, since python3.12 is the default python3 for rawhide / f39. If you absolutely need python3.11 later, this will all probably have been ironed out in the meantime, and it will work properly. This also applies if the set of packages that would be removed with python3.11 is small. You could remove them to fix the python3 11/12 conflict, and then reinstall them later when they have been converted to use python3.12.
I wonder if there is a file that determines which python3 version is the default, and there are two versions of it, so both 11 and 12 are considered default?
You should open a bugzilla at https://bugzilla.redhat.com/ against either sudo-python-plugin or python-setuptool-wheel, and put the information from your other post in it so that the developers are aware of this problem. Maybe direct the error output of dnf5 into a log file that you can attach. That will help get it fixed.
Finally, making python3 unusable will render your system unusable (I think). So, back up anything vital, and have some fallback scheme for recovery, like another working install that you can use to fix rawhide if it becomes unusable.
-
Onyeibo Oku -
stan