-
Notifications
You must be signed in to change notification settings - Fork 168
apt-get update because date/time not set correctly #304
Comments
This might be a problem of all services starting in parallel. The Raspberry Pi has no battery powered clock, it uses a fake clock with a time stamp of the last shutdown AFAIK. |
Maybe the boot sequence can be adapted to work with a modified NTP config that allows for faster convergence and which is switched to the default one after some time (before any user stuff as in `runcmd` is run).
I can look into it but I have no experience with the inner workings of buster/cloud-init.
If I would have some good pointers on how to get started, I can take a stab at it.
… Op 25 jul. 2019 om 08:25 heeft Stefan Scherer ***@***.***> het volgende geschreven:
This might be a problem of all services starting in parallel. The Raspberry Pi has no battery powered clock, it uses a fake clock with a time stamp of the last shutdown AFAIK.
Maybe the boot order has change a little bit in Buster. Maybe there is a command to trigger ntp to sync current date.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@eloots Yes, please try it. Would be great to get this resolved. |
Here's an intermediate update - I haven't looked at modifying the boot sequence [yet], but I've run a number of experiments to observe behaviour and have come to the following conclusions.
From
First experimentI changed the Second experimentFrom one of the runs, here's the time when
I changed my
This results in the following output in
The sequence of interesting events after the restart of
This shows that the correct time is set by So, here's what I think is a correct solution to this problem:
This is 10s after
OtherThere's a way to set the correct time from time servers using
That could be done as part of the If the WDYT? |
This is the temp. workaround I have in my
|
I'm using the package_update: true
package_upgrade: true
package_reboot_if_required: true
packages:
- fail2ban
- vim
- unzip
- tree
- ssmtp
- rsync
- ntfs-3g
- file
- pv the
|
@Legion2 The problem you're seeing is the one described in this issue. What can be confusing is that You can use the workaround I describe above (install packages in the I don't know why this did worked with the previous version of Hypriot (<= 1.10.0) on all Raspberry Pi's up-to RPi 3 B+... I think that the problem actually existed in that case too, but it occurred only with a low frequency: I've seen this happen occasionally and I flashed quite a large number of cards (more than 200). |
I think I get away with editing |
Maybe the |
Great idea about setting passing the current date via the flashed image. A clock running behind in the order of minutes should be ok
… Op 4 aug. 2019 om 10:43 heeft Leon Kiefer ***@***.***> het volgende geschreven:
Maybe the fake-hwclock should be set by the flash tool. This will make the time offset only a few minutes, when you start the image after you flashed it on the sd card.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@StefanScherer @DieterReuter @Legion2 |
I think this is now fixed with hypriot/flash#162 and released in v1.12.0 and version 2.5.0 of flash tool. |
@Legion2 indeed. Closing |
Would it not be better to fix this in the cloud-init start up than in the flash tool? I came across this issue after having imaged 2 SD cards already and had several more to go. Since the flash tool is only *nix compatible, it isn't a real universal solution. |
I usually resolve with a configuration script, written with cloud-init If you want to use NTP (already installed with the last OS image) # Write config files
write_files:
- content: |
#!/bin/bash
# Force update time (NTP will be used instead of systemd-timesyncd). Ntp is installed by default on this image
systemctl stop ntp
ntpd -q -g
systemctl start ntp
# Wait for time update
sleep 5
# Start APT install
apt-get update -y
# Install packages
apt-get install -y ...............................
path: /scripts/init_config.sh
permissions: 0777 If you want to use the default NTP client (systemd-timesyncd) usually used with ubuntu/debian/raspbian you have to uninstall ntp package because you can not use both systems # Write config files
write_files:
- content: |
#!/bin/bash
# Set NTP with default systemd-timesyncd (and remove ntp package, because you can not use both) and reboot the service to force update the time
apt-get purge -y --auto-remove ntp
timedatectl set-ntp true
systemctl stop systemd-timesyncd
systemctl start systemd-timesyncd
# Wait for time update
sleep 5
# Start APT install
apt-get update -y
# Install packages
apt-get install -y ...............................
path: /scripts/init_config.sh
permissions: 0777 I usually use the second way if I don't need a full ntp client/server. Then you can run the script with cloud-init # Execute commands to complete initialization
runcmd:
# Pickup the hostname changes
- 'systemctl restart avahi-daemon'
# Activate WiFi interface (comment if you don't need it)
- 'ifup wlan0'
# Wait wifi connecting
- 'sleep 15'
# Execute the initial configuration
- [ bash, -c, "cd /scripts && ./init_config.sh" ] You can also put all your commands here if you like. I prefer separating the things putting them inside scripts, because I do also other configurations. If you want to install packages you need always to wait for the wifi coming up and then the time sync. P.S. If you want to install and enable byobu for a target user (not working if you use the cloud-init module) you can use apt install -y byobu
su target_user -c byobu-enable Hope this help. |
I used the new v1.11.0-rc3 image on RPi 3 B+ and the new RPi 4 B and they work but with a glitch.
I use the following (slightly minimised) version of my cloud-init yml file:
Notice the
date -s '24 Jul 2019 10:29'
command run in theruncmd
phase.When this line is omitted,
apt-get update
fails because the date and time is set approximately 3 days earlier than the actual date.If I run the
date
command right before setting the current time, it outputs the following:Sun 21 Jul 2019 04:47:52 PM CEST (to be complete: this is during a first boot at around 4:39 PM CET on July 24th).
I may be missing something obvious, but I have no clue what it could be.
This used to work flawlessly with older Hypriot images (e.g. version 1.10.0).
The text was updated successfully, but these errors were encountered: