Dnf: Segmentation fault preventing upgrade to Fedora 37

I have had difficulties upgrading to Fedora Linux 37, from the previous version.

I initiated the upgrade operation through the graphical tool, but after the system booted to a blank screen, I rebooted. The result was a failure condition (see below).

I switched to Virtual Terminal 2, entered login credentials, and attempted some commands (see below), based on recommendations found in other troubleshooting discussions.

I have limited experience with RedHat-family operating systems, including tools such as dnf.

Note the segmentation fault relating to upgrading cinnamon-calendar-server for scriptlet firefox.

Please offer any suggestions for repairing the system.


Boot screen…


sudo dnf update


sudo dnf system-upgrade download --releasever=37

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.

2 Likes

Thank you for the detailed reply.

Given my state of knowledge at the moment, though, it is difficult for me to interpret your suggestions, within the context, toward any specific action.

Would you mind offering some concrete suggestions, at the level of granularity of which commands I might enter?

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

Please see screen capture, below.

(You have noticed the ones included in the original post, correct?)


That content of os-release seems to show the system feels it is now at release 37.
Please show the output of uname -r and dnf list installed kernel

You should be able to run any one of
sudo dnf distro-sync, sudo dnf upgrade, sudo dnf reinstall \* or variations there of.
Please let us know exactly what errors you see when doing any of those.

Thank you for the detailed assistance.

Please see below, and advise about further tests or actions.


sudo dnf upgrade

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.

Problem 1

[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.
Installed Packages
gettext-libs.x86_64                                                0.21.1-1.fc37                                                 @updates

Problem 2

[root@eagle jvian]# dnf list libicu
Last metadata expiration check: 0:02:34 ago on Fri 09 Dec 2022 10:03:28 AM CST.
Installed Packages
libicu.i686                                                       71.1-2.fc37                                                     @fedora
libicu.x86_64                                                     71.1-2.fc37                                                     @fedora

Problem 3

[root@eagle jvian]# dnf list libproxy
Last metadata expiration check: 0:03:41 ago on Fri 09 Dec 2022 10:03:28 AM CST.
Installed Packages
libproxy.i686                                                     0.4.18-3.fc37                                                   @fedora
libproxy.x86_64                                                   0.4.18-3.fc37                                                   @fedora

Problem 4

[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.
Installed Packages
libreoffice-core.x86_64                                             1:7.4.3.2-1.fc37                                             @updates

Problem 5

[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.
Installed Packages
llvm-libs.i686                                                    15.0.4-1.fc37                                                  @updates
llvm-libs.x86_64                                                  15.0.4-1.fc37                                                  @updates

Problem 6

[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.
Installed Packages
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 time I add a new package or pattern to the exclude criteria, for upgrade, the process proceeds, but with an error being generated with respect to yet another package.

I am not following much of the rest of the comments, in terms of how to move toward an effective repair.

When specifying package names with wildcard, please put the name in single quote. Thus not

dnf reinstall *

but

dnf reinstall '*'

Right. I understand now.

See below.


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.

I’m not much following the theme of your current suggestions.

I have removed some packages, then tried to reinstall all, but I’m not in any condition particularly better than earlier.


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.

For example,
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.

You can also try upgrading or reinstalling one package at a time. For example remove the libicu fc36 package then dnf upgrade javascriptcoregtk4 --allowerasing --releasever=37 to see the results and errors that may be generated from that one piece.

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.

It would be best, of course, but as noted, my window interface is reduced to an icon of a frowning monitor. I am seeking desperately to move past such an unhappy condition.

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.


dnf upgrade --releasever=37

Various flavors of dnf distro-sync --releasever=37

Various flavors of sudo dnf remove libicu-69.1.6.fc36.x86_64

Various flavors of dnf reinstall \*

…with --skip-broken and --allowerasing.

dnf upgrade javascriptcoregtk4 --allowerasing --releasever=37

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.

  1. Give up on the recovery and do a complete new install
    or
  2. Continue the recovery effort, teaching yourself more about the tools and usage, while dedicating the time and effort to fixing what broke.

So the way to do a routine system upgrade in Fedora is to spend days learning the inner details of the package system to discover why the system failed to resolve packages correctly…?

We still have not explained why dnf produces a segmentation fault.

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!!!