Bug #12769
closedZFS installations without an RTC battery boot with clock at BIOS/EFI default value because they do not receive initial clock value from filesystem data
100%
Description
Already fixed and covered by NG 7447 but adding here so it goes in the release notes.
Systems without an RTC battery boot with their clock at the BIOS/EFI default which, depending on implementations, may be ~1970 (UNIX timestamp 0) or a BIOS/EFI build minimum value. If FreeBSD boots with a UFS volume it reads a mount time value from UFS which populates a default value for the clock which is more reasonable than the default. ZFS does not pass such a value on to the OS so the clock remains very far out of sync.
From here it ends up in a chicken-and-egg scenario: NTP can't sync the clock because DNS fails and DNS fails because NTP can't sync the clock. NTP would normally take care of this but it requires working DNS resolution. The DNS Resolver is enabled by default with DNSSEC on. With the clock so far out of sync, DNSSEC will fail and NTP cannot resolve a hostname to locate servers, thus the clock remains out of sync.
We need to take multiple steps to work around this problem during each boot sequence:
1. Check a few commonly modified files on the filesystem and set the clock to whichever is the newest if it's also newer than the clock: 42ed3b9d540c101617eaa00581c527673f6206a2
2. Do a one-time NTP sync to a list of static IP address servers from Google Public DNS which sidesteps the DNSSEC issue: 4745879c9967682624a2e87e190ebc12ba6f985b
There is a manual way to override the NTP sync if people do not want their firewalls to contact those servers at boot. It can be disabled or pointed to alternate static IP address NTP servers. See the comments in the commit above, and it will be in the docs soon.