Use of dnf autoremove

@augenauf I disagree a bit with the autoremove argument. It is for good reasons suggested in the upgrade process even in our docs, although normally after the upgrade. It definitely makes sense to check the packages before remove, but it does not tend to kill the system.

2 Likes

autoremove has never worked reliably on dnf / Fedora.

1 Like

Sorry, my argument was written in “German” English. I meant that he should not do it if he is unsure. Just corrected that.

However, if you have any indication that there is an issue with the autoremove, I suggeset to become active and start a discussion about our docs.

1 Like

You name it, the docs describe removal after the upgrade process, not before.
Nonetheless, I would say it’s a lie whatever is written in the Docs. ( "You can safely remove packages no longer in use with"… let’s get those Docs fixed.

On my system it would want to remove grub, kernel, linux-utils, linux-firmware, and gnome-shell… :innocent:

FYI, I have split the topic in order not to clutter the dnf upgrade package conflict topic.

So, here and now, only autoremove

I see the Warning in the Docs about removing and autoremoving. That should maybe be more present. Or we remove the hint about autoremove. You’re not gonna gain anything with that command, maybe except 100 megs of space and a lot trouble fixing missing dependencies or bootloaders

I have not checked any package, but at first glance, in grass list I don’t see anything system critical. I saw that a lot libvirt and qemu packages are removed. But for good reasons: he has nothing installed that makes use of these technologies (otherwise, these packages would have been in the list due to dependency). But if he has something dependent in place not managed by dnf/rpm: this is why to check the list before proceed autoremove. If I do it on my system, there is nothing critical inside, and as I do it after upgrades, my list is comparably short. As mentioned, if he is unsure, don’t. We already solved the original issue.

However, if you have such issues with it, I indeed suggest to start a discussion on discussion.fedora

For me this argument is new.

Supplement for the split topic: the list of @grass I refer to is the following:
https://discussion.fedoraproject.org/t/unable-to-upgrade-to-fedora-35-from-fedora-34/19958/5

@augenauf it is post 5, not 4 :wink:

1 Like

I therefore split the topic.

reference to the list, so everybody knows what @py0xc3 is referring to:

https://discussion.fedoraproject.org/t/unable-to-upgrade-to-fedora-35-from-fedora-34/19958/4

1 Like

Related, past discussion are here:

It would be interesting to know if others have the same issue. kernel removal in dnf autoremove should be impossible (I have never seen that before). Autoremove is intended to not touch protected packages and such.

Maybe we have here not just a question of how to change the docs but also about forwarding this as a (indeed dangerous) bug.

In my experience, and I assume this is what the docs are referring to in the contained warning, a problem rises only if I have something in place that is not managed by dnf/rpm but that has dependencies in dnf/rpm, while the dependency was not intentionally installed by the user. Looking forward to other experiences. I’m curious now :slight_smile:

Additional question: @augenauf ain’t this more a topic for discussions.fedora rather than ask.fedora?

Discussions.:fedora: thread: The use and recommendation (in the docs) of dnf autoremove

2 Likes

Not true. I am using several VMs that use qemu yet the autoremove would remove that whole list of qemu packages. Also virt packages the same.

Interesting. For me it is true. It never removed my qemu or libvirt packages, or anything else I needed, just obsolete packages were removed. I use qemu/kvm with virt-manager & the libvirt tools for long. Just tested autoremove, nothing of it is in the list. Seems indeed a bit arbitrary…

I just sent @grass a message to check out if he uses vm’s with qemu, just to see whether his autoremove list can make sense or not. But given the content of the list, it makes sense to me (no frontend is included that is dependent on qemu), making me assume qemu/libvirt used to be a dependency of something that is no longer there (I admit, this contains the assumption he does not use qemu natively on itself). The question for me is if he intentionally and explicitly installed these packages. Let’s see.

Hrm, really? I always only see leaf packages. For example, at the moment:

sudo dnf autoremove
Dependencies resolved.
========================================================================================================================================
 Package                                           Architecture        Version                      Repository                     Size
========================================================================================================================================
Removing:
 annobin-plugin-clang                              x86_64              9.87-3.fc35                  @updates                      125 k
 julietaula-montserrat-base-web-fonts              noarch              1:7.210-5.fc35               @fedora                       971 k
 julietaula-montserrat-fonts-common                noarch              1:7.210-5.fc35               @fedora                       7.3 k
 libpmemobj                                        x86_64              1.11.0-3.fc35                @fedora                       380 k
 ptex-libs                                         x86_64              2.4.0-2.fc35                 @fedora                       515 k
 usd-libs                                          x86_64              21.11-4.fc35                 @updates-testing               30 M

Transaction Summary
========================================================================================================================================
Remove  6 Packages

The man page says:

       dnf [options] autoremove
          Removes all "leaf" packages from the system that were originally installed as dependencies of user-installed packages, but
          which are no longer required by any such package.

       Packages listed in installonlypkgs are never automatically removed by this command.

so it’s probably a bug that grub etc. are being listed, no?

Is it possible that your qemu/libvirt packages were originally installed as dependency of something else? Something that is no longer there? You can fix this with dnf mark, with which you can mark a package as user installed. If the latter is already the case, this would imply a bug that should be filed.

I suggest to file a bug at the bugzilla. This is definitely not intended. What I could find at first glance was:
https://bugzilla.redhat.com/show_bug.cgi?id=1921063
https://bugzilla.redhat.com/show_bug.cgi?id=1962056
But both are closed.

2 Likes

The autoremove list generated on @grass machine makes sense. He does not use qemu/libvirt.

1 Like

Sorry for the delay answering, here is the output of dnf autoremove from my F35 laptop. When I am back home tonight, I’ll post the output from my workstation

<- click on arrow to see output of dnf autoremove
Last metadata expiration check: 0:01:38 ago on Mon 07 Feb 2022 09:38:34 AM CET.
Dependencies resolved.
================================================================================
 Package                              Arch   Version             Repo      Size
================================================================================
Removing:
 at                                   x86_64 3.2.2-2.fc35        @fedora  124 k
 chkconfig                            x86_64 1.19-1.fc35         @fedora  763 k
 compat-readline5                     x86_64 5.2-40.fc35         @fedora  380 k
 cronie                               x86_64 1.5.7-3.fc35        @fedora  294 k
 cronie-anacron                       x86_64 1.5.7-3.fc35        @fedora   46 k
 crontabs                             noarch 1.11-25.20190603git.fc35
                                                                 @fedora   21 k
 ed                                   x86_64 1.14.2-11.fc35      @fedora  127 k
 esmtp                                x86_64 1.2-18.fc35         @fedora   99 k
 f34-backgrounds-base                 noarch 34.0.1-2.fc35       @fedora   23 M
 f34-backgrounds-gnome                noarch 34.0.1-2.fc35       @fedora  925  
 glibc-doc                            noarch 2.34-25.fc35        @updates 1.1 M
 gperftools-libs                      x86_64 2.9.1-2.fc35        @fedora  1.4 M
 grub2-tools-efi                      x86_64 1:2.06-10.fc35      @updates 2.7 M
 grub2-tools-extra                    x86_64 1:2.06-10.fc35      @updates 5.3 M
 guile                                x86_64 5:2.0.14-25.fc35    @fedora   12 M
 info                                 x86_64 6.8-2.fc35          @fedora  492 k
 initscripts                          x86_64 10.14-1.fc35        @updates 1.1 M
 julietaula-montserrat-base-web-fonts noarch 1:7.210-5.fc35      @fedora  971 k
 julietaula-montserrat-fonts-common   noarch 1:7.210-5.fc35      @fedora  7.3 k
 libesmtp                             x86_64 1.0.6-22.fc35       @fedora  181 k
 liblockfile                          x86_64 1.17-1.fc35         @updates  56 k
 libmms                               x86_64 0.6.4-16.fc35       @rpmfusion-free
                                                                          112 k
 libmusicbrainz5                      x86_64 5.1.0-18.fc35       @fedora  598 k
 libpmemobj                           x86_64 1.11.0-3.fc35       @fedora  380 k
 libqrcodegencpp                      x86_64 1.7.0-2.fc35        @fedora   68 k
 libsss_autofs                        x86_64 2.6.3-1.fc35        @updates  62 k
 mailx                                x86_64 12.5-38.fc35        @fedora  495 k
 ncurses-compat-libs                  x86_64 6.2-8.20210508.fc35 @fedora  1.0 M
 ntfs-3g                              x86_64 2:2021.8.22-2.fc35  @fedora  329 k
 ntfs-3g-system-compression           x86_64 1.0-7.fc35          @fedora   44 k
 patch                                x86_64 2.7.6-15.fc35       @fedora  259 k
 python3-pip                          noarch 21.2.3-4.fc35       @updates 9.0 M
 python3-slip                         noarch 0.6.4-25.fc35       @fedora   60 k
 python3-slip-dbus                    noarch 0.6.4-25.fc35       @fedora   70 k
 redhat-lsb-core                      x86_64 4.1-55.fc35         @fedora   39 k
 redhat-lsb-submod-security           x86_64 4.1-55.fc35         @fedora    0  
 spax                                 x86_64 1.6-5.fc35          @fedora  414 k
 systemd-rpm-macros                   noarch 249.9-1.fc35        @updates 9.8 k
 util-linux-user                      x86_64 2.37.3-1.fc35       @updates  60 k

Transaction Summary
================================================================================
Remove  39 Packages

Freed space: 63 M
Is this ok [Y/n]: n
Operation aborted.

There are probably a few “leaf” packages, but certainly packages that I don’t want dnf to remove (python3-pip, ntfs-3g, redhat-lsb-core, grub2*, not sure about util-linux-user, I guess that has been replaced by util-linux)

1 Like

No worries, I was also off… but now FOSDEM is over :frowning:

I have also python3-pip installed but it is not in the list of dnf autoremove. But I am quite sure that I installed it myself intentionally. Was it maybe installed on your machine as a dependency of something else and you then simply started to use it as it is? You can use dnf mark to mark these packages as user-installed and thus, make clear that dnf autoremove does not remove them.

In terms of ntfs-3g, a native ntfs implementation is now part of the kernel. It works stable but I think there are still problems with some GUIs (we also had a thread about that some weeks ago). Because I already removed ntfs-3g myself, I don’t know if it is now intentionally removed in general from Fedora given its successor ntfs3. Maybe the GUI issues have been solved on GNOME (I only have ntfs partitions on my lxqt system).

1 Like