The VirtualMin installer starts correctly and asks for a fully qualified domain next.
Next the installer fails
With an error message that wget can not resolve to software.virtualmin.com.
If I now check resolv.conf, it only contains:
Generated by NetworkManager
======================================
After manually setting resolv.conf back to it’s original values, software.virtualmin.com resolves correctly again.
After starting the Virtualmin GPL installer again, now it is able to complete all correctly.
And Virtualmin works correctly.
Hetzner is one of the biggest hosters, for more info see: https://www.hetzner.com/?country=de
VirtualMin GPL Installer fails with their clean Rocky 8 and Alma 8 images (I tried both).
The repair is to set back the original resolv.conf. But it would be better if this could perhaps be solved in the install script (if possible)?
Not sure if this is relevant but I had issues with a fresh install of AlmaLinux 9 on a Vultr instance.
I chose to install Alma in the Vultr control panel. After installing Virtualmin there were some unusual issues related to “cloud-init” package. I think Vultr make their own install images with additional packages presumably to improve things within their virtualisation environment.
When I took the laternative installation approach of booting the Alma ISO image, I had no problems later with VM and software updates.
I just installed Rocky 9 (basically the same) at vultr about a month ago. Can you screenshot what you mean. I’ve had no issues. No idea what cloud-init is.
P.S.
ok, found some info. Did you tick Enable Cloud-Init User-Data during deployment?
a bit above my knowledge or use.
1 - purchased a root server EX from Hetzner
2 - choose for their minimal Alma Linux 8 image
3 - as root: wget the Virtualmin gpl installer + gave exec rights.
4 - ran install-virtualmin.sh
Next de installer failed because resolver was overwritten.
Tried this 3 times (restore server back to (2). Also tried it with the Rocky image, same result.
Before I figured out that the resolver was being overwritten by or due to the virtualmin installer.
So all straighforward, no extra manual settings or whatever.
After manually restoring the resolver back to how it was before starting the virtualmin installer, and running the installer again (so for the second time), all went fine and installation was okay.
May be related to the default AlmaLinux / Rocky image provided by Hetzner?
I don’t see how that could happen. I’ll have to try to reproduce it, but there is no code touching resolv.conf in the installer that I know of (and I wrote the installer!).
Fire up a new server. Do not install Virtualmin, yet.
Run dnf update
Does it change resolv.conf?
If not, wait a while…check the status of cloud-init service. Is it still doing things? (I just fired up a test Rocky 8 instance on vultr, and cloud-init was still installing packages and making changes several minutes after the system first booted.)
I’m guessing that the host has made a mistake in something they’re deploying automatically, and because we trigger a dnf update before starting, just to try to avoid known bugs in the OS packages from causing problems because folks don’t always update before running the installer. But, we’ve already seen issues where the hosting provider has their own packages that break stuff. I’m guessing this is another instance of that.
My test install did not touch resolv.conf (as expected). And I’m pretty confident it is not touching resolv.conf on your system, either. But, something we trigger (like updating system packages with dnf update) might be making that change. It’s not something we can fix. If your host gives you a system that isn’t safe to run dnf update on, that’s a problem they need to solve.
If I’m wrong and we are actually changing it, of course I still want to fix it. But, I don’t see how it can be anything we’re doing.