New Installations (v1.8.8) Stuck at "Installing dependencies"

As the title suggests, new Installations of v1.8.8 are stuck at “Installing dependencies” step, on both Debian and Ubuntu. I noticed that this error was immediately introduced after the last v1.8.8 release.

Update: After rebooting the server and re-running the installation script, it successfully passed “Installing dependencies” step, so it seems it was able to install missing dependencies at the first time but was not able to communicate this and kept showing the “Installing dependencies” screen indefinitely.

Hello @islasphere,

What are the debian and ubuntu versions?

What options you used to install Hestia?

The message was exactly Installing dependencies or it was [ * ] Installing dependencies...

I’m asking because when you install Roundcube, composer tries to install the dependencies so maybe it is related to Roundube installation and nthere is a PR merged already to fix the Roundcube issue.


Install dependencies does’t install Roundcube during the install…

It only download the dependencies for phpmailer and a few other tools…

That is the reason I’m asking for the exact message, because if it is [ * ] Installing dependencies... it is not related to Roundcube :wink:

@islasphere maybe you should check the log in /root/hst_install_backups/hst_install-HEREDATEANDTIME.log

I’ve installed Hestia 1.8.8 right now in a clean and minimal Debian 12.1 and it installed Hestia perfectly.

Debian 12
Ubuntu 22.04 LTS
The message was “[ * ] Installing dependencies…”
The used flags during installation were:
–apache no --spamassassin no --clamav no --port 2087 --quota yes --sieve yes --hostname *** --email *** --password ***

After inspecting the logs turns out the first install attempt (the one that got stuck) had only one required dependency that was not installed (apt-transport-https), so it proceeded to install it, and though the log shows it was installed successfully, the installation script didn’t proceed after that step and kept showing the “[ * ] Installing dependencies…” message.

The other log that belongs the successful installation (the one done after the reboot) shows that all dependencies was already installed, and hence proceeded normally.

This is the log of the first run:

Reading package lists...
Building dependency tree...
Reading state information...
ca-certificates is already the newest version (20230311).
curl is already the newest version (7.88.1-10+deb12u1).
dirmngr is already the newest version (2.2.40-1.1).
dirmngr set to manually installed.
gnupg is already the newest version (2.2.40-1.1).
openssl is already the newest version (3.0.9-1).
wget is already the newest version (1.21.3-1+b1).
The following NEW packages will be installed:
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.2 kB of archives.
After this operation, 35.8 kB of additional disk space will be used.
Get:1 bookworm/main arm64 apt-transport-https all 2.6.1 [25.2 kB]
Fetched 25.2 kB in 0s (896 kB/s)
Selecting previously unselected package apt-transport-https.
(Reading database ... 39178 files and directories currently installed.)
Preparing to unpack .../apt-transport-https_2.6.1_all.deb ...
Unpacking apt-transport-https (2.6.1) ...
Setting up apt-transport-https (2.6.1) ...

If apt didn’t get stuck setting the package apt-transport-https (I doubt apt-get got stuck) there are other commands that could cause that and my guess is this command:

wget --quiet "" -O /dev/null

By default, wget has no limit neither for connection nor dns timeouts and has 15 minutes for read timeouts so maybe you had some dns or connection issues and wget was stuck forever. If you can test it in a new installation, execute the command manually to see whether it gets stuck before trying to install Hestia.

If that is the problem, maybe a timeout should be used in wget (for example; --timeout=30)

Hi @sahsanu , I just tried a fresh new install from a different cloud platform and everything went normally, so I guess this bug is now considered vendor-specific. For now I will mark this reply as a solution. Thanks sahsanu and eris for your involvement in this topic and for all your efforts in this amazing community.

1 Like

If the install of apt package failed it would be broken a long time ago.

Also the installer log sucks a lot in the current setup…

Yes, that’s why I doubt the apt-get install failed but I think wget should have a timeout, if you use wget without a timeout, in Debian doesn’t wait forever but it does during 45 minutes:

$ time wget --quiet "" -O /dev/null

real    45m38.944s
user    0m0.007s
sys     0m0.014s

So a change to wget could be something like this (timeout at 30 seconds and retry the connection max 3 times):

wget --timeout=30 --tries=3 --quiet "https://$RHOST" -O /dev/null

$ time wget --timeout=30 --tries=3 --quiet "" -O /dev/null

real    1m33.026s
user    0m0.021s
sys     0m0.005s

I agree, current installer’s log is not very useful.


1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.