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.
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.
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:
apt-transport-https
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 http://deb.debian.org/debian 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:
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.
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 "https://203.0.113.1" -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):
