Solved Timezone lost on upgrade to 13.2

zirias@

zirias@

Developer
I just upgraded my desktop to 13.2-RELEASE
  • from source (it was pre-built into /usr/obj on a different machine)
  • into a new BE, not activated but just mounted with bectl mount
Did it all in one batch (installkernel, installworld, etcupdate, delete-old[-libs], pkg upgrade -f), rebooted only after that. And all went perfectly fine, just one quick reboot.

Except: After a while, I noticed my clock was showing UTC. Which was quickly fixed running tzsetup(8) of course, unfortunately I was too quick and didn't take the chance to analyze what exactly was wrong (/etc/localtime missing? or linking to the wrong file? or a copy of the wrong file?).

So, anyone else ever experienced this? Is this a gotcha specifically upgrading to 13.2? Or is it maybe related to using etcupdate(8) with the -D flag to update a system that isn't currently running? I'm just curious here, have a few other machines to upgrade soon and will of course pay attention myself...
 
I have seen issues of time on FreeBSD & Linux.
I only know three things.
-run an ntp client.
-set /etc/localtime as softlink as softlink to the timezone.
-run "adjkerntz -a" regularly.
 
Code: 
root@FBSD13-2RC6:/home/userx # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.2-RC6 from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 13.2-RC6-p0.

WARNING: FreeBSD 13.2-RC6 is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 weeks.
Code: 
root@FBSD13-2RC6:/home/userx #  freebsd-update -r 13.2-RELEASE upgrade
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 13.2-RC6 from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base world/lib32

The following components of FreeBSD do not seem to be installed:
kernel/generic-dbg world/base-dbg world/lib32-dbg

Does this look reasonable (y/n)?

To install the downloaded upgrades, run "/usr/sbin/freebsd-update install". root@FBSD13-2RC6:/home/userx # /usr/sbin/freebsd-update install Installing updates... Kernel updates have been installed. Please reboot and run "/usr/sbin/freebsd-update install" again to finish installing updates.

reboot

Code: 
root@FBSD13-2RC6:/home/userx # /usr/sbin/freebsd-update install
Installing updates...
Restarting sshd after upgrade
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 15224, 15224.
Performing sanity check on sshd configuration.
Starting sshd.
Scanning //usr/share/certs/blacklisted for certificates...
Scanning //usr/share/certs/trusted for certificates...
Scanning //usr/local/share/certs for certificates...
 done.
root@FBSD13-2RC6:/home/userx # uname -a
FreeBSD FBSD13-2RC6.yeahbabyyeah 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64

date
Sun Apr 9 14:42:07 CDT 2023

maybe upgrade it like I just did?
 
All the zic and tzdata stuff changed. I can see how something timezone-ish could go wrong.

Having said that, I still have my old /etc/localtime .
 
zirias@ said:
Did it all in one batch (installkernel, installworld, etcupdate, delete-old[-libs], pkg upgrade -f), rebooted only after that. And all went perfectly fine, just one quick reboot.

Except: After a while, I noticed my clock was showing UTC. Which was quickly fixed running tzsetup(8) of course, unfortunately I was too quick and didn't take the chance to analyze what exactly was wrong (/etc/localtime missing? or linking to the wrong file? or a copy of the wrong file?).
Click to expand...

Do you run your CMOS clock in UTC, or in local standard time with the presence of /etc/wall_cmos_clock?

Both rely on /etc/localtime and both are equally valid, but if the latter, missing /etc/wall_cmos_clock breaks file timestamps.

Just a punt :)
 
smithi indeed missed to mention that, thanks. Hardware clock runs on UTC on all my machines ;)

So, a lot of changes in 13.2 means it could be related to that. I wonder whether it also could have been a side-effect of upgrading "offline" (inactive boot environment) :-/

I'll update at least two more machines using the same procedure, so maybe I'll see myself ;)
 
I just remembered I upgraded my server in the same way (to an inactive boot environment), so just checked the situation there: The timezone is still correct, /etc/localtime is a copy of the compiled zone info. But on my desktop, after running tzsetup(8) to fix the incorrect timezone, it's now a symlink.

So, more confused now than before....
 
