My workaround for this kind of problem has been to store the clock value in a file during shutdown/reboot, and initially set the time to that value plus a small amount < reboot latency, before the root filesystem is checked.
This is far from ideal, but does ensure that most user software never sees a clock rollback. When (if) a network interface is finally brought up, the clock can be corrected if ntp is installed: this will always produce a roll-forward, never a roll-back. Could we tweak /etc/init/hwclock.conf to use this as a fallback? It's debatable whether this should be enabled by default though: as for e2fsck, on a "working" system, it may be better to flag up unexpected clock rollbacks rather than silently patching it up. Cheers ---Dave -- Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem https://bugs.launchpad.net/bugs/563618 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
