timedatectl set-timezone fails on UC16

I can reproduce this on core revision 1083 (armhf).

@ogra any idea how we can easily fix this? Whoever updates the symlink at /etc/localtime needs to respect that /etc/localtime is also now just a symlink to /etc/writable/localtime and that the proper target for the symlink needs to be ../../usr/share/zoneinfo/America/Detroit.

All this causes timedated to end up in UTC state.

test@localhost:/etc$ sudo timedatectl
      Local time: Thu 2017-02-09 06:21:21 UTC
  Universal time: Thu 2017-02-09 06:21:21 UTC
        RTC time: n/a
       Time zone: n/a (UTC, +0000)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

well, timedatectl comes from systemd ...
i'm not sure we actually want to patch it ...
what i was thinking about was to have a timezone option in the core snap config instead, then we are free to implement the link farm as we like via some scriptery or go binary

I can confirm that our system is affected too.

https://github.com/snapcore/core/pull/8 would be a possible fix (waiting for reviews from the team)

I have the wrapper script on my dragonboard and the date/time still resets as described in the duplicate bug.

snap 2.23.1
snapd 2.23.1
series 16
kernel 4.4.0-1030-snapdragon

From the log when it reverts to utc

Mar 16 11:07:14 patsdragon dbus[1683]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service'
Mar 16 11:07:14 patsdragon systemd[1]: Starting Time & Date Service...
Mar 16 11:07:14 patsdragon dbus[1683]: [system] Successfully activated service 'org.freedesktop.timedate1'
Mar 16 11:07:14 patsdragon systemd-timedated[10615]: /etc/localtime should be a symbolic link to a time zone data file in /usr/share/zoneinfo/.
Mar 16 11:07:14 patsdragon systemd[1]: Started Time & Date Service.

pat-mcgowan@patsdragon:~$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 18 Mar 8 10:03 /etc/localtime -> writable/localtime
pat-mcgowan@patsdragon:~$ ls -l /etc/writable/localtime
lrwxrwxrwx 1 root root 35 Mar 16 10:57 /etc/writable/localtime -> /usr/share/zoneinfo/America/Detroit
pat-mcgowan@patsdragon:~$

systemd-timedated at
https://github.com/systemd/systemd/blob/master/src/timedate/timedated.c#L71
calls get_timezone() at
https://github.com/systemd/systemd/blob/master/src/basic/time-util.c#L1292
which explicitly checks the value of the linked file name to "/usr/share/zoneinfo"
which fails and logs the error and doesn't return a valid timezone.

Not sure how to fix short of modifying the readlink util to follow multiple links
https://github.com/systemd/systemd/blob/master/src/basic/fs-util.c#L147

On the other hand, why doesn't the get_timezone code just read the value of /etc/timezone rather than parsing the file pathnames all over again?

Seems to fix this on touch we patched timedated to understand writable paths
http://launchpadlibrarian.net/152047435/systemd_204-0ubuntu14_204-0ubuntu15.diff.gz
per
https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1227520

Original patch at
http://launchpadlibrarian.net/151915023/systemd_204-0ubuntu13_204-0ubuntu14.diff.gz

your comment #6 clearly shows that the script did not intercept the set-timezone call:

pat-mcgowan@patsdragon:~$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 18 Mar 8 10:03 /etc/localtime -> writable/localtime

thats a relative link again, the get_timezone() call should be fine if it is an absolute link (which the script cares for)

I reflashed the dragon board to retest

once a timezone is set the date command works, however timedatectl does not and the daemon does reset the TZ to nothing
~$ timedatectl
      Local time: Mon 2017-03-20 17:39:23 UTC
  Universal time: Mon 2017-03-20 17:39:23 UTC
        RTC time: Thu 1970-01-01 00:48:33
       Time zone: n/a (UTC, +0000)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no
pat-mcgowan@localhost:~$ date
Mon Mar 20 13:39:57 EDT 2017

The snapweb UI reflects what timedatectl sees i.e. the wrong timezone.

So this bug seems to be "fixed", will open another on snapweb not to rely on timedatectl.

How can this be fixed if timedatectl is still wrong?

If the timezone is changed via a DBus request to systemd-timedated, will the date command be correct?

if systemd-timedated invokes timedatectl your TZ should be set correctly for date.

Thanks Ogra!

Could you explain what actually was patched and when? We have a customer image due this Thu, and I'm wondering at what point new images will include this fix.

@tony https://github.com/snapcore/core/pull/8 moves timedatectl to timedatectl.real and intercepts the setting of the symlink in /etc/writable to be an absolute one (so it isnt dangling anymore but pointing to an actual timezone file).

@ogra Actually that doesn't sound like a good solution. Timedated offers a DBus-API (https://www.freedesktop.org/wiki/Software/systemd/timedated/) which allows you to set the timezone. So timedatectl talks to timedated over dbus, isn't it? With that we have to fix timedated as otherwise we still have a open hole in our system. Everyone who will use the timezone-control interface will run into this issue again. See https://github.com/snapcore/snapd/blob/master/interfaces/builtin/timezone_control.go

@Ogra

So is there logic in both timedatectl *and* timedated to update the symlink? I'd actually be surprised if that was the case.

Simon is correct in that we have a snapd interface which allows snaps using it to configure the timezone via DBus requests to timedated. I'd made the assumption in my original bug report that timedatectl delegated the work to timedated.

@Tony: timedatectl calls timedated over dbus. Same API as we offer with the timezone-control interface. See https://www.freedesktop.org/wiki/Software/systemd/timedated/

@simon, that interface doesnt even mark /etc/localtime as writable ...

/etc/{,writable/}timezone rw,

looking at the code of timedated it doesnt seem like we can teach it easily about teh two levels of symlinks we use ... it hardcodes nearly everything, including to enforce a relative symlink "../usr/share/zoneinfo/" ... not sure how we could fix this without harming the rest of the world.

@ogra: I think we have to. There needs to be some smart detection code if we're running in a core environment or not.