Had a closer look now while upgrading my notebook in the same way. This is what I see with the new BE for 13.2 still mounted at /mnt/tmpdev after the full upgrade procedure:
Code: 
photon# ls -lh /mnt/tmpdev/etc/localtime 
-r--r--r--  1 root  wheel   2,2K 10 Apr. 10:50 /mnt/tmpdev/etc/localtime
photon# ls -lh /etc/localtime 
-r--r--r--  1 root  wheel   2,3K 19 Feb. 10:11 /etc/localtime

So, I think I can conclude: /etc/localtime is supposed to be a copy of the zone info (not a symlink) and the upgrade process from source handles it correctly, even with an "offline" upgrade.

Leaves me wondering why it broke on my desktop in the first place, and why tzsetup created a symlink there :-/ maybe I should just forget about it.
 
who was it in here that was lecturing me on upgrading and issues never happen when he does it on FreeBSD Oh yeah SirDice

"You must be doing something wrong. I've upgraded dozens of systems from 12.x to 13.x without any issue."

and It actually worked fine going from 13.2 RC1 to 6 then to Release this time. sorry, I just find this a bit ironic (?) to see this issue happening and he is not in here talking that to the OP too.what, I got the lecture and nobody else?
 
userxbw maybe because this here is more about a (strange) hickup I long since "fixed" easily and I'm just curious how it happened in the first place, explicitly NOT ruling out I might have messed something up (which is why I also described my custom method of upgrading)? Just maybe? 🤷‍♂️

Now I kindly ask you not to spam my thread.
 
  • Like
Reactions: mer
zirias@ said:
userxbw maybe because this here is more about a (strange) hickup I long since "fixed" easily and I'm just curious how it happened in the first place, explicitly NOT ruling out I might have messed something up (which is why I also described my custom method of upgrading)? Just maybe? 🤷‍♂️

Now I kindly ask you not to spam my thread.
Click to expand...
I said sorry because I know it is not pertaining to the exact isssue but the system had hiccups too that got that comment to me. so moving on
 
getopt said:
As we all know this is a Whac-A-Mole style problem here and elsewhere.
Click to expand...
"Just smile, you can't **** them all" 😏

getopt said:
This seams to be of utmost relevance, as here we talk about 13.2-RELEASE.
Click to expand...
Maybe just hissing the "SOLVED" flag would discourage more of these utmost relevant follow-ups? 😉

I mean, I can't even reproduce it myself now, upgrading more systems from the same /usr/obj using the very same method and steps ... still weird, but I'm now inclined to file this under "some weird shit just happens sometimes" :-/
 
zirias@ said:
Had a closer look now while upgrading my notebook in the same way. This is what I see with the new BE for 13.2 still mounted at /mnt/tmpdev after the full upgrade procedure:
Code: 
photon# ls -lh /mnt/tmpdev/etc/localtime
-r--r--r--  1 root  wheel   2,2K 10 Apr. 10:50 /mnt/tmpdev/etc/localtime
photon# ls -lh /etc/localtime
-r--r--r--  1 root  wheel   2,3K 19 Feb. 10:11 /etc/localtime

So, I think I can conclude: /etc/localtime is supposed to be a copy of the zone info (not a symlink) and the upgrade process from source handles it correctly, even with an "offline" upgrade.
Click to expand...

I've also had /etc/localtime be setup as a symlink to the /usr/share/zoneinfo/ $region/$city file - i.e. where tzsetup usually copies it from.

I remember being surprised too, but that wasn't either of my present laptops' versions nor was it recent, so I can't be more specific.

zirias@ said:
Leaves me wondering why it broke on my desktop in the first place, and why tzsetup created a symlink there maybe I should just forget about it.
Click to expand...

I only mention it to rule out any correlation with boot environments (UFS only), 13.x in particular (I'm on 12.4, 11.3 a year ago) with an offline laptop on 9.3)

Why tzsetup would choose to copy the zoneinfo file sometimes (usually?) but make a symlink to it at other times remains a mystery.

I doubt it matters, except perhaps if freebsd-update updated zoneinfo (as it has twice recently) without the user running tzsetup, then the symlink would actually be preferable, yeah?
 
You must log in or register to reply here.
Back
Top