Wrong UTC zoneinfo in cloud-images

Bug #1543025 reported by Stefan Bader on 2016-02-08
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cloud-init
High
Unassigned
cloud-init (Ubuntu)
High
Scott Moser
Xenial
High
Scott Moser

Bug Description

ADT runs use cloud-images to create test VM environments. For the Xenial cloud-images I observed a weird issue where libvirt suddenly fails its build-time tests on a time offset test on UTC.
Looking at the prepared image (cloud-init did already run there), I found that indeed a command-line of

TZ=UTC date

reports a CET based time. Looking further this seems to drill down into

/usr/share/zoneinfo/UTC -> Zulu

and that (Zulu another term for UTC) Zulu file looks quite bigger that the same on other hosts and contains the CET string as well (normal ~128b, wrong size 2335). Forcing a reinstall of tzdata will fix the file and also allows the libvirt test to pass.

So I am not sure this is wrong in the initial image base or gets in some way broken during cloud-init. Thats why I start reporting it against cloud-init.

Related branches

Martin Pitt (pitti) wrote :

I downloaded the current amd64 cloud image and dissected it with kpartx, i. e. without booting. /usr/share/zoneinfo/Zulu is correct there, i. e. 127 bytes. So indeed it sounds like this file gets overwritten by cloud-init.

Changed in cloud-init (Ubuntu):
importance: Undecided → High
Martin Pitt (pitti) wrote :

I think the bug is here in cloudinit/distros/__init__.py:

def set_etc_timezone(tz, tz_file=None, tz_conf="/etc/timezone",
                     tz_local="/etc/localtime"):
    util.write_file(tz_conf, str(tz).rstrip() + "\n")
    # This ensures that the correct tz will be used for the system
    if tz_local and tz_file:
        util.copy(tz_file, tz_local)
    return

/etc/localtime ought to be a symlink to the selected file in /usr/share/zoneinfo/, not a copy (it used to in the past due to the possibility of /usr/ being on a separate file system, but that got fixed by initramfs-tools in a better way now). So with the copy() the symlink doesn't get updated, and instead it clobbers the file in /usr/.

Changed in cloud-init (Ubuntu):
status: New → Triaged
Jon Grimm (jgrimm) on 2016-02-23
Changed in cloud-init (Ubuntu Xenial):
assignee: nobody → Scott Moser (smoser)
Scott Moser (smoser) on 2016-03-01
Changed in cloud-init:
status: New → Triaged
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cloud-init - 0.7.7~bzr1176-0ubuntu1

---------------
cloud-init (0.7.7~bzr1176-0ubuntu1) xenial; urgency=medium

  * d/README.source, d/new-upstream-snapshot: simplify the README.source
    with a script.
  * d/rules: support DEB_BUILD_OPTIONS=nocheck and remove unused code.
  * d/rules: make tests with python3
  * d/control: add pep8 as a build depends
  * d/cloud-init.preinst, d/cloud-init.postinst adjust upgrade path
    to adjust systemd jobs that put cloud-init unit jobs directly
    in multi-user.target.
  * New upstream snapshot.
    * Add Image Customization Parser for VMware vSphere Hypervisor Support.
      Disabled by default. [Sankar Tanguturi]
    * lxd: add initial support for setting up lxd using 'lxd init'
    * Handle escaped quotes in WALinuxAgentShim.find_endpoint (LP: #1488891)
    * timezone: use a symlink when updating /etc/localtime (LP: #1543025)
    * enable more code testing in 'make check'
    * Added Bigstep datasource [Daniel Watkins]
    * Enable password changing via a hashed string [Alex Sirbu]

 -- Scott Moser <email address hidden> Fri, 04 Mar 2016 15:44:02 -0500

Changed in cloud-init (Ubuntu Xenial):
status: Triaged → Fix Released
Jon Grimm (jgrimm) wrote :

Updated status, its long been fix released in the upstream.

Changed in cloud-init:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers