How to fix dnf autoremove attempting to remove many essential packages after upgrade to 38?


I recently upgraded to Fedora 38 from 36.

After installation, I looked at the output from dnf autoremove. To my surprise, it suggested 191 packages were to be removed - including ones that appear very fundamental to the functioning of the system (acl, initscripts, gettext, …). All of the packages are listed with a “.fc38” version as well - and when I checked I did not found more than one version of the same packaged installed either.

How can I fix this, so that this won’t cause problems at some later point? (I presume those packages aren’t safe to be removed?)

Thank you.

1 Like

To exclude packages from autoremove, mark them as manually installed:

sudo dnf mark install pkg1 pkg2 ...

Note that the mentioned packages are not necessarily essential as DNF provides an additional protection against removing actually essential packages.

1 Like

Hi Gottfried,

It’ll help to see the list of packages. Run the following command to upload it to the Fedora pastebin:

dnf -qC list --autoremove | fpaste

then reply with the URL.

Are you using Fedora Workstation or another edition/spin?

FWIW, initscripts is probably not used by most Fedora users (it’s for System V init scripts, while Fedora uses systemd), and gettext is needed for developing translations, not using them. acl should be installed though, it’s part of Workstation group.

1 Like


Hello Justin. Thank you for looking into this - I appreciate your time.

Here is the output of the command: UNTITLED - Pastebin Service
According to /etc/os-release I am running the Cloud edition. This is on a DigitalOcean droplet, so this would make sense also.

I am tempted to suggest you run sudo dnf mark install \* that that should mark all packages as “user installed” and therefore autoremove won’t remove them. For any future installed packages autoremove would then work correctly.

I find that installing python3-dnf-plugin-show-leaves can be very useful, as it will show you which packages may no longer be needed when removing a package. You then have to decide which packages are really no longer required.

Does anyone know if Packagekit is now properly marking user installed packages as “user installed” and therefore not to be removed by autoremove?

So it’s a server (no GUI)? Many of these packages are desktop-related (video/audio stack, fonts, flatpak etc), seems strange they are installed in the first place.

A few are expected autoremoves. systemd-boot-unsigned and grub2-tools-* had recent packaging changes and are not required AFAIK.

1 Like

I’m curious to see the transaction history of one of the packages that isn’t part of cloud or core/standard groups. Let’s say sound-theme-freedesktop, since it never receives updates, the only transactions should be whatever caused it to be installed, and the upgrade from F36 to F38:

dnf history info sound-theme-freedesktop | fpaste

Maybe you installed a package with all these desktop-related dependencies at one point. Not sure why they’d be leaves (orphans) now though.

1 Like

Maybe it is a leaf, or maybe not. Perhaps it will become a leaf when some of the other packages are removed.

If you install python3-dnf-plugin-leaves-4.4.1-1.fc38.noarch and python3-dnf-plugin-show-leaves-4.4.1-1.fc38.noarch you can run the command dnf leaves
to get a list of leaf packages.

Whether a packages may be autoremoved depends on how it was installed. If it was installed like dnf install sound-theme-freedesktop, then it will not be autoremoved. If it was installed as a dependency, then it can be autoremoved.

1 Like

Yes I understand. What I’m saying is:

  • Some package foo was installed at some point with all these desktop/GUI dependencies.
  • Either foo was removed, then why were the deps not autoremoved?
  • Or foo is still present, but the dependencies changed (almost absurdly) between F36 and F38?

sound-theme-freedesktop is just an example of one of these dependencies, I picked it because it’s very unlikely anyone installs it explicitly, and it has no updates. So maybe we can find out what foo is or what happened to it.


If you run this command, you will see what packages needs to be removed before sound-theme-freedesktop becomes a leaf package. It was probably originally installed when building the live system.

[root@newbox ~]# dnf remove sound-theme-freedesktop
Dependencies resolved
 Package                                       Architecture         Version                          Repository              Size
 sound-theme-freedesktop                       noarch               0.8-19.fc38                      @fedora                460 k
