Is there a way to ensure packages are marked 'manual'? (Or, resync dependencies?)

I’ve been using Webmin/Virtualmin to do all package management.
For a debian upgrade, I’m using the shell, and apt-get. Imagine my surprise on the first use of it, that it recommended a HUGE list of “autoremovable” packages that are installed by Virtualmin!
Below are some that supposedly are no longer needed (just comparing the list to the package list in Webmin). Obviously this isn’t correct. Yet there are many that probably ARE no longer needed.

So, my simple (?) question is: how do I resync dependencies so the packages I’m actually using/needing are correctly marked?

A partial list:

  • network-manager
  • accountsservice
  • avahi-daemon
  • clamav
  • mariadb-server
  • milter-greylist
  • packagekit
  • smartmontools
  • spamassassin
  • sudo
Operating system Debian Linux 11
Webmin version 2.013
Usermin version 1.861
Virtualmin version 7.5
Authentic theme version 20.13


Do you mean you are doing a distri upgrade like Debian 10 to 11, which triggers this behavior?

Honestly I have not looked at this in a loooong time, and didn’t know to check it before the upgrade.
So, I have no idea if the upgrade “caused” it.

According to the apt man page, use of apt install auto-marks installed packages as manually installed, so that shouldn’t cause the issue.

Easy way to check on any apt-based linux distro:

apt-get --dry-run autoremove

To mark a package as manual, just install it.

i.e.: apt install network-manager

Though I wouldn’t generally use NetworkManager on a server.

these are all already installed.

At this point, I’m wondering the following likely-dumb-question :wink:

  • I originally installed Virtualmin using a recommended package into a ‘raw’ VM
  • Is it possible that:
    a) Virtualmin gets installed via some kind of master package, with dependencies on the various items that it wants…
    b) if that original master package gets upgraded, then the dependencies no longer necessarily exist?

Or something like that.

Obviously, I’ve got an “unsafe” install right now, in the sense that if I autoremove I may lose some important stuff, yet if I don’t, I appear to be retaining hundreds of unneeded packages as well.

I certainly see how this is one of the things that leads people to do full reinstalls occasionally. Painful for a fully-configured complex server but that’s the price of playing…


Virtualmin has it’s own “repo” for supported distros and versions.

The repos are primarily “Virtualmin” packages, and a “few” custom packages.

All other packages not specifically managed by Virtualmin are taken from the distros repo or any other repo you may have setup on your servers.

Repos by nature can specify “dependencies” needed for a package that is installed.

If I’m understanding y’all correctly, what this means at a pragmatic level is:

  • Normally (if everything’s properly configured), no package should end up auto-removable that was explicitly wanted at the outset.
  • The fact that I’ve got such issues means at some point, there was a configuration bug, somewhere… but essentially impossible to know at this late date…
  • Lesson Learned: regularly check the auto-remove list to seek anomalies!

Do I have that about right?


Or, potentially the package is no longer needed.

@Ilia and @Joe I see that for other version upgrades (see link below) Virtualmin has sometimes documented a specific set of commands to essentially do the forced-mark mentioned above by Joe. My guess: there are some of those needed for Debian 10 to 11… no longer surprised by this. :wink:

This is something your OS vendor does. We shouldn’t provide any steps or documentation on how to make distro upgrades. I will remove it in the future. It’s outside of Virtualmin control and can get hairy very quickly and easily.

That said, I personally had done around 8 or 9 release upgrades for Fedora Server. It wasn’t always smooth or easy but it worked flawlessly in the end. It was a physical server though, If it was however a virtual machine I would never do distro/release upgrade (especially on Debian systems), as it’s just much more time consuming rather than spinning up a new instance and just migrating data. I remember your post about FirewallD and Fail2Ban. It appears it took you numerous hours to figure things out (for which neither ours or your bugs) and you still only half way through, and yet with broken package manager metadatabase.

I would suggest to make a clean Debian 11 install and in 15 minutes you will already have clean and properly configured and working Virtualmin system … and in another few hours you will migrate all your data. I assume spending a few hours every 5 years instead of doing distro upgrade is better than ending up with a partially messed up system!

@Ilia I understand. IMHO, “migrate all your data” is the easy part. It’s the many custom configuration settings that take time to discover and migrate :frowning:

I suppose if I were VERY organized, I could take a localized “snapshot” of the initial /etc and /(whatever) trees, and do a global diff at upgrade time to see what I’ve changed. Yet clearly that’s insufficient as intervening updates also change things.

In days of yore I was a CBX (Computerized Branch eXchange) telephony R&D guy. “Moves and Changes” have always been a painful bugaboo… :wink:

FWIW, my server is now apparently running fine, including the shiny new incremental fail2ban. (A post on that coming soon… I am quite happy :wink: ). The only missing bit I see at the moment is the package metadatabase. :cowboy_hat_face:

1 Like

Yeah, I think Ilia’s right. We historically took on too much responsbility, and it’s led to a sort of unfortunate bit of expectation that we can support the entire OS and server, from hardware on up to web apps. When, in reality, we don’t have enough hours in the day to support so many people on so many distros, even when we limit ourselves to supporting just our software and software we directly interact with.

Distro upgrades are pretty much entirely a question for the distro provider. There probably is room for a doc about things to look out for, especially if changing Virtualmin repositories. But, we’re not the folks responsible for documenting apt/dpkg, and can’t be. We try to help when we can, but our docs fall far short of covering our own software, we can’t get distracted trying to write new docs for Debian/Ubuntu/RHEL stuff.

We’re also not experts on all that other stuff! (I mean, we have more experience than most of our customers, but that doesn’t mean we’re the best person to ask about some random Debian/Ubuntu/RHEL feature.)


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.