Plz help, l can't fix this stupid date and time on my Ubuntu 24.04.2 LTS server

[SweetVanilla]

l can't seem to get all the time right on my ubuntu server and its extremely frustrating.

 

 

Ubuntu 24.04.2 LTS server fresh install today. I had similar troubles with every single linux install that l had installed over the pass 2 days. Trying to setup a NAS running samba for file sharing and a jellyfin for media streaming on local network Wanted to install a password manager but kept running into problems installing docker, now l know why lol.

 

Specs

• CPU - AMD Phenom 9750 2.4Ghz base
• AM - Random assortment of kingston memory 4 sticks of 2gb (8gb total) ddr2 running at stock 660-something speed
• MOTHERBOARD- GA-MA780G-UD3H
• GPU - Radeon r7 250 l think
• POWER SUPPLY 650w bronze msi
• SSD 250gb
• Hard drive 350gb Raid 1 configured

 

 

summers-server@summer:~$ sudo timedatectl set-ntp false

summers-server@summer:~$ sudo timedatectl set-time "2025-04-28 04:14:30"

summers-server@summer:~$ timedatectl

Local time: Mon 2025-04-28 04:14:39 AEST

Universal time: Sun 2025-04-27 18:14:39 UTC

RTC time: Sun 2025-04-27 18:14:39

Time zone: Australia/Sydney (AEST, +1000)

System clock synchronized: no

NTP service: inactive

RTC in local TZ: no

summers-server@summer:~$ sudo apt-get update

Ign:1 http://au.archive.ubuntu.com/ubuntu noble InRelease

Ign:2 http://security.ubuntu.com/ubuntu noble-security InRelease

Ign:3 http://au.archive.ubuntu.com/ubuntu noble-updates InRelease

Ign:4 http://au.archive.ubuntu.com/ubuntu noble-backports InRelease

Ign:1 http://au.archive.ubuntu.com/ubuntu noble InRelease

Ign:2 http://security.ubuntu.com/ubuntu noble-security InRelease

Ign:3 http://au.archive.ubuntu.com/ubuntu noble-updates InRelease

Ign:4 http://au.archive.ubuntu.com/ubuntu noble-backports InRelease

Ign:1 http://au.archive.ubuntu.com/ubuntu noble InRelease

Ign:2 http://security.ubuntu.com/ubuntu noble-security InRelease

Ign:3 http://au.archive.ubuntu.com/ubuntu noble-updates InRelease

Ign:4 http://au.archive.ubuntu.com/ubuntu noble-backports InRelease

Err:1 http://au.archive.ubuntu.com/ubuntu noble InRelease

Temporary failure resolving 'au.archive.ubuntu.com'

Err:2 http://security.ubuntu.com/ubuntu noble-security InRelease

Temporary failure resolving 'security.ubuntu.com'

Err:3 http://au.archive.ubuntu.com/ubuntu noble-updates InRelease

Temporary failure resolving 'au.archive.ubuntu.com'

Err:4 http://au.archive.ubuntu.com/ubuntu noble-backports InRelease

Temporary failure resolving 'au.archive.ubuntu.com'

Reading package lists... Done

W: Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/noble/InRelease Temporary failure resolving 'au.archive.ubuntu.com'

W: Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/noble-updates/InRelease Temporary failure resolving 'au.archive.ubuntu.com'

W: Failed to fetch http://au.archive.ubuntu.com/ubuntu/dists/noble-backports/InRelease Temporary failure resolving 'au.archive.ubuntu.com'

W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/InRelease Temporary failure resolving 'security.ubuntu.com'

W: Some index files failed to download. They have been ignored, or old ones used instead.

summers-server@summer:~$)

 

 

Can't get the RTC time, Local or universal time to be correct nor am able to synchronise with the system clock. I've tried a bunch of commands and tried to fix it but no luck. I don't know what else to do. Reinstalling wouldn't fix anything, i'd run into the same problem. I had to set my bios clock 2hs forward just for the installation to find packets because everytime l booted Ubuntu 24.04.2 LTS server, it put my bios clock 2hs back.

 

 

[Kilrah]

Are you dual booting with Windows?

[SweetVanilla]

17 minutes ago, Kilrah said:

Are you dual booting with Windows?

No.

[BoomerDutch]

1 hour ago, SweetVanilla said:

No.

You can try fix ntp server instead after quick chatgpt answer.

Quote

To sync time with an NTP (Network Time Protocol) server on Ubuntu Server, you can use the `timedatectl` command or the `ntp` package.

You can ask chatgpt yourself to figure it out, however it is strange that it isn't correct time. Are you connected to the wrong ntp server by chance?

 

Good luck.

[NoLeafClover]

Welcome to the world of *buntu - endless problems

 

More on topic, "Temporary failure resolving 'au.archive.ubuntu.com'" seems to suggest DNS issues. It would then not be so surprising that NTP doesn't work either, as usually IPs of servers within an NTP pools are accessed through DNS records, instead of being hardcoded.

 

Have you tried to see if your DNS resolvers have been configured properly and work?

 

You can use something like "nslookup google.com" to see if an IP address is returned. You can also see the status of your DNS resolvers through "resolvectl status".

 

If there's a significant time skew, DNS resolvers that employ DNSSEC may block DNS queries as they also validate the time and expect a relatively small skew margin. But they should start working as soon as you set the correct time with "timedatectl set-time".

 

15 hours ago, SweetVanilla said:

Can't get the RTC time, Local or universal time to be correct

What leads you to that conclusion? From what you've shared, "timedatectl set-time" works as expected:

15 hours ago, SweetVanilla said:

summers-server@summer:~$ sudo timedatectl set-time "2025-04-28 04:14:30"

summers-server@summer:~$ timedatectl

Local time: Mon 2025-04-28 04:14:39 AEST

Universal time: Sun 2025-04-27 18:14:39 UTC

RTC time: Sun 2025-04-27 18:14:39

Time zone: Australia/Sydney (AEST, +1000)

System clock synchronized: no

NTP service: inactive

RTC in local TZ: no

All of the highlighted entries are correct. Provided your timezone (Australia/Sydney) is correct, then the entries have indeed updated to the value you supplied.

[y0ur5h4d0w]

On 4/28/2025 at 8:59 AM, SweetVanilla said:

Temporary failure resolving 'au.archive.ubuntu.com'

Err:2 http://security.ubuntu.com/ubuntu noble-security InRelease

Temporary failure resolving 'security.ubuntu.com'

Err:3 http://au.archive.ubuntu.com/ubuntu noble-updates InRelease

Temporary failure resolving 'au.archive.ubuntu.com'

Err:4 http://au.archive.ubuntu.com/ubuntu noble-backports InRelease

Temporary failure resolving 'au.archive.ubuntu.com'

the errors that apt spits out here sounds more like a DNS issue, check your DNS servers, i had an issue where in one of my ubuntu installs (fresh) the DNS for some reasons were set to 127.0.0.52 and i couldn't update anything even if i had a correct IP. For some reasons the DNS servers might be corrupted, try changing them to google ones and you will proably fix the issue

 

if i recall correctly NTP is tied to an FQDN too so if you feel that the NTP time is not correct/not working checking for DNS entries might fix even this issue

[NoLeafClover]

1 hour ago, y0ur5h4d0w said:

the errors that apt spits out here sounds more like a DNS issue

Agree, though not necessarily - see my response above re DNSSEC.

 

1 hour ago, y0ur5h4d0w said:

i had an issue where in one of my ubuntu installs (fresh) the DNS for some reasons were set to 127.0.0.52 and i couldn't update anything even if i had a correct IP

This is normal on modern distros with systemd and does not [usually] cause issues. 127.0.0.52 is a loopback IP address (same as 127.0.0.1) and will point to systemd's stub resolver. The stub resolver will then "pass through" the DNS query to the configured DNS servers which could be either systemd internal ones (especially if using systemd-resolved) or as configured by whatever tool is managing the network interface (e.g. NetworkManager or systemd-networkd). "resolvectl status" will give details about the exact configuration.

 

This is one of the [many] frustrations systemd opponents have against systemd and its ever growing scope creep of responsibilities. And if a problem arises, it becomes more difficult to trace. When the above behaviour is enabled, manual changes to "/etc/resolve.conf" are likely to be overwritten by systemd the next time the machine is rebooted.

 

1 hour ago, y0ur5h4d0w said:

if i recall correctly NTP is tied to an FQDN too

Yes, usually, something like 0.de.pool.ntp.org. Configuring specific server IP addresses is, however, allowed - just not default.

[kuva]

i fixed some time issues i was having on a proxmox box by fixing broken DNS settings.. i'd reccomend looking at that

[SweetVanilla]

On 4/28/2025 at 8:24 PM, BoomerDutch said:

You can try fix ntp server instead after quick chatgpt answer.

You can ask chatgpt yourself to figure it out, however it is strange that it isn't correct time. Are you connected to the wrong ntp server by chance?

 

Good luck.

 

On 4/29/2025 at 7:59 AM, NoLeafClover said:

Welcome to the world of *buntu - endless problems

 

More on topic, "Temporary failure resolving 'au.archive.ubuntu.com'" seems to suggest DNS issues. It would then not be so surprising that NTP doesn't work either, as usually IPs of servers within an NTP pools are accessed through DNS records, instead of being hardcoded.

 

Have you tried to see if your DNS resolvers have been configured properly and work?

 

You can use something like "nslookup google.com" to see if an IP address is returned. You can also see the status of your DNS resolvers through "resolvectl status".

 

If there's a significant time skew, DNS resolvers that employ DNSSEC may block DNS queries as they also validate the time and expect a relatively small skew margin. But they should start working as soon as you set the correct time with "timedatectl set-time".

 

What leads you to that conclusion? From what you've shared, "timedatectl set-time" works as expected:

All of the highlighted entries are correct. Provided your timezone (Australia/Sydney) is correct, then the entries have indeed updated to the value you supplied.

 

On 4/29/2025 at 11:52 PM, y0ur5h4d0w said:

the errors that apt spits out here sounds more like a DNS issue, check your DNS servers, i had an issue where in one of my ubuntu installs (fresh) the DNS for some reasons were set to 127.0.0.52 and i couldn't update anything even if i had a correct IP. For some reasons the DNS servers might be corrupted, try changing them to google ones and you will proably fix the issue

 

if i recall correctly NTP is tied to an FQDN too so if you feel that the NTP time is not correct/not working checking for DNS entries might fix even this issue

 

On 4/30/2025 at 12:59 AM, NoLeafClover said:

Agree, though not necessarily - see my response above re DNSSEC.

 

This is normal on modern distros with systemd and does not [usually] cause issues. 127.0.0.52 is a loopback IP address (same as 127.0.0.1) and will point to systemd's stub resolver. The stub resolver will then "pass through" the DNS query to the configured DNS servers which could be either systemd internal ones (especially if using systemd-resolved) or as configured by whatever tool is managing the network interface (e.g. NetworkManager or systemd-networkd). "resolvectl status" will give details about the exact configuration.

 

This is one of the [many] frustrations systemd opponents have against systemd and its ever growing scope creep of responsibilities. And if a problem arises, it becomes more difficult to trace. When the above behaviour is enabled, manual changes to "/etc/resolve.conf" are likely to be overwritten by systemd the next time the machine is rebooted.

 

Yes, usually, something like 0.de.pool.ntp.org. Configuring specific server IP addresses is, however, allowed - just not default.

 

On 4/30/2025 at 9:17 AM, kuva said:

i fixed some time issues i was having on a proxmox box by fixing broken DNS settings.. i'd reccomend looking at that

Yeah so uhhhhhhhhhhh. I just replaced the CMOS battery because l was having problems with it. I reset my router configuration and made a lot of adjustments and reinstalled the OS and everything works fine now.... My guess is.... Au server repositories were down? Even tho l changed the repositories to US and it still didn't work... Incorrect Dns configuration on my router not aliened with my ubuntu server? I don't fucking know lmao. I'm just glad its fixed. Thanks all for the help!