Installation failed repeatedly


Hoping someone here can shed some light on an issue I’ve been having trying to install Virtualmin on a new VPS (DigitalOcean 512MB/Ubuntu 14.04, though it happens identically on 16.04 and a 1GB VPS). I’ve had a scout through the forums, and I can’t see anyone else having the same issue.

Using (freshly wget’d each time), it always fails at some point during the installation of virtualmin-base, throwing errors as below.

I’m at my wit’s end, as I’m getting the same failures regardless of Ubuntu version or VPS size. I’ve tried reimaging the VPS, and deleting it and creating a brand new one, all with the same result! I’ve had Virtualmin working previously on a 14.04 512MB DigitalOcean VPS, so I’m a bit confused about what’s changed. Any ideas?

Thanks in advance,


Full logs here, if its any help!

INFO - /usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install bsdutils postfix postfix-pcre webmin usermin ruby libxml-simple-perl libcrypt-ssleay-perl unzip zip libfcgi-dev bind9 spamassassin spamc procmail procmail-wrapper libnet-ssleay-perl libpg-perl libdbd-pg-perl libdbd-mysql-perl quota iptables openssl python mailman subversion ruby irb rdoc ri mysql-server mysql-client mysql-common postgresql postgresql-client awstats webalizer dovecot-common dovecot-imapd dovecot-pop3d proftpd libcrypt-ssleay-perl awstats clamav-base clamav-daemon clamav clamav-freshclam clamav-docs clamav-testfiles libapache2-mod-fcgid apache2-suexec-custom scponly apache2 apache2-doc libapache2-svn libsasl2-2 libsasl2-modules sasl2-bin php-pear php5 php5-cgi libapache2-mod-php5 php5-mysql ntpdate: Succeeded. INFO - Succeeded. INFO - Installing Virtualmin and all related packages now using the command: INFO - /usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install virtualmin-base progress, please wait... ................................Use of uninitialized value in numeric eq (==) at /usr/share/webmin/bind8/ line 537. Use of uninitialized value in numeric eq (==) at /usr/share/webmin/bind8/ line 543. ..Enabling quotas on filesystem for /home ...........dpkg: error processing package virtualmin-base (--configure): subprocess installed post-installation script was killed by signal (Killed) Errors were encountered while processing: virtualmin-base

E: Sub-process /usr/bin/dpkg returned an error code (1)

/usr/bin/apt-get --config-file apt.conf.noninteractive -y --force-yes install virtualmin-base failed. Error (if any): 0

Displaying the last 15 lines of /root/virtualmin-install.log to help troubleshoot this problem:
Enabling status monitoring
Hiding the Webmin upgrade page
convertquota: You have to specify action to perform.
convertquota: Utility for converting quota files.
convertquota [options] mountpoint

-u, --user convert user quota file
-g, --group convert group quota file
-e, --convert-endian convert quota file to correct endianity
-f, --convert-format oldfmt,newfmt convert from old to VFSv0 quota format
-h, --help show this help text and exit
-V, --version output version information and exit

convertquota: Bugs to
WARN - apt-get seems to have failed. Are you sure your OS and version is supported?

FATAL - Fatal Error Occurred: Installation failed: 0
FATAL - Cannot continue installation.
FATAL - Attempting to remove virtualmin repository configuration, so the installation can be
FATAL - re-attempted after any problems have been resolved.
FATAL - Removing temporary directory and files.
FATAL - If you are unsure of what went wrong, you may wish to review the log
FATAL - in /root/virtualmin-install.log

Repeating the install won’t change anything. :wink:

I don’t know why that’s happening. It looks like quota setup is failing for some reason, but the reason doesn’t make sense. I guess maybe the mountpoint for /home is being misdetected, and when convertquota is run, the command freaks out because it isn’t actually a mountpoint. I haven’t seen this problem before.

I’m also not sure how to workaround it…that setup step happens in virtualmin-base during the postinstall script, so it can’t be edited without rebuilding the virtualmin-base package.

What’s the contents of /etc/fstab and /etc/mtab? And what does df output?


As another suggestion, try setting up your droplet with CentOS 7, and let us know if the issue persists.

We’ve worked with Digital Ocean, and have never experienced issues installing Virtualmin using CentOS.

If you require hands on assistance, feel free to drop me a line and I can assist resolving the issue, and/or diagnosing the matter more for Joe and Jamie.

I think it was blind optimism more than anything :wink:

# Written by the DigitalOcean build process

LABEL=DOROOT / ext4 errors=remount-ro,usrquota,noatime,rw,grpquota 0 1
proc /proc proc nodev,noexec,nosuid 0 0

/dev/vda1 / ext4 rw,noatime,errors=remount-ro,usrquota,grpquota 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0
none /sys/fs/cgroup tmpfs rw 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
udev /dev devtmpfs rw,mode=0755 0 0
devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
tmpfs /run tmpfs rw,noexec,nosuid,size=10%,mode=0755 0 0
none /run/lock tmpfs rw,noexec,nosuid,nodev,size=5242880 0 0
none /run/shm tmpfs rw,nosuid,nodev 0 0
none /run/user tmpfs rw,noexec,nosuid,nodev,size=104857600,mode=0755 0 0
none /sys/fs/pstore pstore rw 0 0
systemd /sys/fs/cgroup/systemd cgroup rw,noexec,nosuid,nodev,none,name=systemd 0 0

df -h gives:

Filesystem Size Used Avail Use% Mounted on
udev 228M 4.0K 228M 1% /dev
tmpfs 49M 440K 49M 1% /run
/dev/vda1 20G 2.5G 17G 14% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 245M 0 245M 0% /run/shm
none 100M 0 100M 0% /run/user

Thanks for your help on this!


I gather you solved the mystery? If so, glad to hear :slight_smile:

I think I’m getting closer, but still no solution!

Done a bit more tinkering, and installation works flawlessly on both a CentOS droplet at DigitalOcean, and an Ubuntu 16.04 VPS at Linode - leading me to think its a problem with DigitalOcean’s Ubuntu image somehow. Interestingly, I just span up a new Ubuntu droplet, and the installation failed in a similar, but different place. Log here - looks like its failing at BIND. Despite the installation failing, I seem to be able to access Virtualmin, though I’m not sure I trust it…

Oh! So it’s not actually a mountpoint issue, at all. Different symptoms like this nearly always means memory is running out and the oom killed is kicking in. It’s weird that it happens so late, though…I would expect it during the install of packages, not during configuration (which doesn’t usually take a lot of memory).

Check dmesg for OOM (out of memory) messages. If that’s so, then adding a swap file will make the problem go away. You can then reduce the size of Virtualmin once installed by following the low memory guide. Now that all of the major VPS providers have good packages for $5 I’m about to go through and run install tests on all of them to make sure we handle them gracefully (Virtualmin is historically tuned for performance and not low memory…but, it’s just so common that people want a tiny system for cheap that we need to make the installer better for those environments).

Boy do I feel stupid now!

Installed without a hitch. Thanks a lot :slight_smile: