Ubuntu Server - 9 September 2019

Hi everyone, below you will find the updates of the Ubuntu Server team members from the last week. If you are interested in discussing a topic please start a thread in the Server area of this Discourse site.




1 Like


  • pmdk-convert update: #1842428 I started looking at updating pmdk-convert, assuming it would have just fixes and therefore need no Feature Freeze Exception. Turns out the actual changes to its code are ok, but it embeds multiple older versions of pmdk inside itself, so it’s able to convert from one to the other (that’s the purpose of this package after all: format conversion). These sources were bumped, and some have changes that I think are not compatible with the Feature Freeze period we are in at the moment. I’m still reviewing them, but it might be faster to just go ahead and ask for the FFe. TBD.
  • libpmemobj-cpp: again this package, but this time to drop the added delta from last week, which was extra build dependencies. With the final update of pmdk, these extra build-deps can now be dropped.


  • troubleshooted a kopana-webcore dep8 failure that was blocking its migration (#1842755)
  • postfix FTBFS (fix uploaded, stuck in migration for other reasons): #1842923). Fix also submitted to Debian at https://salsa.debian.org/postfix-team/postfix-dev/merge_requests/2, so it’s a small delta that we can drop in the near future
  • Migration: the week started with many server packages stuck in excuses. Many were uploaded as a no-change rebuild due to glibc 2.30 arriving in eoan, and that sometimes triggers failures. We split them up between ourselves and will fix them one by one. I’ll check ruby2.5, freeipmi and probably resource-agents as that is what is blocking my postfix upload.
1 Like


  • Validation of the SRU (Stable Release Update) of cloud-init back into xenial, bionic and disco
    • Performed manual boot verification on Oracle Cloud Infrastructure
      • This resulted in the discovery of a minor regression on Oracle, bug 1842752
      • This bug is cosmetic, and causes boot to slow down by <0.1s
      • Under normal circumstances, we would address even this, but Ubuntu images in Oracle Cloud Infrastructure will be migrating to the Oracle data source in the near future, so the impact of this will be substantially limited
    • Wrote the verification script and bug content for bug 1812857
      • This took the best part of a day because I ran into a number of roadblocks; I don’t have an OpenStack I can modify network config on, performing validation in a VM would require crafting OpenStack network_data.json for the issue, and bond setup inside xenial containers wasn’t working for me
      • Excerpt from my notes:
        • Figured I could probably do better in a VM with a ConfigDrive attached
          • I couldn’t
  • Code review


  • No substantial curtin work this week


  • No substantial UA client work this week


  • Back after a week and a day off, so spent the early part of the week just catching up on email etc.
    • Footage of me destroying my email backlog: Footage of me destroying my email backlog
    • (I was at this show during my time off!)
  • Submitted several talk proposals for PyCon Canada 2019, fingers crossed!

Ubuntu HA

LP: #1842016 - crmsh autopkgtests regression in Eoan

  • Fix Released, autopkgtests work after last SRU
  • VERIFICATION: s390x is broken (LP: #1745155)

LP: #1745155 - ocfs2-tools s390x is broken (segfaults).

  • Finished analyzing ocfs2-tools source code for small/big little issues.
  • Tested bitmap pointer array different orders in amd64 and s390x.
  • Read how ocfs2-tools bitmap array was allocated and populated.
  • Decided to fail build over all big-endian architectures.
  • I mostly agree to Christian’s comments about architecture whitelists.

LP: #1840958 - defragfs.ocfs2 hangs (or takes too long) on arm64, ppc64el


LP: #1805256 - qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

  • Upstream work fixing QEMU Async I/O for Aarch64: Somehow ARM64 (D06 Huawei Server) existing MEM barriers aren’t enough for this machine, causing Async I/O to hang (this is also true for QEMU core parts, not only for qemu-img).
  • https://lists.nongnu.org/archive/html/qemu-devel/2019-09/msg02346.html
  • I have added a mutex around affected parts and it was enough to make it work for ARM64 but upstream might want to continue with primitives so I might have to re-check which barriers weren’t enough for the mem ordering and fix them.
1 Like