@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.
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… 
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 
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 
Additional question: @augenauf ain’t this more a topic for discussions.fedora rather than ask.fedora?
Discussions.
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 
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