I dug into this and found the real culprit. To be clear, repo setup is a very complex flow with thousands of small ordered steps, and I made one ordering mistake in the EL migration path—we removed the old release/repo file before checking whether the old repo had been present. Because of that, the migration logic never ran on EL systems.
Besides, the migration script did not correctly handle release-number changes within the same package version, for example Webmin 2.641-1 vs 2.641-3. That would have caused problems too, because package managers treat those as different package releases even though the upstream Webmin version is the same.
Debian and Ubuntu were not affected in the same way because their migration path still detected the old repo correctly and ran the migration as expected.
I understand the concern, but I’m sure it would be far more complicated to support both paths.
A repo change happens either way because moving from GPL to Pro is also a repo change. I understand and agree it’s not exactly the same as moving from Virtualmin 7 repos to Virtualmin 8 repos within the same product line, but we still need to place the system on the correct Pro repo. This is especially important for clean Virtualmin 8 GPL installs upgraded to Pro, as they must get the new Virtualmin Pro repo, not the old one.
So, if we try to support both, we have to distinguish between clean GPL-to-Pro upgrades, older Virtualmin 7 repo installs, already-migrated systems, stable/pre-release/unstable branches, and GPL vs Pro repo layouts. That would highly likely create more issues than it solves.
The migration logic is designed to handle repo switch cleanly, and now it does on both EL systems and Debian/Ubuntu. Factually, the main practical difference between the old and new repos is that Webmin changed from a full package to a core package with separate module packages. If the migration runs correctly, as it does now, it reinstalls Webmin from the new repo and restores the Webmin modules the user was already using.
Later this autumn, we’ll still need to ask a much larger group of users to upgrade their repos. They’ll start seeing a message during config check starting September 30 asking them to do so. If we didn’t already have this process in place, the same type of bug could have affected a much larger group of users. Now the repo upgrade path should be smooth, and users shouldn’t have to worry anymore about missing modules they were previously using.
In the past, the repo upgrade logic was mostly hard-coded around the Virtualmin package itself, which made these kinds of issues much harder to fix cleanly. Now the repo setup logic is decoupled, so we can fix repo setup or repo migration bugs in no time.
And, as you very well know, Joe, the repo setup script is extremely complex. And, this is why it’s now the single source of truth for how GPL and Pro repos are configured across stable, pre-release, and unstable branches across different systems.
In this case, as I explained above, the EL issue came down to one ordering mistake in a process with thousands of small steps, as we removed the old repo file before checking whether the old repo was present. That’s fixed now, so no worries here.
I added a direct link from the Virtualmin Documentation page in the FAQ section to explain the change. It’s now much easier to find.
Yet, after all I’m thinking we should add back a few modules to Webmin core package that many users asked about, like webmin-custom and webmin-postgresql at least. I’ll test how it behaves during upgrades and whether package managers can handle the change correctly.
Again, thanks to everyone for bringing this up and helping to sort out a tricky but important issue. I really appreciate it!
And sorry for any frustration caused by the few missing Webmin modules after upgrade.