timedatectl set-timezone fails on UC16

Bug #1650688 reported by Tony Espy
52
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Snappy
Triaged
High
Unassigned
systemd (Ubuntu)
Fix Released
Medium
Lukas Märdian
Bionic
Fix Released
Undecided
Unassigned
Focal
Fix Released
Undecided
Unassigned
Hirsute
Won't Fix
Undecided
Unassigned
Impish
Won't Fix
Undecided
Unassigned
Jammy
Fix Released
Medium
Lukas Märdian

Bug Description

SRU
===

[Impact]

 * The bug prevents timedated from recognizing and correctly set the system's timezone when running Ubuntu Core 16, 18 and 20.

 * This causes by timedated fails to take Ubuntu Core's /etc/writable redirection into account.

 * The recognizing part is fixed by making the code take writable redirection into account.

 * The set part is fixed by making the code link to the absolute path instead of a relative one.

 * Currently core snaps worked around the set part by providing a wrapper script which re-create /etc/writable/localtime afterward. However this does not cover DBus users.

[Test Plan]

 * On classics systems: ensure the proposed systemd package is installed.
   On Ubuntu Core systems: build a new core snap including proposed package, and install it. Replaces timedatectl with timedatectl.real to test skipping the wrapper.

(Note that one can simulate core snap's /etc/writable redirection by running this image creation hook [1] on the system.)

[1] https://git.launchpad.net/livecd-rootfs/tree/live-build/ubuntu-core/hooks/08-etc-writable.chroot?h=ubuntu/focal

 * On freshly boot system: query the timezone using `timedatectl`. The timezone should corresponds to `readlink -f /etc/localtime` and does not show `n/a`.

 * Set a new timezone: `sudo timedatectl set-timezone Asia/Bangkok`. `readlink -f /etc/localtime` should points to an existing file.

 * Run `sudo systemctl restart systemd-timedated.service`. Then, query the timezone again: `timedatectl`. It should show the previously set timezone and not `n/a`.

 * Run `sudo systemctl status systemd-timedated.service`. This should show no sign of timedated crashing.

[Where problems could occur]

 * It's possible that the redirection handling code will be sub-par and causes crash. However, it's not likely because the similar pieces of code is in the previous patch since Ubuntu 16.04.

 * If it does: the patched `get_timezone()` function is used in 2 places: the networkd's DHCP server [3] and the timedated itself.

   - Networkd is used primarily on servers where NetworkManage is absent. It's possible that this patch causes the user to loss access to the server due to networkd crash when setting up network interfaces, and requires physical access to fix. However, the code path is executed when DHCP is enabled only. I think it's not common for users to have networkd's DHCP server enabled: the feature seems to gear towards desktop users wanting to share internet connection, and in those cases they're more likely to use NetworkManager.

   - The timedated itself is likely used by the programs that involves in time-related functions. If a crash occur, in the worst case users won't be able to set time or timezone via timedated. However, users should still be able to e.g. set time using `date` or set timezone using /etc/localtime (assuming online guides still consider systems without systemd). Timedated is DBus-activated, and thus a crash should be self-healing.

 * The set part would also affects the clasic systems. However, I believe nothing else actually rely on /etc/localtime being a relative path, otherwise the /etc/writable redirection would causes even more problem, and would have been reported.

[3] Yes, I'm surprised that there's a DHCP server inside systemd codebase.

[Other Info]

 * This is also useful for UBports's Ubuntu Touch. We continue using system-image system where the rootfs is read-only, and thus is affected by this bug similarly to Ubuntu Core. I've tested the Focal version of the package on our (currently in development) Focal Ubuntu Touch image, and the fix works.

------------

[Original bug description]

On a system running UC16, the file /etc/localtime is a link that points to /etc/writable/localtime.

On a freshly installed system, /etc/writable/localtime is a fully-qualified link that points at /usr/share/zoneinfo/UTC.

If timedatectl is used to set the timezone to something else, timedated updates the localtime symbolic link with a relative path to the zoneinfo directory, which results in an invalid link.

$ sudo timedatectl set-timezone America/Detroit

$ sudo timedatectl
      Local time: Fri 2016-12-16 18:18:49 EST
  Universal time: Fri 2016-12-16 23:18:49 UTC
        RTC time: Fri 2016-12-16 23:18:49
       Time zone: America/Detroit (EST, -0500)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

$ ls -l /etc/writable/localtime
/etc/writable/localtime --> ../usr/share/zoneinfo/America/Detroit

admin@localhost:/etc/writable$ date
Fri Dec 16 23:20:07 UTC 2016

I'm running the latest core snap from the candidate channel which contains snapd 2.18.1. Hardware details and/or more debug information can be supplied on request.

See 'man 3 timezone' and 'man timedatectl' for more details.

Related branches

Revision history for this message
Simon Fels (morphis) wrote :

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

Revision history for this message
Oliver Grawert (ogra) wrote :

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

Tony Espy (awe)
Changed in snappy:
status: New → Confirmed
Revision history for this message
Renat (renat2017) wrote :

I can confirm that our system is affected too.

Revision history for this message
Oliver Grawert (ogra) wrote :

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

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

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

Changed in snappy:
assignee: nobody → Oliver Grawert (ogra)
importance: Undecided → High
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

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:~$

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

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?

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :
Revision history for this message
Pat McGowan (pat-mcgowan) wrote :
Revision history for this message
Oliver Grawert (ogra) wrote :

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)

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

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.

