After upgrading 13.0 to 13.1 date is changing

I using command date 2205210031. I have been upgrading the system consistently since version 10.0. This has never happened before.
Maybe that's why after updating the system, ssh did not work?
 
I've recently done this upgrade, I'm only looking for NTP client (I use openntpd instead of base ntp) and don't have any issues.
If base ntpd, what does the output of "ntpq -pn" show?
How about "service ntpd status"?
 
% sudo service ntpd start
Starting ntpd.
ntpd error: only one pidfile option allowed
ntpd - NTP daemon program - Ver. 4.2.8p15
Usage: ntpd [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \
[ <server1> ... <serverN> ]
Try 'ntpd --help' for more information.
/etc/rc.d/ntpd: WARNING: failed to start ntpd.

But the hardware time, even without ntpd should not be reset after a system upgrading.
I have some applications stopped working due to fantastically wrong time :)
 
That sounds like a bad option being passed to ntpd. How about the output of the following commands:
grep -i ntp /etc/rc.conf
grep -i ntp /etc/defaults/rc.conf

variables defined in these 2 files are used in the init script so maybe a merge went wrong.

Hardware time:
If your hardware clock is set to GMT and NTP is not running, your applications could see the wrong time. Depending on how many timezones you are away from GMT it could be fantastically wrong :)
 
kerogaz
As a new member to the FreeBSD forums be cordially welcomed.
Please take some time for reading
You will earn some "reaction score" for applying the BB-Codes to the postings you made. :)

Your problem is very probably related to the configuration of ntpd(8).

In /etc/rc.conf you should have
Code:
ntpd_sync_on_start="YES"
ntpd_enable="YES"

And please post /etc/ntp.conf
 
I lost my timezone config on upgrade, nothing a quick re-run of tzsetup(8) can't solve.

But a wrong timezone won't lead to a different month or year :what: So I have doubts this issue can be directly related to upgrading. Maybe (just speculation), the hardware clock was always wrong, but ntpdate/ntp silently fixed it on boot before you upgraded...
 
But I do not use ntp : I set the time in version 10.0 manually and from that moment I upgraded the system sequentially to 13.0. Time lost only after upgrading to 13.1. If you are not interested, then I will not write to you anymore.But now ,after such collisions of time, I ran ntpd just in case.
Code:
pal@boss:~ % service ntpd status
ntpd is running as pid 89859.
 
Maybe of interest, although I should not rush to assume the same cause(s): Some problems in setting the year : freebsd

… i got automatically 2276 instead of the right year. on freebsd 13.0 it was working fine …



… after updating the system, ssh did not work? …

 
pal@boss:~ % date
Thu Jan 8 16:37:21 EET 2015.
Probably ntp also stopped working after the system upgrade
But I do not use ntp [...]
These statements about ntp usage seem contradictionary; please clarify your ntp(d) intentions. Furthermore, it would be helpful if you posted the details about the requested ntp settings others asked—if you intend to use ntp.
 
Last edited:
I upgraded 3 VMs yesterday. Today a cron job did not run and gave the following output after I ran it manually:
Code:
]# /usr/local/bin/poudriere jail -uj 13amd64 && cd / && /usr/sbin/pkg upgrade -y && /usr/local/bin/poudriere ports -up local && /usr/local/bin/poudriere bulk -j 13amd64 -p local -z kjpservers -f /usr/local/etc/poudriere.d/13amd64-local-kjpservers-pkglist
[00:00:00] Upgrading using ftp
/etc/resolv.conf -> /usr/local/poudriere/jails/13amd64/etc/resolv.conf
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 13.1-RELEASE-p0.

WARNING: FreeBSD 13.1-RELEASE HAS PASSED ITS END-OF-LIFE DATE.
Any security issues discovered after Fri May 31 23:59:59 UTC 2024
will not have been corrected.
13.1-RELEASE
[00:00:07] Recording filesystem state for clean... done
Updating custom repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01   
Fetching packagesite.pkg: 100%   44 KiB  44.7kB/s    00:01   
Processing entries: 100%
custom repository update completed. 140 packages processed.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
[00:00:00] Updating portstree "local" with portsnap...Looking up portsnap.FreeBSD.org mirrors... 4 mirrors found.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org... done.
Snapshot appears to be more than a year old!
(Is the system clock correct?)
Cowardly refusing to proceed any further.
[00:00:00] Error:  fail
[root@zzzz /]# date
Tue Aug 26 17:46:16 BST 2194

The time zone is correct but I must have overslept last night somewhat!

This can only by a type change in timestamp format (signed v unsigned or something like that). All my VMs give the same result. I daren't reset the clock for fear of upsetting my host system. NTP can do nothing about such a large deviation.

It appears 13.1-RELEASE might not be ready for deployment because its timestamp parsing doesn't match other OSes preventing it being used in VM environments alongside other systems.
 
Are you using ntpd from the base or openntpd as a client?
What does your ntp.conf look like?
I'm using openntpd from pkgs as a client and had zero issues updating 2 systems. But I am in EST.
What about any flags passed to ntp from rc.conf?
Is NTP actually running in the VMs?
In the past, when having weird issues, I have stopped the ntpd service ,then go over to /var/db (it may be in /var/db/ntp) and deleted ntpd.drift
and then restarted ntpd service. Doing this seemed to clear things up.
 
The last reply in the Reddit thread put me on to my problem. VirtualBox with KVM Paravirtualisation interacts badly with 13.1-RELEASE. I changed the VB setting to HyperV and all is well again. Not sure whether that does anything since neither system runs Windows, but hey ho, it's working.

(Now watch the long discussion between FreeBSD and Oracle about whose code is at fault here!)

Update: now changed to "Default" as that's apparently the one to use if uncertain about which is correct.
 
Back
Top