Most installation problems are related to having third party repositories enabled, attempting to run the install script on an unsupported operating system, and sometimes network connectivity.
Installation "Freezes" and Never Completes
Check the /root/virtualmin-install.log. It is possible that your package manager is configured to use a local CD ROM device for packages, and the disk is unavailable. Another possibility is that connections to one or more repositories are timing out, and causing the system to install packages very slowly.
- 1 Installation Troubleshooting
- 1.1 Installation "Freezes" and Never Completes
- 1.2 Third Party Repositories and Package Conflicts
- 1.3 Package Manager Errors (signed errors, failed to download comps.xml file, etc.)
- 1.4 /tmp directory is mounted noexec
- 1.5 ClamAV outdated errors
- 1.6 ClamAV ERROR: Could not lookup : Servname not supported for ai_socktype
- 1.7 DBI connect failed : Access denied for user 'root'@'localhost' (using password: NO)
- 1.8 Getting Help
Third Party Repositories and Package Conflicts
If your package manager is configured to use non-OS package repositories, or if you have installed alternative versions of packages before installation, conflicts are likely to occur during installation. If you plan to use non-OS standard packages (other than those provided by Virtualmin repositories), they should be installed after installation of Virtualmin, and you should add an exclude directive to the yum or apt-get configuration in order to insure similar conflicts do not happen in the future.
Also note that if you are using non-OS standard packages, you may need to configure the relevant Webmin module to make it aware of the location of the configuration files.
Note that if your Linux distribution was installed by your ISP (such as with a VPS image), you may want to verify that no additional repositories were setup.
Package Manager Errors (signed errors, failed to download comps.xml file, etc.)
Sometimes package manager metadata can end up in a broken state. Try cleaning the metadata to see if it resolves the problem.
On RHEL/CentOS systems:
# yum clean all
On Debian/Ubuntu systems:
# apt-get clean; apt-get update
Then try the installation again.
/tmp directory is mounted noexec
If you have run any so-called "hardening scripts" on your system before running install.sh, your /tmp directory may be mounted noexec. It is always best to run the install script on a freshly installed supported Operating System, though this particular issue can be resolved. The install script cannot complete if this is the case, and /tmp will need to be remounted to allow executables.
To do that:
# mount -o remount,exec /tmp
If you wish to switch back to your original settings after installation, you can use this command to reset the noexec option:
# mount -o remount,noexec /tmp
ClamAV outdated errors
ClamAV is updated frequently by the upstream developers. Your OS repository may not have the latest version, which causes ClamAV to issue very scary warnings. These warnings are non-fatal, and can generally be safely ignored.
If you are using CentOS, the ClamAV packages come from our repositories, and are updated every few weeks, as time and testing schedules allow. So, if you see this error, it will go away with the next update.
If you are using Debian, you may consider enabling the "volatile" apt-get repository, as it includes newer versions of ClamAV and SpamAssassin, which are both rapidly moving targets and worth running recent versions of.
ClamAV ERROR: Could not lookup : Servname not supported for ai_socktype
We don't know why this happens. ClamAV has become very fragile in recent years.
Usually, you can work around it, by starting clamd service from the command line. On CentOS 7 systems:
# systemctl start clamd@scan
Then trying again in the post-install wizard.
DBI connect failed : Access denied for user 'root'@'localhost' (using password: NO)
Some virtual machine images, and some hosting providers set a MySQL/MariaDB root password, and thus it's impossible for Webmin to login to MySQL/MariaDB, so the initial database setup during the post-install wizard will complain. The workaround this, you have a couple of options. If you know the MySQL/MariaDB root password, you can configure Webmin to connect with it in the MySQL module under Webmin>Servers>MySQL, filling in the root password.
If you don't know the MySQL/MariaDB root password, you can set one from the command line with the following steps:
# service mysql stop
# service mariadb stop
# mysqld_safe --skip-grant-tables --skip-networking & # mysql -u root > use mysql; > update user set password=PASSWORD("") where User='root'; > flush privileges; > quit;
And, then restart the server as normal.
# service mysql restart
# service mariadb restart
Now the install wizard should be able to set a MySQL root password for you, as usual.
Virtualmin Professional customers receive free installation service if the automated installation process fails to work correctly on any Grade A supported operating system listed on the OS Support page. Open a ticket in the issue tracker with a description of your problem and the relevant portion of the virtualmin-installation.log, and we will try to walk you through to a solution, or log into your system and complete the installation free of charge.
Virtualmin GPL users can make use of the forums to ask for assistance with any problems that arise during installation.