The old patch (comment #9) introduced a check for writable_filename then modified the calls to something like
r = readlink_malloc(writable_filename("/etc/localtime"), &t);

We could do that same hacks. It seems this code was refactored a good bit since then.

Can someone please change the status back to 'Confirmed'?

@pat the prob is as you say ... it is a hack ... we need to get this proper into systemd.

while we have a PPA for a few image build bits we can not carry a patch for systemd in that PPA if there is no chance it gets merged either as a distro patch or upstream.

i think we should involve foundations in this discussion as they are maintaining the ubuntu systemd package and would have to carry that patch.

This is really messy. As Pat pointed out, one option is to teach systemd to understand that there might be /etc/writable/localtime. I started with such a patch but its more involved (we need to tweak context_write_data_timezone() and get_timezone() to make it understand the different layout) and also very unlikely be taken by upstream (and a high likelyhood for conflicts).

A cheap(er) alternative might be to simply makee /etc/localtime writable and stop it being a symlink to writable/localtime. Then we patch systemd to retry the symlinking of that file in a non-atomic way if the atomic one failed. This patch is much more isolated and easier to carry. *If* all apps are using systemd to write this symlink we should be fine. It is still non-atomic but its just the timezone that would be wrong if in the middle of unlink/symlink() things go bad.

we can not make single files writeable because our writable-paths only act on directories using bind mounts, this is the main reason for the whole /etc/writable mess to exist in the first place.

@ogra: check /etc/default/keyboard. The fact that we have /etc/writable is only because things want to write atomic with a pattern like write("/etc/foo.tmp"), rename("/etc/foo.tmp", "/etc/foo")

Guys, can't we have a symlink like /etc/usr -> /usr to resolve this? I tried to patch the image but, seems, /etc is not changeable from the image file.

This is a critical issue for Renat and is blocking their project. Can it be fixed quickly?

According to https://forum.snapcraft.io/t/next-snapd-2-25/197 this is set to be fixed with the 2.25 release.

Doesn't look like it made the cut per the release announcement:

https://github.com/snapcore/snapd/releases/tag/2.25

the following changes were recently added in edge, do we have any snap or a simplified test case to test the dbus way of setting the timezone to verify the changes ?

https://github.com/snapcore/core/pull/40
https://github.com/snapcore/snapd/pull/3316

Using the core from edge and the command in the bug description this works now. This will be part of the 2.26.3 stable core to be released in ~2 weeks.

@mvo the command in the bug description works since march when this bug was originally closed ... what doesnt work is the additional method used via the dbus interface (the original command just runs timedatectl directly, no dbus interface involved).

what we are missing is a verification for the dbus method to set the timezone for which no test case was added to this bug ...

@mvo, @ogra

I'll test the DBus case this afternoon, and add my details to the bug. Sorry for the delay in reviewing this.

I'd originally assumed that timedatectl used DBus to do the heavy lifting, and had asked the question of whether there was duplicate code to handle the symlink in both timedatectl and timedated in comment #17.

Anyways, the command to set the timezone to "Detroit" via DBus is simply:

sudo dbus-send --system --print-reply \
     --dest=org.freedesktop.timedate1 \
     /org/freedesktop/timedate1 \
     org.freedesktop.timedate1.SetTimezone \
     string:"America/Detroit" boolean:false

After installing core from edge (16-2.26.3+git204.1bc8375/r2013), and running this command, it fails and I end up with the same broken link as originally reported in the bug:

$ ls -l /etc/writable/localtime
lrwxrwxrwx 1 root root 37 May 23 20:44 /etc/writable/localtime -> ../usr/share/zoneinfo/America/Detroit

That said, using timedatectl to change the timezone does work, and results in the following symbolic link:

lrwxrwxrwx 1 root root 35 May 23 16:51 /etc/writable/localtime -> /usr/share/zoneinfo/America/Detroit

I'm confused, it appears that we still haven't touched timedate1 itself yet?

Looks like Tyler want ahead and modified timezone-control, so that snaps using this interface can execute timedatectl directly, so at least there's a way for a snap to actually control the timezone programmatically.

Perhaps we should file a new bug to track that the DBus interface way of doing this is still broken?

@Tony. When is Tyler's landing going to reach snapd stable? This is a blocker for a customer going to beta, which they hope to do next week.

Sorry, I missed mvo's comment 33 " This will be part of the 2.26.3 stable core to be released in ~2 weeks."

One of our commercial customers just reported an issue about timedatectl not working properly on Ubuntu Core 16.

The short summary:

1. sudo timedatectl set-timezone TZ works:
  - /etc/timezone is set correctly
  - the date command displays the new TZ correctly
  - timedatectl displays the new TZ

2. after a reboot, /etc/timezone is still set to the new TZ, date still displays the new TZ, however timedatectl shows the timezone as unset

3. Using DBus to set the TZ as described in comment #36 still fails

Reopened based on last comment.

I too have the problem described in #36 where setting the timezone via DBus seems to work (timezone shows up in timedatectl output), but is actually ignored and timedatectl output reverts to UTC after 1-3 minutes. Setting via `timedatectl set-timezone <tz-identifier>` works, but is also reverted sometimes after a varying amount of time.

This is unfortunately still an issue, it looks like a race between when systemd mounts /etc/writable and when it looks at /etc/localtime (which points to /etc/writable).

Fwiw, this issue is also present on uc18, uc20.

On Mon, 3 Aug 2020, 11:00 Michael Vogt, <email address hidden> wrote:

> This is unfortunately still an issue, it looks like a race between when
> systemd mounts /etc/writable and when it looks at /etc/localtime (which
> points to /etc/writable).

We should either mount etc/writable from initrd. Or make all services that
need it to have wants/after=etc-writable.mount dropin.

I looked at this a bit closer and we already bind mount everything /etc* in initrd. So my initial hunch was wrong. It turns out the issue is that src/basic/time-util.c:get_timezone() is smart and checks the prefix of the symlink target of /etc/localtime.

The attached patch for systemd fixes this on focal and we will need something similar for xenial, bionic. We also need a proper spread regression test for snapd - which should be trivial to write as we have tests/core/system-settings already which checks that this works *except* the reboot :(

Hello

We at UBports are continuing the Ubuntu Touch project and is bringing it to 20.04. As we continue to use the system-image system with read-only rootfs, we're encountering this same issue. We carry a patch in systemd [1] to solve this issue on xenial, but we would very much prefer not to continue forking it. Could you please take a look again at this issue?

Note that in the patch we carry [1], we not only fix the path resolution, but also fix the symlink creation inside timedated. This would fix the timezone setting when done via DBus, which is important for us as Ubuntu Touch's system-settings calls timedated's DBus interface to set the timezone.

[1] https://github.com/ubports/systemd-packaging/blob/xenial/debian/patches/0001-Fix-reading-of-localtime-link-on-readonly-systems.patch

So, I go ahead and apply the patch from @mvo (+another patch) into Impish, Focal and Bionic systemd packaging repo, and propose merges to them (see related branches in the bug). Note that the patch for Bionic is slightly different, but the principle is the same.

The description will be updated with Impish feature freeze (sort of) exception request and the SRU message.

Now that Jammy series is opened, I've opened another merge proposal on Jammy branch with the same patch as in Focal's. Please take another look; this patch is important for us at UBports, and having the patches in Jammy would be nice because there will be Ubuntu Core 22.

The Impish-related section has been removed from the description. Should I also delete the merge proposal for Impish branch?

I can confirm that Ratchanan's patches work (well, I only tried the one on timedated, as the one on timedatectl is not essential to fix this bug).

But I don't think that it should be treated separately from the existing patch we have, so I'm attaching a refreshed patch which includes Ratchanan's change. Still, we probably want to explore other solutions, since Dan (@ddstreet) is also right that carrying hacks for 7 years is something we should avoid doing.

But I don't have many alternative ideas :-( Unfortunately, bind-mounting /etc/writable/localtime over /etc/localtime does not work, because when mounting, the kernel follows all symbolic links, so we end up bind-mounting the timezone file (for example "/usr/share/zoneinfo/Europe/Berlin") on top of itself :-)

Status changed to 'Confirmed' because the bug affects multiple users.

I'm pretty much with @ddstreet here, introducing another hack to handle Ubuntu Core quirks is not nice, as those hacks will make our systemd more unstable over time and will break regularly after merging upstream changes.

As stated before, we already carry such hacks since 2014 and I just want to give a brief quote from that long standing patch: "Forwarded: OMGno, this is a rather nasty hack until we fix system-image to get a writable /etc" – I do not know a lot about Ubuntu Core's file system hierarchy and why it deviates from the common setup, but maybe getting a writable /etc is the core problem to solve here, as stated by @pitti in 2014 already.

IIUC we currently have a workaround by @ogra in place that only applies to the "timedatectl" CLI, the proposed MRs would fix this for the "timedatectl" CLI and the systemd-timedated DBus API. But what about other tools that assume /etc/localtime to be handled like on most other common systems? Do we start patching every application now and teach them about Ubuntu Core's /etc/writable quirks, e.g. glibc's "tzset(3)"?
That cannot be the correct path forward...

OTOH those MRs are rather small and clear and they solve an issue for our users NOW (tho only one part of the issue that is related to systemd-timedate).

As a compromise I guess I would be willing to accept the current patches into Jammy (so they can be SRUed afterwards), IF we have a clear path forward about solving this problem properly and replacing the hack with an upstream solution in the not too distant future – hopefully dropping the other long-standing /etc/writable patch at the same time.

The snapd team (Michael/Valentin) recently started investigating proper upstream solutions to this problem (thanks for that!) and I asked Valentin to create a tracking bug for us, that we can reference alongside those new hacks, so we can drop them once a better solution is in place: https://bugs.launchpad.net/snappy/+bug/1953172

The workarounds for read-only /etc/ are only needed in Ubuntu Core / system-image / UBports environments (/etc/writable doesn't exist on classic systems), that are based on the LTS releases. Therefore, I'm marking the Hirsute and Impish tasks as WONTFIX.

This bug was fixed in the package systemd - 249.5-2ubuntu2

---------------
systemd (249.5-2ubuntu2) jammy; urgency=medium

  * d/p/debian/timedatectl-lp1650688.patch,
    d/p/debian/UBUNTU-Fix-timezone-setting-on-read-only-etc.patch:
    Fix timedated unable to retrieve & properly set timezone on
    read-only /etc (e.g. Ubuntu Core and system-image-based systems)
    (LP: #1650688, LP: #1733881)

 -- Ratchanan Srirattanamet <email address hidden> Wed, 08 Dec 2021 09:25:28 +0100

Hello Tony, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.14 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello Tony, or anyone else affected,

Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.53 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

I have accepted this fix for all the prepared systemd SRUs. I see that LP: #1953172 has been created to track the future snapd work, but do you know if work on this is already ongoing? Did you hear anything from the snapd team regarding when we can expect it to land?

The investigation started just recently. I do not expect a fix to be landed soon.

All autopkgtests for the newly accepted systemd (237-3ubuntu10.53) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

openssh/1:7.6p1-4ubuntu0.5 (armhf)
linux-hwe-5.0/5.0.0-65.71 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Test result on Focal (245.4-4ubuntu3.14):
- Normal environment: Tested on my desktop. timedatectl output is correct. Setting the timezone works, and doesn't put the link inside /etc/writable/.
- System-image environment (UBports image): timedatectl output is correct. Setting timezone works; readlink -f /etc/localtime points to an existing file.
- Ubuntu Core environment: test with snapcore/core20 commit 2d970050. focal-proposed is enabled and src:systemd is pinned in overlay. timedatectl output is correct. Setting timezone works; readlink -f /etc/localtime points to an existing file.

Test result on Bionic (237-3ubuntu10.53):
- Normal environment: Tested in an LXD container. timedatectl output is correct. Setting the timezone works, and doesn't put the link inside /etc/writable/.
- Ubuntu Core environment: test with snapcore/core18 commit b8ad5ed4. bionic-proposed is enabled and src:systemd is pinned in overlay. timedatectl output is correct. Setting timezone works; readlink -f /etc/localtime points to an existing file.
- System-image enviroment: We at UBports doesn't have a port of Ubuntu Touch based on Bionic, and as such I cannot test in this environment.

Note: in Ubuntu Core environments, timedatectl.real is used to test timedated instead of the wrapper.

Note: according to [1], seems like verification-needed* has to be left as-is until another positive testimony appears or the test is done by an SRU verification team member.

[1] https://wiki.ubuntu.com/QATeam/PerformingSRUVerification#Updating_the_bug_report

------

Oh, BTW, I looked at the autopkgtests failure earlier. One of the failure (can't remember which) was because of an out-of-space error. It seems to be gone by now though.

Thank you very much Ratchanan for the verification on Bionic & Focal. I re-triggered those autopkgtest and they are now resolved.

Anything else has to be done for this?

This bug was fixed in the package systemd - 245.4-4ubuntu3.14

---------------
systemd (245.4-4ubuntu3.14) focal; urgency=medium

  [ Lukas Märdian ]
  * Allow target units to fail (LP: #1948476)
    File: d/p/lp1948476-pid1-target-units-can-fail-through-dependencies.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=fe0cb0bd66baea89d8bbe47cb47d88540f46d470
  * Fix whitespace in lp1926547-hwdb-60-keyboard-Update-Dell-Privacy-Micmute-Hotkey-.patch to match upstream
    File: debian/patches/lp1926547-hwdb-60-keyboard-Update-Dell-Privacy-Micmute-Hotkey-.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=80fef80a1b018556939011707c4ce00cebc58806
  * Support detection for ARM64 Hyper-V guests (LP: #1952599)
    Files:
    - debian/patches/lp1952599/0001-virt-Support-detection-for-ARM64-Hyper-V-guests.patch
    - debian/patches/lp1952599/0002-virt-Fix-the-detection-for-Hyper-V-VMs.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=caf3aff933cc7bf21565faba05f78ce78b3196cd

  [ Andy Chi ]
  * Add privacy micmute hotkey for Dell machine. (LP: #1952733)
    File: debian/patches/lp1952733-hwdb-60-keyboard-Update-Dell-Privacy-Micmute-Hotkey-Map.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ff8dc41f55baa418076e42509ddbf3212a8c1353
  * Add microphone mute key for Dell machine. (LP: #1952735)
    File: debian/patches/lp1952735-keymap-Add-microphone-mute-keymap-for-Dell-Machine.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=175fb4e209fba889b4bcd81cb2ed262923943a3f

  [ Yao Wei ]
  * Add ACCEL_LOCATION=base property for 6 Dell clamshell models (LP: #1943561)
    File: debian/patches/lp1943561-dell-clamshell-accel-location-base-with-sku.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=246195d68b2bb0473f4a3f1c2ebe54dfd37f068b

  [ Dan Streetman ]
  * d/p/lp1944711-login-filenames-in-run-systemd-users-are-uids.patch:
    Fix systemd-logind restart loading of existing sessions
    (LP: #1944711)

  [ Ratchanan Srirattanamet ]
  * d/p/debian/timedatectl-lp1650688.patch,
    d/p/debian/UBUNTU-Fix-timezone-setting-on-read-only-etc.patch:
    Fix timedated unable to retrieve & properly set timezone on
    read-only /etc (e.g. Ubuntu Core and system-image-based systems)
    (LP: #1650688)

 -- Lukas Märdian <email address hidden> Fri, 10 Dec 2021 10:04:02 +0100

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package systemd - 237-3ubuntu10.53

---------------
systemd (237-3ubuntu10.53) bionic; urgency=medium

  [ Ratchanan Srirattanamet ]
  * d/p/debian/timedatectl-lp1650688.patch,
    d/p/debian/UBUNTU-Fix-timezone-setting-on-read-only-etc.patch:
    Fix timedated unable to retrieve & properly set timezone on
    read-only /etc (e.g. Ubuntu Core and system-image-based systems)
    (LP: #1650688)

  [ Lukas Märdian ]
  * Support detection for ARM64 Hyper-V guests (LP: #1952599)

 -- Lukas Märdian <email address hidden> Fri, 10 Dec 2021 10:15:49 +0100