Time is set to UNIX epoch due to read_persistent_clock being renamed to read_persistent_clock64
#488
Labels
in_fix_queue
will fix in next release
Comments
10 tasks
Robertof
added a commit
to Robertof/nixpkgs
that referenced
this issue
Apr 30, 2020
Without the `-f` flag, `resize2fs` checks that the last time where the filesystem was checked is greater or equal than the last time is mounted. This currently works due to a bug in `cptofs` (lkl/linux#488) and it breaks on slower systems when the last mount time is greater than 1970-01-01 00:00:01. To fix this, either we allow `fsck` to update the "last checked" timestamp on the filesystem, which requires to replace the `-n` option with `-y`, or we force `resize2fs` to skip these checks. Since we're only dealing with an image file which is checked immediately before resizing, it is safe to bypass this check as `fsck` will fail if the filesystem is unclean.
|
thanks for the report. We should/will fix this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi! I have been debugging a timing related issue recently which led me to investigate the matter further, and I found out the following.
In 9266178,
read_persistent_clockwas removed during the shift to 64 bit timestamps as it was no longer used, in an effort to prevent the Y38K problem.However, this change was never noticed downstream in the LKL repo, where the 32-bit
read_persistent_clockis still implemented, and never being used. The reason why no error is thrown even though the original function was renamed is becauseread_persistent_clock64has the__weakdescriptor, so the kernel is silently using the default implementation:https://github.com/lkl/linux/blob/8a1fc6c/kernel/time/timekeeping.c#L1476-L1489
All of this has caused the issue described in #158 to happen again -- i.e., the userspace kernel is not synchronizing its time with the host anymore, and starts its wall clock time from the UNIX epoch.
The text was updated successfully, but these errors were encountered: