cloudron 6.0.1 fail to install on a new fresh ubuntu 20.04 server
-
hi there,
i'm trying to install cloudron on a new fresh ubunntu 20.04 server
the installation fail with the following error :echo "==> Configuring host" ==> Configuring host sed -e 's/^#NTP=/NTP=0.ubuntu.pool.ntp.org 1.ubuntu.pool.ntp.org 2.ubuntu.pool.ntp.org 3.ubuntu.pool.ntp.org/' -i /etc/systemd/timesyncd.conf timedatectl set-ntp 1 Failed to set ntp: NTP not supportedi have tried to manually setup timedatectl with a ntp service but the same error append.
keep up the great work ! -
Hm maybe the specific ubuntu image from scaleway does not pre-install ntp. Can you run
apt-get install ntpand then try to install Cloudron again?@nebulon said in cloudron 6.0.1 fail to install on a new fresh ubuntu 20.04 server:
apt-get install ntp
i already done that but no change.
after installing$: timedatectl statusrerpot :Local time: Tue 2020-12-08 13:50:22 CET Universal time: Tue 2020-12-08 12:50:22 UTC RTC time: Tue 2020-12-08 12:50:22 Time zone: Europe/Paris (CET, +0100) System clock synchronized: no NTP service: n/a RTC in local TZ: norelating to this answer on serverfault :
timedatectl command reports that NTP is in use when either chronyd or systemd-timesyncd
apt-get install systemd-timesyncdseems to solve my problem ( chronyd does not work for me)... -
On DEV1-M, the package is already there and
timedatectl set-ntp 1works on a vanilla ubuntu 20root@scw-tender-euclid:~# systemctl status systemd-timesyncd ā systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2020-12-08 18:25:01 UTC; 1min 22s ago Docs: man:systemd-timesyncd.service(8) Main PID: 270 (systemd-timesyn) Status: "Initial synchronization to time server 10.194.3.3:123 (10.194.3.3)." Tasks: 2 (limit: 614) Memory: 1.7M CGroup: /system.slice/systemd-timesyncd.service āā270 /lib/systemd/systemd-timesyncd Dec 08 18:25:00 ubuntu systemd[1]: Starting Network Time Synchronization... Dec 08 18:25:01 ubuntu systemd[1]: Started Network Time Synchronization. Dec 08 18:25:04 scw-tender-euclid systemd-timesyncd[270]: Network configuration changed, trying to establish connection. Dec 08 18:25:04 scw-tender-euclid systemd-timesyncd[270]: Network configuration changed, trying to establish connection. Dec 08 18:25:06 scw-tender-euclid systemd-timesyncd[270]: Network configuration changed, trying to establish connection. Dec 08 18:25:36 scw-tender-euclid systemd-timesyncd[270]: Initial synchronization to time server 10.194.3.3:123 (10.194.3.3). -
It worked on a STARDUST1-S instance as well. Mmm, let's see if we have others reporting similar issue before making a fix.
-
It worked on a STARDUST1-S instance as well. Mmm, let's see if we have others reporting similar issue before making a fix.
@girish it may only be my server... the scalway support is working on my server since my last message because the server is randomly going offline for no apparent reason after(?) installing cloudron. they even tryed to change the server because the ubuntu reinstalaltion process got broken at some point.
on their ubuntu image openntpd is installed in place of systemd-timesyncd.
have you ever encountered this kind of probleme (server randomly going offline ) ?
-
@girish it may only be my server... the scalway support is working on my server since my last message because the server is randomly going offline for no apparent reason after(?) installing cloudron. they even tryed to change the server because the ubuntu reinstalaltion process got broken at some point.
on their ubuntu image openntpd is installed in place of systemd-timesyncd.
have you ever encountered this kind of probleme (server randomly going offline ) ?
-
i have watched journalctl until it crash and ...
Apparently it was systemd-sleep kicking in and suspending the server ...
i previsously missed it from logs because i was searching for errors.
( also i was assuming that it came from scalway because the first server was completly broken and they had to replace it)i have disabled power management with :
$: systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.targetit should go fine now.
Thanks for your time
-
i have watched journalctl until it crash and ...
Apparently it was systemd-sleep kicking in and suspending the server ...
i previsously missed it from logs because i was searching for errors.
( also i was assuming that it came from scalway because the first server was completly broken and they had to replace it)i have disabled power management with :
$: systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.targetit should go fine now.
Thanks for your time
-
@thenils wow that's quite the oversight from Scaleway.
A server OS doesn't normally come with power management by default.
There may be other things hidden there, so check if you can install your own clean OS with less surprises.
-
The exact same ntp issue also happens with the Ubuntu 20.04 image being used by Atlantic.net.
After initial VM spin-up, the output of
timedatectlwas showing as:Local time: Tue 2021-01-05 00:04:37 UTC Universal time: Tue 2021-01-05 00:04:37 UTC RTC time: Tue 2021-01-05 00:04:37 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes NTP service: n/a RTC in local TZ: noDue to the NTP service showing as n/a, even though it is verified as running and enabled, your setup script passing the
timedatectl set-ntp 1would fail with:Failed to set ntp: NTP not supportedAfter wasting too much time on NTP issues by verifying configs and the working of the NTP daemon, I pulled the default NTP package and installed Chrony. Problems vanished.
For whatever reason, the default ntp package used in the image:
Package: ntp Version: 1:4.2.8p12+dfsg-3ubuntu4is not being recognized by
timedatectl. I'm sure it is a simple fix, but it is just so much faster to replace ntp.Hope this helps someone.
-
The exact same ntp issue also happens with the Ubuntu 20.04 image being used by Atlantic.net.
After initial VM spin-up, the output of
timedatectlwas showing as:Local time: Tue 2021-01-05 00:04:37 UTC Universal time: Tue 2021-01-05 00:04:37 UTC RTC time: Tue 2021-01-05 00:04:37 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes NTP service: n/a RTC in local TZ: noDue to the NTP service showing as n/a, even though it is verified as running and enabled, your setup script passing the
timedatectl set-ntp 1would fail with:Failed to set ntp: NTP not supportedAfter wasting too much time on NTP issues by verifying configs and the working of the NTP daemon, I pulled the default NTP package and installed Chrony. Problems vanished.
For whatever reason, the default ntp package used in the image:
Package: ntp Version: 1:4.2.8p12+dfsg-3ubuntu4is not being recognized by
timedatectl. I'm sure it is a simple fix, but it is just so much faster to replace ntp.Hope this helps someone.
@tx-hermit thanks for reporting, let me test out atlantic.net to see if we can fix this to make it work out of the box.
-
The exact same ntp issue also happens with the Ubuntu 20.04 image being used by Atlantic.net.
After initial VM spin-up, the output of
timedatectlwas showing as:Local time: Tue 2021-01-05 00:04:37 UTC Universal time: Tue 2021-01-05 00:04:37 UTC RTC time: Tue 2021-01-05 00:04:37 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes NTP service: n/a RTC in local TZ: noDue to the NTP service showing as n/a, even though it is verified as running and enabled, your setup script passing the
timedatectl set-ntp 1would fail with:Failed to set ntp: NTP not supportedAfter wasting too much time on NTP issues by verifying configs and the working of the NTP daemon, I pulled the default NTP package and installed Chrony. Problems vanished.
For whatever reason, the default ntp package used in the image:
Package: ntp Version: 1:4.2.8p12+dfsg-3ubuntu4is not being recognized by
timedatectl. I'm sure it is a simple fix, but it is just so much faster to replace ntp.Hope this helps someone.
I could reproduce the issue on atlantic.
root@cloudron:~# systemctl is-active ntp active root@cloudron:~# timedatectl set-ntp 1 Failed to set ntp: NTP not supportedThen, I saw this error in ntp service logs:
ā ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2021-01-05 01:28:44 UTC; 9min ago Docs: man:ntpd(8) Main PID: 23144 (ntpd) Tasks: 2 (limit: 2353) Memory: 1.5M CGroup: /system.slice/ntp.service āā23144 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 107:115 Jan 05 01:28:49 cloudron ntpd[23144]: Soliciting pool server 69.164.213.136 Jan 05 01:28:49 cloudron ntpd[23144]: Soliciting pool server 91.189.89.199 Jan 05 01:28:49 cloudron ntpd[23144]: Soliciting pool server 104.194.8.227 Jan 05 01:28:49 cloudron ntpd[23144]: Soliciting pool server 50.205.244.39 Jan 05 01:28:50 cloudron ntpd[23144]: Soliciting pool server 91.189.89.198 Jan 05 01:28:50 cloudron ntpd[23144]: Soliciting pool server 173.255.215.209 Jan 05 01:28:50 cloudron ntpd[23144]: Soliciting pool server 68.54.100.49 Jan 05 01:28:50 cloudron ntpd[23144]: Soliciting pool server 66.79.136.235 Jan 05 01:28:50 cloudron ntpd[23144]: Soliciting pool server 4.53.160.75 Jan 05 01:34:27 cloudron ntpd[23144]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronizedntptime also returns some strange errors:
root@cloudron:~# ntptime ntp_gettime() returns code 5 (ERROR) time e39e4293.b8e9e5e4 Tue, Jan 5 2021 1:42:43.722, (.722319846), maximum error 16000000 us, estimated error 16000000 us, TAI offset 37 ntp_adjtime() returns code 5 (ERROR) modes 0x0 (), offset 0.000 us, frequency 0.000 ppm, interval 1 s, maximum error 16000000 us, estimated error 16000000 us, status 0x2041 (PLL,UNSYNC,NANO), time constant 3, precision 0.001 us, tolerance 500 ppm, -
The exact same ntp issue also happens with the Ubuntu 20.04 image being used by Atlantic.net.
After initial VM spin-up, the output of
timedatectlwas showing as:Local time: Tue 2021-01-05 00:04:37 UTC Universal time: Tue 2021-01-05 00:04:37 UTC RTC time: Tue 2021-01-05 00:04:37 Time zone: Etc/UTC (UTC, +0000) System clock synchronized: yes NTP service: n/a RTC in local TZ: noDue to the NTP service showing as n/a, even though it is verified as running and enabled, your setup script passing the
timedatectl set-ntp 1would fail with:Failed to set ntp: NTP not supportedAfter wasting too much time on NTP issues by verifying configs and the working of the NTP daemon, I pulled the default NTP package and installed Chrony. Problems vanished.
For whatever reason, the default ntp package used in the image:
Package: ntp Version: 1:4.2.8p12+dfsg-3ubuntu4is not being recognized by
timedatectl. I'm sure it is a simple fix, but it is just so much faster to replace ntp.Hope this helps someone.
@tx-hermit Ah, here's the explanation - https://serverfault.com/questions/1024770/ubuntu-20-04-time-sync-problems-and-possibly-incorrect-status-information . Uninstalling/disabling ntp service does the trick! I will make a fix for next release.
