# After upgrading 13.0 to 13.1 date is changing



## kerogaz (May 20, 2022)

pal@boss:~ % date
Thu Jan  8 16:37:21 EET 2015.  
Probably ntp also stopped working after the system upgrade


----------



## kerogaz (May 20, 2022)

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?


----------



## mer (May 20, 2022)

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"?


----------



## kerogaz (May 21, 2022)

sudo service ntpd status
ntpd is not running.    Really not started


----------



## kerogaz (May 21, 2022)

% 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


----------



## mer (May 21, 2022)

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


----------



## getopt (May 21, 2022)

kerogaz
As a new member to the FreeBSD forums be cordially welcomed.
Please take some time for reading








						Formatting Guidelines
					

1. Please write as clearly as possible.  Use English punctuation and capitalization, and avoid abbreviating things.  This helps to improve the clarity of messages and make problems easier to solve.  2. Use BBCode formatting tags.  As with punctuation, these tags make messages easier to read...




					forums.freebsd.org
				











						BB codes
					

The list of BB codes you can use to spice up the look of your messages. This page shows a list of all BB codes that are available.




					forums.freebsd.org
				



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

```
ntpd_sync_on_start="YES"
ntpd_enable="YES"
```

And please post /etc/ntp.conf


----------



## zirias@ (May 21, 2022)

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  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...


----------



## Erichans (May 21, 2022)

Zirias said:


> But a wrong timezone won't lead to a different month or year


kerogaz, it might also be useful to check your CMOS battery for your RTC.


----------



## mer (May 21, 2022)

Zirias said:


> But a wrong timezone won't lead to a different month or year


Agreed, but all we have from the OP is "...fantastically wrong time" so we don't know if it's hours or months/years.


----------



## Erichans (May 21, 2022)

kerogaz said:


> pal@boss:~ % date
> Thu Jan  8 16:37:21 EET 2015.





mer said:


> Agreed, but all we have from the OP is "...fantastically wrong time" so we don't know if it's hours or months/years.


I'm counting more than 7 years ...


----------



## mer (May 21, 2022)

Sorry I never looked at what he showed us, only what he said


----------



## kerogaz (May 21, 2022)

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.

```
pal@boss:~ % service ntpd status
ntpd is running as pid 89859.
```


----------



## kerogaz (May 21, 2022)

Erichans said:


> kerogaz, it might also be useful to check your CMOS battery for your RTC.


Battery 3 V


----------



## grahamperrin@ (May 21, 2022)

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 …






kerogaz said:


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











						Solved - After upgrading from 13.0 to 13.1, ssh stopped working
					

kex_exchange_identification: Connection closed by remote host  /CODE]   But ping to remote host is working and ping from remote host to for exemple 8.8.8.8  is working




					forums.freebsd.org


----------



## Erichans (May 21, 2022)

kerogaz said:


> pal@boss:~ % date
> Thu Jan  8 16:37:21 EET 2015.
> Probably ntp also stopped working after the system upgrade





kerogaz said:


> 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.


----------



## kjpetrie (May 27, 2022)

I upgraded 3 VMs yesterday. Today a cron job did not run and gave the following output after I ran it manually:

```
]# /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.


----------



## mer (May 27, 2022)

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.


----------



## kjpetrie (May 27, 2022)

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.


----------