Changed in snappy:
status: Confirmed → Fix Released
Revision history for this message
Tony Espy (awe) wrote :

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?

Revision history for this message
Oliver Grawert (ogra) wrote :

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

Revision history for this message
Tony Espy (awe) wrote :

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.

Revision history for this message
Oliver Grawert (ogra) wrote :

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

Revision history for this message
Simon Fels (morphis) wrote :

@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

Revision history for this message
Tony Espy (awe) wrote :

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

Revision history for this message
Simon Fels (morphis) wrote :

@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/

Revision history for this message
Oliver Grawert (ogra) wrote :

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

/etc/{,writable/}timezone rw,

Revision history for this message
Oliver Grawert (ogra) wrote :

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.

Revision history for this message
Simon Fels (morphis) wrote :

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

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

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.

Revision history for this message
Tony Espy (awe) wrote :

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

Changed in snappy:
status: Fix Released → Confirmed
Revision history for this message
Oliver Grawert (ogra) wrote :

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

Tony Espy (awe)
tags: added: hwe
Revision history for this message
Michael Vogt (mvo) wrote :

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.

Revision history for this message
Oliver Grawert (ogra) wrote :

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.

Revision history for this message
Michael Vogt (mvo) wrote :

@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")

Revision history for this message
Renat (renat2017) wrote :

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.

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

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

Revision history for this message
Simon Fels (morphis) wrote :

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

Revision history for this message
Tony Espy (awe) wrote :

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

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

Oliver Grawert (ogra)
Changed in snappy:
status: Confirmed → In Progress
Revision history for this message
Oliver Grawert (ogra) wrote :

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

Revision history for this message
Michael Vogt (mvo) wrote :

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.

Changed in snappy:
status: In Progress → Fix Committed
Revision history for this message
Oliver Grawert (ogra) wrote :

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

Revision history for this message
Tony Espy (awe) wrote :

@mvo, @ogra

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

Revision history for this message
Tony Espy (awe) wrote :

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?

Revision history for this message
Tony Espy (awe) wrote :

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?

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

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

Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

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

Revision history for this message
Tony Espy (awe) wrote :

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

Revision history for this message
Zygmunt Krynicki (zyga) wrote :

Reopened based on last comment.

Changed in snappy:
status: Fix Committed → New
Revision history for this message
glancr team (glancr) wrote :

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.

Zygmunt Krynicki (zyga)
Changed in snappy:
status: New → Triaged
Oliver Grawert (ogra)
Changed in snappy:
assignee: Oliver Grawert (ogra) → nobody
Revision history for this message
Michael Vogt (mvo) 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).

Revision history for this message
Michael Vogt (mvo) wrote :

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

Revision history for this message
Dimitri John Ledkov (xnox) wrote : Re: [Bug 1650688] Re: timedatectl set-timezone fails on UC16

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.

Revision history for this message
Michael Vogt (mvo) wrote :

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 :(

Revision history for this message
Ratchanan Srirattanamet (peat-new) wrote :

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

Revision history for this message
Ratchanan Srirattanamet (peat-new) wrote :

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.

description: updated
Mathew Hodson (mhodson)
Changed in systemd (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Ratchanan Srirattanamet (peat-new) wrote :

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?

description: updated
tags: added: rls-jj-incoming
Revision history for this message
Alberto Mardegan (mardy) wrote :

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 :-)

Revision history for this message
Alberto Mardegan (mardy) wrote :
Lukas Märdian (slyon)
tags: added: fr-1885
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
tags: removed: rls-jj-incoming
Revision history for this message
Lukas Märdian (slyon) wrote :

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

Lukas Märdian (slyon)
Changed in systemd (Ubuntu Jammy):
assignee: nobody → Lukas Märdian (slyon)
Lukas Märdian (slyon)
Changed in systemd (Ubuntu Jammy):
status: Confirmed → In Progress
status: In Progress → Fix Committed
Revision history for this message
Lukas Märdian (slyon) wrote :

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.

Changed in systemd (Ubuntu Hirsute):
status: New → Won't Fix
Changed in systemd (Ubuntu Impish):
status: New → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu Jammy):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

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.

Changed in systemd (Ubuntu Focal):
status: New → Fix Committed
tags: added: verification-needed verification-needed-focal
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

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.

Changed in systemd (Ubuntu Bionic):
status: New → Fix Committed
tags: added: verification-needed-bionic
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

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?

Revision history for this message
Lukas Märdian (slyon) wrote :

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

Revision history for this message
Ubuntu SRU Bot (ubuntu-sru-bot) wrote : Autopkgtest regression report (systemd/237-3ubuntu10.53)

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!

Revision history for this message
Ratchanan Srirattanamet (peat-new) wrote :

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.

Revision history for this message
Lukas Märdian (slyon) wrote :

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

tags: added: verification-done-bionic verification-done-focal
removed: verification-needed-bionic verification-needed-focal
Revision history for this message
Ratchanan Srirattanamet (peat-new) wrote :

Anything else has to be done for this?

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu Bionic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers