We had reports about problems stemming from skewed clocks during
installation, especially if their time was in the future during
installation and on first real boot got synced up, certs may not be
valid yet, RRD may has written data before that correcting time-sync
went through and errors afterwards, once time jumped back, and lots
of other issues.
So, depend on the modern and nifty, but still small, NTP
implementation `chrony`. Start its daemon just after we asked for a
DHCP lease, as then it can directly try to sync with one of the
(Debian namespaced) NTP pools time server.
In the worst case (no network, no server available) we are as good as
now, but if chrony can sync the time we avoid lots of issues and
breakages
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Package: pve-installer
Architecture: all
Depends: geoip-bin,
Package: pve-installer
Architecture: all
Depends: geoip-bin,
libgtk3-webkit2-perl,
pve-kernel-helper,
squashfs-tools,
libgtk3-webkit2-perl,
pve-kernel-helper,
squashfs-tools,
Package: pmg-installer
Architecture: all
Depends: geoip-bin,
Package: pmg-installer
Architecture: all
Depends: geoip-bin,
libgtk3-webkit2-perl,
pve-kernel-helper,
squashfs-tools,
libgtk3-webkit2-perl,
pve-kernel-helper,
squashfs-tools,
Package: pbs-installer
Architecture: all
Depends: geoip-bin,
Package: pbs-installer
Architecture: all
Depends: geoip-bin,
libgtk3-webkit2-perl,
pve-kernel-helper,
squashfs-tools,
libgtk3-webkit2-perl,
pve-kernel-helper,
squashfs-tools,
+echo -n "Starting chrony for opportunistic time-sync... "
+chronyd || echo "starting chrony failed"
+
echo "Starting a root shell on tty3."
setsid /sbin/agetty -a root --noclear tty3 &
echo "Starting a root shell on tty3."
setsid /sbin/agetty -a root --noclear tty3 &