Removing dependent packages:
 claws-mail-plugins-notification               x86_64               4.1.1-6.fc38                     @updates               165 k
 libcanberra-gtk3                              x86_64               0.30-31.fc38                     @fedora                 71 k
 onboard                                       x86_64               1.4.1-29.fc38                    @fedora                4.1 M
 onboard-data                                  noarch               1.4.1-29.fc38                    @fedora                 21 M
 pavucontrol                                   x86_64               5.0-8.fc38                       @fedora                1.0 M
 system-config-printer                         x86_64               1.5.18-3.fc38                    @fedora                1.8 M
 vim-X11                                       x86_64               2:9.0.1587-1.fc38                @updates               4.3 M
 xfce4-pulseaudio-plugin                       x86_64               0.4.6-1.fc38                     @fedora                473 k
Removing unused dependencies:
 keybinder3                                    x86_64               0.3.2-15.fc38                    @fedora                 32 k
 libcanberra                                   x86_64               0.30-31.fc38                     @fedora                274 k
 xfce4-notifyd                                 x86_64               0.8.2-1.fc38                     @fedora                878 k

Transaction Summary
Remove  12 Packages

Freed space: 34 M
Is this ok [y/N]: n
Operation aborted.
[root@newbox ~]# 
1 Like

Thank you @jn64 and @vekruse for helping me with this!

It is a server, and I never had X running on it. If I understand the output of dnf history right, then sound-theme-freedesktop was initially installed with ImageMagic. (Here is the pastebin.) That sounds about right… I did install it at some point, and it pulling in way too many dependencies sounds familiar. Perhaps a more recent package got rid of those dependencies? (I see imagemagic still installed at this point.)

So maybe that’s correct - but what about acl? Is there a way of figuring out what package/dependency I am missing that makes it (and possibly other essential ones) look ripe for autoremove?

1 Like
  • ImageMagick was installed in F34, bringing in a bunch of dependencies (fonts, gtk3, sounds). Slightly heavy but seems normal.
  • During system-upgrade from F34 to F36, many more desktop dependencies were installed (video/audio stack, flatpak, some GNOME components, Bluetooth). Not sure why, but this is the root of the problem. Maybe it was something in the dependency chain of ImageMagick, maybe something else entirely.
  • system-upgrade from F36 to F38 seems normal. Whatever was the problem in F36 was fixed between F36 and F38, but system-upgrade doesn’t autoremove, so here we are.

Edit: removed instructions because they were based on wrong assumptions. See next post.

1 Like

Oh I see now. standard group is an optional dep of Fedora Cloud Server group. My mistake assuming it’s a required group like on Workstation.

So, if you want acl, you can dnf mark install it before the autoremove, or install it yourself afterwards. Or, you can group install the standard group if you want everything else in it (it’s all CLI stuff, but more desktop-oriented).

To see the other optional groups in Cloud:

dnf group info 'Fedora Cloud Server'

You can install a group with all optional groups, but that’s probably not what you want here:

dnf group install --with-optional <group>...
1 Like

I have a clean install of F38 Workstation and I see this related to that package.

# dnf list sound-theme-freedesktop
Last metadata expiration check: 4:35:46 ago on Sat 03 Jun 2023 05:01:24 AM CDT.
Installed Packages
sound-theme-freedesktop.noarch                                             0.8-19.fc38                                             @anaconda

It seems that the installer actually installs that package on a clean install and it is thus not a residual from an earlier install

You’re using Workstation. This is not relevant to Cloud. The logs provided above also disprove this.

I ended up making a snapshot of the instance before trying to run autoremove (since it now looked like everything was in good order, and “acl” optional anyway). Unfortunately the instance did not come up after rebooting (no ping), so it seems like something wasn’t that optional… :frowning:

I might go ahead and ultimately mark all packages as “user installed”, since I just don’t know which are safe to delete.

Hm. Did you reinstall all installed groups after autoremove?

I didn’t, but I just tried again with pinning these packages before the autoremove - and this time it survived the reboot.

NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown grub2-tools-efi grub2-tools-extra initscripts initscripts-rename-device systemd-boot-unsigned systemd-rpm-macros

Unsure which of those is ultimately needed. At least all my services started up fine, so I guess that’s good enough for me. Thank you very much @jn64 for your time.


Strange, but I’d also call it good enough :smiley:

1 Like

NetworkManager-initscripts-ifcfg-rh is needed if you are using the old style configuration files for NetworkManager. These old style scripts are found in /etc/sysconfig/network-scripts.

1 Like