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?
At this point, I’m wondering the following likely-dumb-question …
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…
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!
@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.
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
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…
FWIW, my server is now apparently running fine, including the shiny new incremental fail2ban. (A post on that coming soon… I am quite happy ). The only missing bit I see at the moment is the package metadatabase.
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.)
…
