Re: buster netinst timezone
On Mon 12 Aug 2019 at 08:38:47 (-0400), Greg Wooledge wrote:
> On Sat, Aug 10, 2019 at 12:16:04PM -0500, David Wright wrote:
> > If you're desparate to get the timezone altered earlier in your
> > installation process, you could always do it manually: try switching
> > to VC2 and editing the file /target/etc/timezone to the string UTC
> > (the alternatives are simply the names of the files in
> > /usr/share/zoneinfo, including subdirectories). Obviously wait until
> > the file exists. (I've not tried this so I don't know when that is.)
>
> I'm skeptical that this would be sufficient. Debian actually stores the
> system's default timezone in *two* different places, using two completely
> different mechanisms. I have been led to believe that one of these is
> "standard" for GNU/Linux-based systems, and the other is for backward
> compatibility.
Yes, you're right.
> wooledg:~$ ls -ld /etc/*time*
> -rw-r--r-- 1 root root 46 Apr 10 2017 /etc/adjtime
> lrwxrwxrwx 1 root root 36 Apr 1 08:58 /etc/localtime -> /usr/share/zoneinfo/America/New_York
> -rw-r--r-- 1 root root 17 Apr 1 08:58 /etc/timezone
>
> The first one is the /etc/timezone file, which as you say, is a
> simple text file that a (root) user can edit. I believe this is the
> backward-compatibility one.
And that's the one I find useful, in that a lot of applications honour
a value for TZ, which needs to be the text version. I always have a
link to /etc/timezone as ~/.timezone, and TZ is set to its value in
my startup files, which makes it easy to run a session in a
contradictory timezone if I wish.
> The second one is the /etc/localtime symbolic link, which needs to point
> to an existing binary time zone data file in /usr/share/zoneinfo. The
> symbolic link can be re-pointed by hand; the binary data file should not
> be edited by hand.
I assume the system is interested in this one because it needs the
actual rules and not just the name of the timezone. Otherwise the
system wouldn't be able to junp the clocks at the appropriate times.
> Running dpkg-reconfigure tzdata changes both of these, so that all the
> programs work, regardless of which one they choose to honor. Manually
> changing just *one* of them would probably leave the system in an
> inconsistent state, where some programs display the correct time zone,
> and others do not.
Well, a system running on a UTC hardware clock might have different
applications displaying different times, and writing their logs
accordingly, but the effects shouldn't be damaging. In fact, that
is exactly what is happening during the installation itself: the
major part of the log is in UTC, interspersed with segments in
local time from the likes of useradd and groupadd.
I couldn't speak for users who have a non-UTC clock.
I would expect anyone using my desparate [sic] tip would confirm
their timezone in the Debian™ manner as soon as practicable.
I just checked the link/file on a recently-installed buster, and the
timestamps indicate that they're created at the start of the main
tranche of package installation, when /var/log/syslog shows¹
Aug 22 01:19:31 in-target: Setting up tzdata (2019b-0+deb10u1) ...
Aug 22 01:19:31 in-target:
Aug 22 01:19:33 in-target:
Aug 22 01:19:33 in-target: Current default time zone: 'America/Chicago'
Aug 22 01:19:33 in-target: Local time is now: Wed Aug 21 20:19:33 CDT 2019.
Aug 22 01:19:33 in-target: Universal Time is now: Thu Aug 22 01:19:33 UTC 2019.
Aug 22 01:19:33 in-target: Run 'dpkg-reconfigure tzdata' if you wish to change it.
Aug 22 01:19:33 in-target:
Aug 22 01:19:33 in-target: Setting up linux-image-4.19.0-5-686-pae (4.19.37-5+deb10u2) ...
As dpkg gets set up around the same point, I suppose one could try running
# /target/usr/sbin/dpkg-reconfigure tzdata
in a VC at any time after this, though one might need to wait for a
pause in proceedings (like the popcon question) to avoid any file locking.
AFAICT the clock question at the end (UTC yes/no) only involves adjtime.
> I don't have any kind of statistics for how many programs use one vs.
> the other. It's not trivial to find out.
I guess it ought to depend on whether the program is concerned only
with the here and now (use timezone), or whether it takes into account
past history. Precisely 24 weeks ago, the wall time was the same in
the afternoon as now (though someone in the UK would disagree).
25 weeks ago, it was still morning, an hour earlier. For that
determination, you want the file pointed to by localtime.
¹ Note that tzdata gets installed and set up twice, the first time
being the .deb from the iso, the second from the mirror. The log from
the first time looks like
Aug 22 00:56:21 debootstrap: Setting up tzdata (2019a-1) ...
Aug 22 00:56:23 debootstrap:
Aug 22 00:56:23 debootstrap: Current default time zone: 'Etc/UTC'
Aug 22 00:56:23 debootstrap: Local time is now: Thu Aug 22 00:56:23 UTC 2019.
Aug 22 00:56:23 debootstrap: Universal Time is now: Thu Aug 22 00:56:23 UTC 2019.
Aug 22 00:56:23 debootstrap: Run 'dpkg-reconfigure tzdata' if you wish to change it.
Aug 22 00:56:23 debootstrap:
Aug 22 00:56:23 debootstrap: Setting up libpam0g:i386 (1.3.1-5) ...
Cheers,
David.
Reply to: