Fix apt "invalid for another" or "unable to fetch packages" error

The issue

Can’t run sudo apt update or sudo apt-get update because you’re getting errors that look like the following in WSL?

1 2 3

E: Release file for http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease is not valid yet (invalid for another 27min 35s). Updates for this repository will not be applied. E: Release file for http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease is not valid yet (invalid for another 7min 28s). Updates for this repository will not be applied. E: Release file for http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease is not valid yet (invalid for another 8min 8s). Updates for this repository will not be applied.

How about Ubuntu apt-get unable to fetch packages? Well, this guide should help.

The solution

Well, the answer is simple. WSL has its time desynchronized from Windows. Simply run:

1 2	sudo apt install ntpdate sudo ntpdate -v pool.ntp.org

And you should now be able to run

1 2 3

sudo apt update # or sudo apt upgrade

to your hearts content.

Heck, sometimes even just installing other software using dpkg fails.

What causes the WSL time desync?

WSL has a clock, but it isn’t truly independent of Windows. In WSL 1 the Linux clock and the Windows clock shared the same underlying system time, so they never drifted. In WSL 2, Linux runs inside a lightweight virtual machine with its own kernel, and that VM has to keep its clock in sync with the host (Windows) by periodically asking the hypervisor for the current time.

A few common reasons the sync goes wrong:

• Suspended laptop or hibernation. When Windows sleeps, WSL pauses. When it wakes, the VM resumes from when it was paused, but the host clock has moved on. The two clocks can be hours or days apart.
• Dual-boot and BIOS time mismatch. Linux expects the hardware clock to be in UTC; Windows assumes local time. If Windows is set to local time, every boot puts WSL 2 minutes (or hours) off from real time.
• Timezone misconfiguration. WSL inherits its timezone from Windows. If Windows is wrong, WSL is wrong.
• Hyper-V clock drift on long-running VMs. WSL 2 instances that stay up for weeks can drift by a few seconds to a few minutes due to how the virtualized TSC clock is emulated.

Why does Windows time matter to Linux?

Apt, dpkg, and most package management tools use PGP signatures and expiry windows to validate the Release and InRelease files. Those files have a Valid-Until header. If the clock on your system is set to a time before that header, apt considers the file “not valid yet” and refuses to use it as a security precaution. The repository mirror hasn’t actually expired - your clock just thinks it has.

A few minutes of drift is fine. Hours of drift is what produces the error above. The fix is to make Linux agree with the real-world time, which is most easily done by pointing it at NTP.

Making the time fix permanent

The ntpdate solution above is a one-shot fix. If you keep hitting the same error every few weeks, make it stick:

1. Enable the systemd time sync in WSL. In recent WSL builds you can run:
   

   1	sudo systemctl enable --now systemd-timesyncd

   This keeps the clock synced automatically.
2. Or add a cron job. Edit your crontab with sudo crontab -e and add:

   
       
           
       
       0 * * * * /usr/sbin/ntpdate -q pool.ntp.org >/dev/null 2>&1
   

   This syncs the clock once an hour.
3. Or fix it on the Windows side. WSL 2 syncs its clock from the Windows host. Make sure Windows itself is set to sync time automatically: Settings → Time & Language → Date & Time → Set time automatically = On.

If you dual-boot, set Windows to use UTC for the hardware clock:

1. Open an elevated command prompt in Windows.
2. Run:
   

   1	reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

3. Reboot. From now on, both Linux and Windows will agree on the clock, and WSL won’t drift.

ALSO

Have a look at the time on Windows, vs a clock or phone. Is it the same? Make sure to double-check your Windows time and timezone, even if you think it’s correct!

Other solutions

The above worked for me, but these are the other solutions I found while trying to fix this.

1 2 3 4 5

sudo nano /etc/resolv.conf # Now add the following, Save with Ctrl+S, Ctrl+X, and try again nameserver 8.8.8.8 nameserver 8.8.4.4

1	sudo hwclock -s

1 2	# As a temporary workaround apt-get -o Acquire::Check-Valid-Until=false -o Acquire::Check-Date=false update

Other common WSL networking issues

If apt update is failing for reasons unrelated to time, these are the next things to check:

• DNS resolution failing inside WSL. The resolv.conf fix above (forcing Google DNS) is the most common workaround. WSL has a long-standing quirk where the DNS configuration it auto-generates from Windows can point at addresses that the WSL2 NAT can’t reach, especially on corporate networks and VPNs.
• WSL can’t reach the internet at all. Restart WSL with wsl --shutdown from PowerShell, then relaunch your distro. This refreshes the virtual network adapter.
• Slow or hanging package downloads. WSL 2’s NAT can be slow on certain Wi-Fi drivers. Switching to the mirrored network mode (.wslconfig with networkingMode=mirrored, available in WSL 2.0+ and Windows 11 22H2+) often fixes sluggish downloads.
• “Temporary failure resolving archive.ubuntu.com”. Almost always DNS. Same fix - hard-code nameserver 8.8.8.8 in /etc/resolv.conf.