I had a similar error when I upgraded using the dnf system-upgrade method when done in a GUI terminal. It segfaulted somewhere and the next morning although the reboot worked it was stuck between F36 & F37, having never properly completed.
I had to log in to a terminal session (ctrl-alt-F3) then fix the issue. I wound up redoing the system-upgrade download steps with no progress. I then did a dnf upgrade --releasever=37 which gave me an error because of replacing protected packages. dnf distro-sync and dnf distro-sync --releasever=37 both failed with the same messages.
It turned out that the rpm database showed a lot of f37 packages installed alongside the same F36 packages.
The ultimate fix was to manually identify the packages that were related to python and dnf that it refused to upgrade then use rpm -e on the fc36 version of those packages after verifying the fc37 version was already installed to remove the need for them to be updated. Once I fixed the errors about the protected packages then the distro-sync for releasever=37 was able to properly complete and the system was fully updated. I had over 2000 fc36 packages that remained to be removed by the distro-sync at that point.
Lesson Learned !!
Do not do a release version upgrade from within a graphical environment!!
It may fail and leave you in limbo as the graphical packages are upgraded which may cause a crash in the middle of the upgrade.
Just as a side note.
In past versions I never had this problem, but it seems upgrading to version 37 may be more problematic after seeing the number of reported upgrade errors.
Getting more detailed would be slow and require some time since this is actually depending upon your description of what you see, my interpretation of what you describe, and the lag between posts going both directions.
While I would love to give detailed assistance, it really is not feasible unless done in real-time such as with a zoom link using a camera or screen sharing so we can communicate more actively than on this forum. I am open to that for at least part of the day tomorrow if needed.
A starting point would be cat /etc/os-release to see if it ever acknowledged the update.
Follow that with dnf list installed --showduplicates | grep fc36, then possibly repeat that last as dnf list installed --showduplicates | grep fc36 | wc -l to get a count of the remaining fc36 packages involved
For the dnf upgrade
the error was on the cinnamon packages so first do the remaining updates with sudo dnf upgrade --exclude=cinnamon-calendar-server or if that fails sudo dnf upgrade --exclude=cinnamon* so the other packages are updated then work on cinnamon separately. It may even be possible to remove cinnamon-calendar-server then reinstall it
With the distro-sync errors.
I listed the packages for each of the noted problems in these segments below.
In all cases it seems to me the rpm database may be out of sync.
One possible fix would be to do a reinstall of each of the listed packages.
i.e. sudo dnf reinstall gettext-libs for Problem 1 and similar for each of the additional noted Problems.
[root@eagle jvian]# dnf list gettext-libs
Last metadata expiration check: 0:08:12 ago on Fri 09 Dec 2022 10:03:28 AM CST.
gettext-libs.x86_64 0.21.1-1.fc37 @updates
[root@eagle jvian]# dnf list libicu
Last metadata expiration check: 0:02:34 ago on Fri 09 Dec 2022 10:03:28 AM CST.
libicu.i686 71.1-2.fc37 @fedora
libicu.x86_64 71.1-2.fc37 @fedora
[root@eagle jvian]# dnf list libproxy
Last metadata expiration check: 0:03:41 ago on Fri 09 Dec 2022 10:03:28 AM CST.
libproxy.i686 0.4.18-3.fc37 @fedora
libproxy.x86_64 0.4.18-3.fc37 @fedora
[root@eagle jvian]# dnf list libreoffice-core
Last metadata expiration check: 0:05:07 ago on Fri 09 Dec 2022 10:03:28 AM CST.
libreoffice-core.x86_64 1:22.214.171.124-1.fc37 @updates
[root@eagle jvian]# dnf list llvm-libs
Last metadata expiration check: 0:05:40 ago on Fri 09 Dec 2022 10:03:28 AM CST.
llvm-libs.i686 15.0.4-1.fc37 @updates
llvm-libs.x86_64 15.0.4-1.fc37 @updates
[root@eagle jvian]# dnf list qemu-common
Last metadata expiration check: 0:06:13 ago on Fri 09 Dec 2022 10:03:28 AM CST.
qemu-common.x86_64 2:7.0.0-11.fc37 @updates
You could run the same dnf list installed commands for each of those packages and see what your system tells you before doing anything else.
For the reinstall
I made an error in the reinstall command. It should have been sudo dnf reinstall \* or sudo dnf reinstall '*' so dnf saw the * instead of the current directory content. I fixed that in the post above.
Each of those that shows a conflict with an fc36 and an fc37 package will require that you manually remove the conflict by removing the fc36 package.
For example, with problem 10 above you would need to do either dnf remove llvm-libs-14.0.5-1.fc36.x86_64 or if that does not work then rpm -e llvm-libs-14.0.5-1.fc36.x86_64
With problem 9 it would be dnf remove llibicu-69.1-6.fc36.x86_64 or if that does not work then rpm -e libicu-69.1-6.fc36.x86_64
The same pattern would be used for each conflict. Note that the dnf command should ensure that dependencies are managed while the rpm command does not manage all the dependencies the same.
Pay attention to each listed conflict and you should see that it is remaining fc36 packages that conflict with already installed fc37 packages since the cleanup and removal of old packages apparently did not properly complete during the system upgrade.
Have you been able to run either dnf upgrade --releasever=37 or dnf distro-sync --releasever=37 after removing those packages with conflicts?
Working with the errors from the upgrade will be more beneficial than just the reinstall. You also have to work backwards to determine which other packages are trying to pull back in those fc36 packages you just removed.
I cannot see the screen, nor sit there and know exactly what has already been done or not done. A full, step by step, description of what you have done, what the results were, for each step, etc. and stopping and fixing errors one at a time works best.
Did you do the dnf remove libicu-69.1-6.fc36.x86_64 as I suggested?
Were there errors or did it succeed?
Did you try adding the --allowerasing option that was suggested in one of your previous posts?
Did you try fixing one problem at a time or are you still trying a blanket ‘fix it all’ shotgun approach?
If you break things down and analyze what you are seeing while fixing one thing at a time it becomes much simpler.
This is like the question How do you eat an elephant? Answer: One bite at a time.
The dnf reinstall \* command may not be the best since there still seem to be a lot of fc36 packages that conflict. The dnf distro-sync --allowerasing or dnf upgrade --allowerasing --best may be a better option. Work on each package and error reported one at a time.
It would be best if you could boot then as you run the commands give us a text output of the results. Screen images make it difficult to answer since responses require copying the text from the image and are subject to errors while copy & paste of text simplifies the process.
Screen images make it difficult to answer since responses require copying the text from the image and are subject to errors while copy & paste of text simplifies the process.
In addition, content pasted as text can be indexed and found by others with similar problems. This can be helpful in finding the root cause of aa problem as well helping the next person who encounters it.
I understand, but the format of your suggestions has not been supportive of my following a sequence of steps and reporting results.
It is not easy, doing as you ask, with only a text console. I have no scrolling or capture. It might be helpful if I were able to run screen, but alas, attempts to install it have failed.
I had taken each broken packages reported by dnf reinstall \*, and applied to each one dnf remove. In many cases, the operation was successful. I then tried reinstall, as before, which installed many new packages. However, the operation ultimately failed. See below for the new results.
I have tried it many combinations, and you can see some results below.
I am open to either, but I am only able to describe one problem, that of the system not booting. Of course, it is the job of a package manager to resolve all operations through a single command. In the current case, it has not worked, and so I have sought help in the forum. I have no idea how to identify the particular problems internal to the package system.
As I originally have stated, I have extremely limited experience with RedHat-family operating systems and their tools.
It’s a great idea. Perhaps you could help me understand what I am seeing. All I know is I tried a “routine” system upgrade and was dropped into hell.
I have no idea what the various messages are indicating.
I had given you an alternative to that command if it failed. sudo rpm -e libicu-69.1-6.fc36.x86_64 which should work since it does less dependency checking.
If you read back through my suggestions there are several with details as to how to analyze the errors and tackle the problems one at a time.
One further suggestion is to run the sudo dnf distro-sync --allowerasing command then capture the noted fc36 packages which indicate a conflict. Remove those packages one at a time making sure you use the full package name, including verifying that it is the fc36 version of that package.
Use the sudo rpm -e <package name> version of the removal command and after removing each retry the distro-sync noted just above to see if there are changes in the errors.
Work through that sequence one package at a time until you have removed all the errors about protected packages. After that distro-sync should work for the remainder of the clean up.
Note that dnf will never remove a package that it thinks is protected even if it is the wrong version. rpm does not have the same restriction, and you are removing the conflicting fc36 versions of those packages.
Your choice at this point seems simple.
Give up on the recovery and do a complete new install
Continue the recovery effort, teaching yourself more about the tools and usage, while dedicating the time and effort to fixing what broke.
Not what was said. This is recovery from a problem, not a routine upgrade.
Fixing any problem is done one step at a time. You can do it the easy and (almost) painless way by a reinstall or you can actually learn something instead of having your hand held and being guided one step at a time through the process. Most of us learn best by doing.
Explaining a seg fault is impossible without the data logged (or not logged) at the time it occurs, and sometimes not even then. A corrupt package which causes an invalid cpu command can cause a seg fault, as can many other circumstances. It is obvious the upgrade failed and impossible to know what the cause was or why. Fixing the problem is better than sitting and wondering WHY!!!