I have Linux Mint 19.3 on the PC. I did a general upgrade as recommended by the Update Manager ( that was yesterday, January 28 2023). WINE was upgraded too from version 7.0 to 8.0, and the new version gave me trouble .
I removed it and after I removed it , I did apt autoclean followed by apt autoremove in the terminal. I ran APT check as well and there were no issues.I have done this many times before with no problems.When I booted up again, I could no longer boot into the GUI and startx did not work either. I then had to restore from a Timeshift backup via the terminal.
I'm no longer confident using autoremove. Has anyone ever had this problem too?

As I hope you know, Mint is based upon *buntu, which in turn is based upon Debian. Just today I finished cleaning up a very similar problem with an upgrade from Ubuntu 20.04 to 22.04. The need for the linux-modules-extra package was somehow removed in preparation to begin the upgrade, resulting in the 22.04 kernel's installation not including it. Either I didn't notice, or I caused it intentionally but forgot. It's the source for nouveau.ko, the absence of which forces FOSS NVidia graphics into fallback mode. It also stopped the kernel from finding my NIC, and thus there was no network. Because it is on a multiboot machine, I was able to easily boot Debian in order to fetch the correct linux-modules-extra package directly off a mirror and save it on the Ubuntu / filesystem so that I could install it. The process of installing it and rebuilding the initrd also brought networking back, so I never needed to determine why networking had failed. Autoremove is a good tool, but not perfect. It helps to eagle eye its list of what it proposes to remove before answering y. When in doubt, answer n, and either remove the individual packages manually, or find a way to prevent what needs to be kept from being included in the list to remove. I chose the manual route, so the affected .bash_history file on that installation currently holds about 200 lines that include the string purge. Or use timeshift, which I have never enabled on anything. Using something so easy makes it harder to learn from mistakes.

I use apt autoremove all the time.

Not sure if this is still the case but Debian and some Ubuntu, maybe all of them don't have a "Install limit" for kernels. For those with a separate boot partition, many times the small partition gets plugged with excess backup kernels that they can't finish applying updates at the rebuilding of initramfs stage and the update process pukes and you can't boot from the incomplete initramfs because there was not enough space. Not to mention, the update process takes a lot more time to complete with 8 kernels since it appears every initramfs that exist get's rebuilt when adding/removing a kernel.

Using autoremove after every second or third round of updates keeps a set kernel limit.

I have never had a negative experience with autoremove, in the past I never used it and my Debian testing which is always changing would always get obese, not very stable or quick in that shape, autoremove keeps it a little more slim and fit.

1 members found this post helpful.

This is configurable via update_initramfs= in /etc/initramfs-tools/update-initramfs.conf.

Not something apt will tell you at the command line. However, seems lately apt now tells you when there are packages no longer needed and use autoremove to remove them.

The information you provide is not exactly common knowledge but nice to know for sure.
The RPM junkies have "install-limit" or similar set to 3 in /etc/dnf/dnf.conf, no need to wait till your system can't boot because there is no set default like in Debian types with plugged boot partitions.
Would be nice if this was automatically set like dnf.

1 members found this post helpful.

I am completely satisfied with autoremove.
The trouble here is Wine on Mint and a new problem with current install-packages. People with knowledge of the distribution should be able to help or to direct.

Along with reading the list of proposed actions prior to accepting, it's probably also worth finding out what autoremove actually does.
https://manpages.ubuntu.com/manpages...an8/apt.8.html

It does seem like a WINE on mint/ubuntu/debian problem in my case. Other users have had this problem too. Autoremove can create problems and not only because of a WINE removal, and I don't trust "APT check" now either. I'll post it as a bug on the WINE site, although I don't think there will be a response to it.
Here is a link for someone who had my experience:
https://askubuntu.com/questions/7202...move-dangerous

There are also some who have had my failure on a MATE desktop version of mint, which is what I use. A gui failure.Possibly it's something not only related to WINE removal, but to removing it on a MATE desktop machine.
Next time I'll use : "apt autoremove --dry-run" first, and pay close attention to desktop packages.I don't know them, but will have to find out what they are.

Have a look at /var/log/apt/history.log or history.log.1.gz
It details what was removed, you may spot something prompting you to reinstall a package that may fix the issue. The log is well detailed as in my log example below:

1 members found this post helpful.

Good tip thank you.

I have used sudo apt autoremove extensively with Debian based Antix22 LXDE and Loc-OS without any problems – it has been most useful in keeping my system minimal after using Synaptic to fully remove apps or packages.
At times it notifies me and lists “file or folder was not empty so was not deleted”
At this stage I would not wish to use Bleachbit to force the issue or delete the individual items under sudo command.

I still do not know how to list unused packages such as firmware specific to hardware I do not have – perhaps another topic…?

Most of the time autoremove works without any problems, however I also have had a few times, far and inbetween, where autoremove removed more that it should have resulting in a broken system.

Was your system so broken that you could not run sudo apt update..?
Would this have repaired your system as it would have recognised the broken package?

No, the one time I remembered I had the same problem as the op and had to reinstall a few packages to get X to work again, I don't remember the details, just remember it happening.