I grabbed the last development ISO you made. In Calamares, I choose Europe/Paris to be my timezone. But on first start, displayed time is shifting by 2 hours.
The workaround was to install ntp and enter in a terminal: sudo ntpdate fr.pool.ntp.org
I tried to activate automatic sync for time in KDE date and time settings option, but I'm unable to activate this option.
So which ntp tool - ntp ? chrony ? openntpd ? - is used here and can be used to automatically sync your local
time ?
Thanks a lot for your answer.
Have a good day.
Steps to Reproduce
Grab last development ISO
Install it in a Virtual Machine
Set for a timezone, like Europe/Paris one
Look at time
Expected Behavior
No time shift.
Actual Behavior
Time is 2 hours in the future
Environment
ISO version: last one from July 28th
Install method: Calamares online
Desktop: KDE
Relevant Log Output
Code of Conduct
I agree to follow this project's Code of Conduct
### Description
Hello.
I grabbed the last development ISO you made. In Calamares, I choose Europe/Paris to be my timezone. But on first start, displayed time is shifting by 2 hours.
The workaround was to install ntp and enter in a terminal: sudo ntpdate fr.pool.ntp.org
I tried to activate automatic sync for time in KDE date and time settings option, but I'm unable to activate this option.
So which ntp tool - ntp ? chrony ? openntpd ? - is used here and can be used to automatically sync your local
time ?
Thanks a lot for your answer.
Have a good day.
### Steps to Reproduce
1. Grab last development ISO
2. Install it in a Virtual Machine
3. Set for a timezone, like Europe/Paris one
4. Look at time
### Expected Behavior
No time shift.
### Actual Behavior
Time is 2 hours in the future
### Environment
- ISO version: last one from July 28th
- Install method: Calamares online
- Desktop: KDE
### Relevant Log Output
```shell
```
### Code of Conduct
- [x] I agree to follow this project's Code of Conduct
hey fred, good catch — this was a real bug, now fixed.
short version: the iso ships ntp (ntp-dinit) but never enables the ntpd service at install time. so nothing ever syncs the clock. your vm's rtc holds local time (qemu likes -rtc base=localtime, and paris = utc+2 in summer) while linux treats /etc/adjtime as utc. so at boot it reads that paris value as utc and the clock lands 2h ahead. your ntpdate workaround is literally what ntpd does automatically — that's why it fixed the display.
fix is merged for the next dev iso: ntpd enabled in services-artix.conf (offline + online). first boot, as long as you have network, it corrects within seconds. no manual steps.
to your "ntp / chrony / openntpd?" — it's ntp (ntp-dinit). you don't need the others.
and the greyed-out kde "automatic sync" toggle: expected. that toggle controls systemd-timesyncd, but this is a dinit box — no systemd to drive it. time still syncs fine via ntpd, the toggle just has nothing to do. cosmetic.
if you can retest on the next dev iso (or on your current install: sudo dinitctl enable ntpd && sudo dinitctl start ntpd), the shift should be gone. thanks for the clean report — zero digging needed.
hey fred, good catch — this was a real bug, now fixed.
short version: the iso ships ntp (ntp-dinit) but never enables the ntpd service at install time. so nothing ever syncs the clock. your vm's rtc holds local time (qemu likes -rtc base=localtime, and paris = utc+2 in summer) while linux treats /etc/adjtime as utc. so at boot it reads that paris value as utc and the clock lands 2h ahead. your ntpdate workaround is literally what ntpd does automatically — that's why it fixed the display.
fix is merged for the next dev iso: ntpd enabled in services-artix.conf (offline + online). first boot, as long as you have network, it corrects within seconds. no manual steps.
to your "ntp / chrony / openntpd?" — it's ntp (ntp-dinit). you don't need the others.
and the greyed-out kde "automatic sync" toggle: expected. that toggle controls systemd-timesyncd, but this is a dinit box — no systemd to drive it. time still syncs fine via ntpd, the toggle just has nothing to do. cosmetic.
if you can retest on the next dev iso (or on your current install: sudo dinitctl enable ntpd && sudo dinitctl start ntpd), the shift should be gone. thanks for the clean report — zero digging needed.
Well, I still have to do a sudo ntpdate fr.pool.ntp.org to get the right time. Maybe the fix in the ISO is better than manually installing and enable ntpd.
And I'm used to write bug reports. 17 years of using Archlinux helps a little here :)
Well, I still have to do a sudo ntpdate fr.pool.ntp.org to get the right time. Maybe the fix in the ISO is better than manually installing and enable ntpd.
And I'm used to write bug reports. 17 years of using Archlinux helps a little here :)
Sorry to say that, but with last ISO from github action https://github.com/Antergos-NeXT/antergos-iso/actions/runs/31129619700 I still have a time shift. Ouch :(
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
Hello.
I grabbed the last development ISO you made. In Calamares, I choose Europe/Paris to be my timezone. But on first start, displayed time is shifting by 2 hours.
The workaround was to install ntp and enter in a terminal: sudo ntpdate fr.pool.ntp.org
I tried to activate automatic sync for time in KDE date and time settings option, but I'm unable to activate this option.
So which ntp tool - ntp ? chrony ? openntpd ? - is used here and can be used to automatically sync your local
time ?
Thanks a lot for your answer.
Have a good day.
Steps to Reproduce
Expected Behavior
No time shift.
Actual Behavior
Time is 2 hours in the future
Environment
Relevant Log Output
Code of Conduct
hey fred, good catch — this was a real bug, now fixed.
short version: the iso ships ntp (ntp-dinit) but never enables the ntpd service at install time. so nothing ever syncs the clock. your vm's rtc holds local time (qemu likes -rtc base=localtime, and paris = utc+2 in summer) while linux treats /etc/adjtime as utc. so at boot it reads that paris value as utc and the clock lands 2h ahead. your ntpdate workaround is literally what ntpd does automatically — that's why it fixed the display.
fix is merged for the next dev iso: ntpd enabled in services-artix.conf (offline + online). first boot, as long as you have network, it corrects within seconds. no manual steps.
to your "ntp / chrony / openntpd?" — it's ntp (ntp-dinit). you don't need the others.
and the greyed-out kde "automatic sync" toggle: expected. that toggle controls systemd-timesyncd, but this is a dinit box — no systemd to drive it. time still syncs fine via ntpd, the toggle just has nothing to do. cosmetic.
if you can retest on the next dev iso (or on your current install: sudo dinitctl enable ntpd && sudo dinitctl start ntpd), the shift should be gone. thanks for the clean report — zero digging needed.
Well, I still have to do a sudo ntpdate fr.pool.ntp.org to get the right time. Maybe the fix in the ISO is better than manually installing and enable ntpd.
And I'm used to write bug reports. 17 years of using Archlinux helps a little here :)
Sorry to say that, but with last ISO from github action https://github.com/Antergos-NeXT/antergos-iso/actions/runs/31129619700 I still have a time shift. Ouch :(