Release file for repository is not valid yet

[salaxander]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

Please fill out the below information:

• Your Windows build number: Microsoft Windows [Version 10.0.18917.1000]

• What you're doing and what's happening: Attempting to run a sudo apt update within a WSL 2 installation. Seeing thing following error

[sudo] password for xander: Hit:1 https://packages.microsoft.com/repos/azure-cli bionic InRelease Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease Get:3 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB] Hit:5 http://archive.ubuntu.com/ubuntu bionic-backports InRelease Get:4 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] Reading package lists... Done E: Release file for http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease is not valid yet (invalid for another 10h 29min 48s). Updates for this repository will not be applied. E: Release file for http://archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease is not valid yet (invalid for another 11h 0min 22s). Updates for this repository will not be applied.

Based on my own searching, I suspect the WSL clock may be falling out of sync with my windows machine? Though trying to cat /etc/localtime causes WSL to hang

• What's wrong / what should be happening instead: apt should run an update with no error output

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).

• For WSL launch issues, please collect detailed logs.

See our contributing instructions for assistance.

[benhillis]

What do the following commands return?

date
cmd.exe /c time /t
readlink /etc/localtime

What is your Windows timezone? Any interesting errors in sudo dmesg?

[salaxander]

Thanks for the reply!

~ date 
Wed Jun 12 19:29:19 PDT 2019 

~ cmd.exe /c time /t
 '\\wsl$\Ubuntu\home\xander'
CMD.EXE was started with the above path as the current directory. 
UNC paths are not supported.  Defaulting to Windows directory.
09:14 AM

~ readlink /etc/localtime
 /usr/share/zoneinfo/America/Los_Angeles

The only thing that catches my eye in sudo dmesg is

[    0.606657] hv_utils: cannot register PTP clock: 0

[benhillis]

Interesting, not only is the hour wrong, the minutes is way off as well...

Thanks, does Ameria/Los_Angeles match your Windows time zone (Pacific)?

[salaxander]

It does indeed! For what it's worth, I was also selfhosting a build with WSL 2 about a month ago (I work at Microsoft 😄), and I encountered the same issue, sorry for not reporting it to the team sooner!

[trondhindenes]

Can repro. My windows computer is in CET, but WSL2 gives a completely different utc time altho /etc/localtime seems to be correctly set to Europe/Berlin

[benhillis]

This seems to have to do with clock drift. If you shut down wsl and restart, is the problem solved?

wsl.exe --shutdown

[salaxander]

That does seem to resolve the issue for now. Running date shows the correct time. I'm still seeing [ 0.531827] hv_utils: cannot register PTP clock: 0 when running a sudo dmesg though (not sure if that's consequential or not). I'll report back if things fall out of sync again.

[therealkenc]

Laptop? Did it sleep? Maybe related this. WAG.

[mithunshanbhag]

Running into this same issue when running sudo apt update && sudo apt upgrade (Ubuntu 18.04 with WSL2 on windows insider build 18917.1000 on Macbook air).

Definitely some clock drift issue as the date command is returning the wrong time.

Shutting down WSL2 (wsl --shutdown) and rerunning the apt update command seems to fix it for now.