[Group.of.nepali.translators] [Bug 1758037] Re: LTC Test- Ubuntu18.04: Starting the guest with network filter defined will fail with "cause is unknown".

[ChristianEhrhardt]

Regression- and Case-Tested once more from a ppa and being good.
Also pushed to ubuntu libvirt-maintainers git as a new cosmic-4.0 branch
Uploaded to Cosmic and completed, now considering SRUs.

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Artful)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Bionic)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1758037

Title:
  LTC Test- Ubuntu18.04: Starting the guest with network filter defined
  will fail with "cause is unknown".

Status in libvirt:
  Unknown
Status in The Ubuntu-power-systems project:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Triaged
Status in libvirt source package in Artful:
  Triaged
Status in libvirt source package in Bionic:
  Triaged

Bug description:
  [Impact]

   * nwfilters were not usable if configured to use dhcp based learning

   * Fix by backporting upstream bug

  [Test Case]

   * Add the following to the interface section of a guest description in 
 libvirt:
   
 
   
  Then start the guest.

  Bad case:
  error: Failed to start domain VM1
  error: An error occurred, but the cause is unknown

  Fixed:
  Guest starts and works.

  [Regression Potential]

   * I thought a while on this. On first sight one might say there is a 
 regression risk due to increasing the size of the buffer. This risk 
 would arise on hyperscale environments where the memory consumption per 
 guest would increase by 2*128Kb*#guest-interfaces (not much, but can 
 sum up on MANY guests).
 But then I realized that this is only true for the use case using 
 dhcpsnoop which is
 a) clearly not the most common case
 b) failing to work at all before this fix
 So there can't be anyone today with a working setup that then runs OOM, 
 due to the setup either not using the feature (=no change) or failing 
 missing this fix.
 So I actually think this mem consumption increase is not an issue in 
 terms of SRU considerations.
 Due to that the only remaining regression would be users that had a 
 self-built libpcap without TPACKET_V3 to drive a workload like the 
 above, and even then only the rather small size bump is what changes.

  [Other Info]
   
   * I have added this case and a few deeper checks on the created rules for 
 iptables to the regression tests

  ---

  == Comment: #2 - Mallesh N. Koti  - 2018-02-28
  05:02:49 ==

  Guest Xml

  ===
  ISSUE
  ===
  Defining a network filter and Starting a VM with this nwfiter in VM's xml is 
failing with "cause is unknown".

  ==
  Recreation Steps
  ==

  1. Define a network filter as:
    virsh nwfilter-define filter.xml

  2. Add nwfilter in guest xml and start guest.
    virsh start VM1

  It fails with :
  # virsh start VM1
  error: Failed to start domain VM1
  error: An error occurred, but the cause is unknown

  XML used for defining network filter:
  ```
  
    -b071-6127-b4ec-
    
  
  
  ```

  will be attaching the guest xml

  The issue happens with Ubuntu 18.04 host - where not able to start the
  guest with network defined with value dhcp.

  
  .
  Found following commit is not there in 18.04 Ubuntu source. There could be 
some dependent commit too.  we are facing some build issue and hence not able 
to verify it.
  .
  
https://github.com/libvirt/libvirt/commit/e62cb4a9b78c7f4499a206635fb4f06e6ac627e5
  .

To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1758037/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1752271] Re: New upstream microreleases 9.3.22, 9.5.12, 9.6.8 and 10.3

[ChristianEhrhardt]

** Changed in: postgresql-10 (Ubuntu Bionic)
   Status: Triaged => Fix Released

** Changed in: postgresql-10 (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1752271

Title:
  New upstream microreleases 9.3.22, 9.5.12, 9.6.8 and 10.3

Status in postgresql-10 package in Ubuntu:
  Fix Released
Status in postgresql-9.3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-9.6 package in Ubuntu:
  Invalid
Status in postgresql-9.3 source package in Trusty:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-9.6 source package in Artful:
  Fix Released
Status in postgresql-10 source package in Bionic:
  Fix Released

Bug description:
  Postgresql stable update

  Note: this is an unusual schedule, but this is about a fix for a (not
  yet published) security fix. But the disclosure didn't align with the
  common releases.

  Note: this time in the initial release there were build errors (on
  windows), so this is already based on the rerolled upstream tarballs

  Current versions in supported releases:
   postgresql-9.3 | 9.3.21-0ubuntu0.14.04 trusty
   postgresql-9.5 | 9.5.11-0ubuntu0.16.04 xenial
   postgresql-9.6 | 9.6.7-0ubuntu0.17.10  artful
   postgresql-10  | 10.2-1bionic

  Special cases:
  - Bionic will be synced from Debian which usually releases fast.
So no Bionic upload.
  - This is again a security update, so while we want to bundle postrges-common
fixes for some dep8 tests, this is not the "normal" SRU we will do so

  Last related stable updates: 9.3.22, 9.5.12, 9.6.8, 10.3

  So the todo is to pick:
  MRE: Trusty 9.3.22 from 
https://borka.postgresql.org/staging/70f3461f2a455731e6f3d11e313840be0b48cf00/postgresql-9.3.22.tar.gz
  MRE: Xenial 9.5.12 from 
https://borka.postgresql.org/staging/70f3461f2a455731e6f3d11e313840be0b48cf00/postgresql-9.5.12.tar.gz

  Sync: Artful 9.6.8 from 
https://borka.postgresql.org/staging/70f3461f2a455731e6f3d11e313840be0b48cf00/postgresql-9.6.8.tar.gz

  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676

  As usual we test and prep from the PPA and then add the NEWS/Upgrade
  Info link once available for the final upload (Annoucnment is Thursday
  1st of March).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-10/+bug/1752271/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1384532] Re: Unable to set AppArmor profile [...] no such file or directory

[ChristianEhrhardt]

Hi,
sorry for chiming in so late, but I haven't seen this issue before - the last 
update changed that.
Special chars as reported in comment #26 and comment #15 are an issue, but most 
of them are fixed or at a better error message now.

First of all since Ubuntu 17.10 (~=UCA-Pike) all files in generated
rules are in quotes which formerly they were not - that allows for some
chars like spaces.

Further some other chars are just plain forbidden and would break the
rule - these are mostly apparmor wilcards so these are now rejected
since v3.10.0 by a150b86c instead of later failing when loading the
profile.

That said it is hard for me to track details of the old issue, but with
a recent Ubuntu this should be all fixed.

With space a rule will now look as:
  "/var/lib/uvtool/libvirt/images/a space does not hurt.qcow" rwk,
and work just fine.

But the actual issue - at least with tolerable special chars is fixed in
the latter releases. And the apparmor wildcards do not randomly fail, or
work or be a security issue - instead they always fail now.

I have to admit the message is still the old misleading one in the remaining 
failing cases.
I spawned bug 1767934 for this - but at low prio.

Per above I'd set the bug fix releases at least for the latter releases.
Given the long time this bug slumbers before a person is hit by it again and 
the fact that a simple file rename gets you around makes me not think of SRUs 
for this atm.
So I'll set won't fix for pre-Artful, but hey - discussions welcome.

** Changed in: libvirt (Ubuntu)
   Status: Confirmed => Fix Released

** Also affects: libvirt (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: High
   Status: Fix Released

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Bionic)
   Importance: High => Medium

** Changed in: libvirt (Ubuntu Artful)
   Importance: Undecided => Medium

** Changed in: libvirt (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1384532

Title:
  Unable to set AppArmor profile [...] no such file or directory

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Artful:
  Fix Released
Status in libvirt source package in Bionic:
  Fix Released

Bug description:
  =
  Bugs are not infrequently reported along the lines of
  Unable to set Apparmor Profile for [emulator]: No such file or directory

  It is frequently (always?) the result of some value (a cdrom or disk
  file) which has spaces of odd characters which mess up virt-aa-helper
  or libvirt itself.

  We should attempt to detect this early on.  Perhaps we can use a qemu hook, 
or add a check in virt-aa-helper.
  =

  /usr/bin/kvm-spice is a soft-link to /usr/bin/kvm

  in /etc/apparmor.d/abstractions/libvirt-qemu there is no line for kvm-
  spice.

  This leads rise to the error:
  libvirt:  error : unable to set AppArmor profile 
'libvirt-224075ba-a31a-48e9-98fe-337146e9f4f1' for '/usr/bin/kvm-spice': No 
such file or directory

  when using e.g. OpenStack

  $ lsb_release -rd
  Description:Ubuntu 14.10
  Release:14.10

  $ dpkg -l|grep libvirt-bin
  ii  libvirt-bin 1.2.8-0ubuntu11 
amd64programs for the libvirt library

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1384532/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1681839] Re: libvirt - disk not ready for pivot yet

[ChristianEhrhardt]

Thanks Falstaff, yeah we knew the fixes are in latter releases - they just were 
hard to backport keeping the general regression risk low (for all other users).
UCA as you used it is a valid way to get fixes ahead of time into last LTS, 
Thanks for verifying this again falstaff.

@bestpa - sad to hear :-/ but see ya another day on another case.

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Medium
   Status: Incomplete

** Also affects: libvirt (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Bionic)
   Status: Incomplete => Fix Released

** Changed in: libvirt (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1681839

Title:
  libvirt - disk not ready for pivot yet

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Artful:
  Fix Released
Status in libvirt source package in Bionic:
  Fix Released

Bug description:
  root@thewind:/home/bestpa/scripts# virsh blockcommit mail vda --active 
--verbose --pivot
  Block commit: [100 %]error: failed to pivot job for disk vda
  error: block copy still active: disk 'vda' not ready for pivot yet

  found related bugfix at redhat... can i get 1.3.2 pushed into ubuntu
  16.04 release?

  bestpa@thewind:~$ cat /etc/os-release 
  NAME="Ubuntu"
  VERSION="16.04.2 LTS (Xenial Xerus)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu 16.04.2 LTS"

  bestpa@thewind:~$ libvirtd --version
  libvirtd (libvirt) 1.3.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1681839/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1766534] Re: libguestfs cannot start the qemu process on s390x

[ChristianEhrhardt]

Given the current Final Freeze for 18.04 this will (if done) have to be an SRU 
for 18.04 as well.
I just did the initial triage, but will leave it for the screener team to 
ensure it is as needed.

** Also affects: libguestfs (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: libguestfs (Ubuntu)
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** No longer affects: linux (Ubuntu)

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)

** Also affects: libguestfs (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libguestfs (Ubuntu Bionic)
   Importance: Undecided
 Assignee: Skipper Bug Screeners (skipper-screen-team)
   Status: New

** Also affects: libguestfs (Ubuntu Artful)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1766534

Title:
  libguestfs cannot start the qemu process on s390x

Status in Ubuntu on IBM z Systems:
  New
Status in libguestfs package in Ubuntu:
  New
Status in libguestfs source package in Xenial:
  New
Status in libguestfs source package in Artful:
  New
Status in libguestfs source package in Bionic:
  New

Bug description:
  The libguestfs versions < 1.37.22 don't work on s390x, as they don't
  contain the patches which include the s390x specifics to instruct qemu-kvm
  correctly. Ubuntu 16.04 contains an older version than that, which makes 
  libguestfs not usable on s390x.


  Steps to reproduce
  ==
  A chronological list of steps which will bring off the issue I noticed:

  
  mz@s390xhost$ docker run -it --privileged --rm ubuntu:xenial bash
  root@5dde0aef5d2e:/# 
  root@5dde0aef5d2e:/# 
  root@5dde0aef5d2e:/# apt update
  root@5dde0aef5d2e:/# DEBIAN_FRONTEND=noninteractive apt install -y \
  libguestfs-tools \
  python-libguestfs \
  linux-image-generic \
  qemu
  root@5dde0aef5d2e:/# 
  root@5dde0aef5d2e:/# 
  root@5dde0aef5d2e:/# export LIBGUESTFS_DEBUG=1 
  root@5dde0aef5d2e:/# export LIBGUESTFS_TRACE=1
  root@5dde0aef5d2e:/# libguestfs-test-tool 


  Expected result
  ===
  The libguestfs-test-tool passes and I can use it on s390x.

  To check if qemu on s390x works independently from libguestfs, I use this
  command:

  root@5dde0aef5d2e:/# qemu-system-s390x \
  -enable-kvm \
  -nographic \
  -kernel /boot/vmlinuz-4.4.0-119-generic \
  -initrd /boot/initrd.img-4.4.0-119-generic \
  -m 1G \
  -M s390-ccw-virtio

  [...]  # boot

  BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs)


  Actual result
  =

  libguestfs instructs qemu to use pci devices and serial consoles
  which doesn't work on s390x, e.g.:

  root@5dde0aef5d2e:/# libguestfs-test-tool
   
   *IMPORTANT NOTICE
   *
   * When reporting bugs, include the COMPLETE, UNEDITED
   * output below in your bug report.
   *
   
  libguestfs: trace: set_verbose true
  libguestfs: trace: set_verbose = 0
  libguestfs: trace: set_verbose true
  libguestfs: trace: set_verbose = 0
  LIBGUESTFS_DEBUG=1
  LIBGUESTFS_TRACE=1
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  SELinux: sh: 1: getenforce: not found
  libguestfs: trace: add_drive_scratch 104857600
  libguestfs: trace: get_tmpdir
  libguestfs: trace: get_tmpdir = "/tmp"
  libguestfs: trace: disk_create "/tmp/libguestfs82Gj1d/scratch.1" "raw" 
104857600
  libguestfs: trace: disk_create = 0
  libguestfs: trace: add_drive "/tmp/libguestfs82Gj1d/scratch.1" 
"format:raw" "cachemode:unsafe"
  libguestfs: trace: add_drive = 0
  libguestfs: trace: add_drive_scratch = 0
  libguestfs: trace: get_append
  libguestfs: trace: get_append = "NULL"
  guestfs_get_append: (null)
  libguestfs: trace: get_autosync
  libguestfs: trace: get_autosync = 1
  guestfs_get_autosync: 1
  libguestfs: trace: get_backend
  libguestfs: trace: get_backend = "direct"
  guestfs_get_backend: direct
  libguestfs: trace: get_backend_settings
  libguestfs: trace: get_backend_settings = []
  guestfs_get_backend_settings: []
  libguestfs: trace: get_cachedir
  libguestfs: trace: get_cachedir = "/var/tmp"
  guestfs_get_cachedir: /var/tmp
  libguestfs: trace: get_direct
  libguestfs: trace: get_direct = 0
  guestfs_get_direct: 0
  libgu

[Group.of.nepali.translators] [Bug 1705743] Re: qemu-system-x86 crashes when VNC connection is established

[ChristianEhrhardt]

Ok, I can confirm the ppa fixing this case.
And OTOH it is fixed in qemu >=2.7.

Furthermore the change is very small and easily reviewable (essentially
only changing a malloc to a malloc0 to initialize properly).

I'm marking the tasks accordingly and prep this as an SRU.

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: qemu (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: qemu (Ubuntu Xenial)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1705743

Title:
  qemu-system-x86 crashes when VNC connection is established

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * some more uncommon vnc configurations (e.g. very long names, but also 
 potentially various other cases that make 
 vnc_init_basic_info_from_server_addr fail) will lead to random data 
 (after alloc) in a struct that will then be used on calls (e.g to free)

   * The fix would avoid hard crashes (due to freeing random or null 
 pointers) in qemu of xenial

  [Test Case]

   * To trigger the issue you can use e.g. a very long vnc string.
   Console 1
 $ mkdir /tmp/service
 $ qemu-system-x86_64 -enable-kvm -vnc 
unix:/tmp/service/../service/../service/../service/vnc-sock
   Console 2
 $ socat - UNIX:/tmp/service/vnc-sock

  [Regression Potential]

   * I'd consider the regression potential very low for the following 
 reasons:
 - small change (easier to review)
 - changing alloc to zeroing alloc (to avoid random data in struct)
 - the change is from upstream and quite old without being reverted or 
   post-fixed

  [Other Info]
   
   * pre testable in ppa 
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3245


  Following minimal test case crashes qemu-system-i386 on amd64 host:

  qemu-system-i386 -name test -nodefconfig -no-user-config -nodefaults
  -sandbox off -machine none -m 256 -balloon none -no-acpi -parallel
  none -vga virtio -display "vnc=unix:vnc.socket" -boot menu=on

  and open the connection (not even real VNC client needed):

  socat - UNIX:vnc.socket

  Result:

  *** Error in `qemu-system-i386': free(): invalid pointer: 0x7fbad024eb78 
***
  === Backtrace: =
  /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fbacff017e5]
  /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fbacff0a37a]
  /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fbacff0e53c]
  qemu-system-i386(+0x4a630d)[0x56145bd6930d]
  qemu-system-i386(visit_type_VncServerInfo+0xa2)[0x56145bd7b342]
  qemu-system-i386(qapi_free_VncServerInfo+0x30)[0x56145bd68910]
  qemu-system-i386(+0x4358fa)[0x56145bcf88fa]
  qemu-system-i386(+0x43aa03)[0x56145bcfda03]
  qemu-system-i386(+0x43abe5)[0x56145bcfdbe5]
  qemu-system-i386(aio_dispatch+0x68)[0x56145bd1f9e8]
  qemu-system-i386(+0x44fcce)[0x56145bd12cce]
  
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7)[0x7fbad0be2197]
  ...

  $ lsb_release -rd
  Description:Ubuntu 16.04.2 LTS
  Release:16.04

  $ apt-cache policy qemu-system-x86
  qemu-system-x86:
    Installed: 1:2.5+dfsg-5ubuntu10.14
    Candidate: 1:2.5+dfsg-5ubuntu10.14
    Version table:
   *** 1:2.5+dfsg-5ubuntu10.14 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://archive.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:2.5+dfsg-5ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1705743/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

[ChristianEhrhardt]

** Also affects: open-vm-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Artful)
   Importance: Undecided
   Status: New

** No longer affects: systemd (Ubuntu Artful)

** Changed in: open-vm-tools (Ubuntu Xenial)
   Status: Invalid => Triaged

** Changed in: open-vm-tools (Ubuntu Artful)
   Status: New => Triaged

** Changed in: open-vm-tools (Ubuntu)
   Status: Fix Released => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1750780

Title:
  Race with local file systems can make open-vm-tools fail to start

Status in cloud-init:
  Invalid
Status in open-vm-tools package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Triaged
Status in systemd source package in Xenial:
  New
Status in open-vm-tools source package in Artful:
  Triaged
Status in open-vm-tools package in Debian:
  Fix Released

Bug description:
  Since the change in [1] open-vm-tools-service starts very (very) early.
  Not so much due to the 
  Before=cloud-init-local.service
  But much more by
  DefaultDependencies=no

  That can trigger an issue that looks like
  root@ubuntuguest:~# systemctl status -l open-vm-tools.service
  ● open-vm-tools.service - Service for virtual machines hosted on VMware
 Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: resources)

  
  As it is right now open-vm-tools can race with the other early start and then 
fail.
  In detail one can find a message like:
open-vm-tools.service: Failed to run 'start' task: Read-only file system"

  This is due to privtaeTmp=yes which is also set needing a writable
  /var/tmp [2]

  To ensure this works PrivateTmp would have to be removed (not good) or some 
after dependencies added that make this work reliably.
  I added
  After=local-fs.target
  which made it work for me in 3/3 tests.

  I' like to have an ack by the cloud-init Team that this does not totally kill 
the originally intended Before=cloud-init-local.service
  I think it does not as local-fs can complete before cloud-init-local, then 
open-vm-tools can initialize and finally cloud-init-local can pick up the data.

  To summarize:
  # cloud-init-local #
  DefaultDependencies=no
  Wants=network-pre.target
  After=systemd-remount-fs.service
  Before=NetworkManager.service
  Before=network-pre.target
  Before=shutdown.target
  Before=sysinit.target
  Conflicts=shutdown.target
  RequiresMountsFor=/var/lib/cloud

  # open-vm-tools #
  DefaultDependencies=no
  Before=cloud-init-local.service

  Proposed is to add to the latter:
  After=local-fs.target

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677
  [2]: https://github.com/systemd/systemd/issues/5610

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750780/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1758428] Re: Subprocesses of StartProgramInGuest fail when creating temporary files

[ChristianEhrhardt]

** Also affects: open-vm-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: open-vm-tools (Ubuntu Artful)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1758428

Title:
  Subprocesses of StartProgramInGuest fail when creating temporary files

Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Triaged
Status in open-vm-tools source package in Artful:
  Triaged
Status in open-vm-tools source package in Bionic:
  Fix Released

Bug description:
  Using open-vm-tools/xenial,now 2:10.2.0-3ubuntu0.16.04.1~ppa6 amd64
  [installed], subprocesses started by vim.vm.guest.ProcessManager fail
  to create temporary files.

  Summary:
  * When running subprocesss through open-vm-tools 2:10.2.0-3ubuntu0.16.04.1 
(via vim.vm.guest.ProcessManager), subprocesses crash while trying to write 
temporary files.
  * Subprocesses run correctly when executed directly from the shell
  * Subprocesses execute correctly from open-vm-tools 
open-vm-tools-10.2.0-7253323, when compiled from source

  Steps to reproduce:
  1. Install open-vm-tools/xenial 2:10.2.0-3ubuntu0.16.04.1~ppa6 on a VMWare 
ESX 6.5 16.04 guest
  2. Using VMOMI API, start a child process that relies on temporary files (eg. 
`apt-get update`)
  3. Note the error code on the child process (eg. 100)
  4. Run process directly from guest shell (eg. `apt-get update`)
  5. Note the successful return code on the child process (1)

  Logs from vmtoolsd on guest:

  
  Mar 23 19:32:32 kcp vmtoolsd[660]: Hit:1 https://apt.dockerproject.org/repo 
ubuntu-xenial InRelease
  Mar 23 19:32:32 kcp vmtoolsd[660]: Couldn't create tempfiles for splitting up 
/var/lib/apt/lists/apt.dockerproject.org_repo_dists_ubuntu-xenial_InReleaseErr:1
 https://apt.dockerproject.org/repo ubuntu-xenial InRelease
  Mar 23 19:32:32 kcp vmtoolsd[660]:   Could not execute 'apt-key' to verify 
signature (is gnupg installed?)

  -

  Psuedo code using pyVMOMI API to start a child process:
  
  #!/usr/bin/python
  import re
  import time
  from pyVim import connect
  from pyVmomi import vim, vmodl

  service_instance = connect.SmartConnectNoSSL(host=,
  user=,
  pwd=,
  port=443)
  content = service_instance.RetrieveContent()

  vm = content.searchIndex.FindByIp(datacenter=None,
ip=,
vmSearch=True)

  creds = vim.vm.guest.NamePasswordAuthentication(
  username="root", password=
  )

  pm = content.guestOperationsManager.processManager
  ps = vim.vm.guest.ProcessManager.ProgramSpec(
 programPath="/usr/bin/apt-get",
 arguments="update"
  )
  res = pm.StartProgramInGuest(vm, creds, ps)
  pid_exitcode = pm.ListProcessesInGuest(vm, creds,
 [res]).pop().exitCode
  while re.match('[^0-9]+', str(pid_exitcode)):
  time.sleep(5)
  pid_exitcode = pm.ListProcessesInGuest(vm, creds,
 [res]).pop().exitCode
  if pid_exitcode == 0:
  print("Program %d completed with success" % res)
  break
  # Look for non-zero code to fail
  elif re.match('[1-9]+', str(pid_exitcode)):
  print("ERROR: Program apt-get completed with Failure %s" % 
pid_exitcode)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/1758428/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1741390] Re: Please backport open-vm-tools 2:10.2.0-3 (main) from bionic

[ChristianEhrhardt]

bug 1758428 unlocked, it's fix is on the way into Bionic.
Once that completes I can propose the changes as prepared to Artful and Xenial.

** Also affects: open-vm-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: open-vm-tools (Ubuntu Artful)
   Status: New => In Progress

** Changed in: open-vm-tools (Ubuntu Artful)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1741390

Title:
  Please backport open-vm-tools 2:10.2.0-3 (main) from bionic

Status in Xenial Backports:
  New
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  In Progress
Status in open-vm-tools source package in Artful:
  In Progress

Bug description:
  [Impact]

   * Without SRUing the never version users get issues running on more 
 recent hipervisors.

   * See comment #6 for where we decided to consider this SRU-worthy

   * This is not backporting a single fix, but the version of a latter 
 Ubuntu release

  [Test Case]

   * This is special in this case, and there are two things

   * a) If one doesn't have a vmware hipervisor he can take get a free 30 
day trial and test the upgrade in there

   * b) more important there is a while matrix of potential hipervisor 
versions to test and none of us has them available. Therefore 
vmware being the owner of the hipservisor as well as the open-vm-
tools upstream project volunteered to verify the upload (already 
done on the PPA ,will be done on the SRU again)

  [Regression Potential]

   * This is quite a bump of versions, so if the new version has issues 
 the old one had not there might be regressions. There are no known 
 issues like that atm and this also is why we pulled VMWare into 
 helping us with the verification (as they are more an authority to 
 call it good)

  [Other Info]
   
   * This was meant to go to backports, but after several discussions a 
 release via SRU is preferred as this will benefit all users way more.

   * Down the road we intend to re-do so for the LTS releases >=Xenial of 
 Ubuntu backporting from the most recent Dev release, so ~6 month 
 cadence.

  ---

  This is no more intended to be a backport, but instead an SRU
  Keep the content if ever needed again.

  Description:
  Please backport open-vm-tools 2:10.2.0-3 (main) from bionic to xenial.

  Reason for the backport:
  
  Newer versions of VMWare ESXi, especially newer features of those require the 
availability of newer open-vm-tools in the guest.
  Making that available as an SRU is at the moment considered to be too much of 
a risk due to the lack of a vast array of ESXi verification setups.
  But it seems good and somewhat tested, while OTOH important for several 
users, which is why it seems the backports pocket is just the right pocket to 
go to.

  Testing:
  
  A ppa is made available for testing at:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3152
  You can test it with:
  sudo add-apt-repository ppa:ci-train-ppa-service/3152
  apt install open-vm-tools

  * xenial - build:
  [No - see below] Package builds without modification

  * xenial - install:
  (tested on VMWare Workstation 14 - upgrading to ppa version)
  [X] open-vm-tools installs cleanly and runs
  [X] open-vm-tools-desktop installs cleanly and runs
  [X] open-vm-tools-dev installs cleanly and runs
  (ppa builds with debug, so I enabled debug from ppa for these tests)
  [X] open-vm-tools-desktop-dbgsym installs cleanly and runs
  [X] open-vm-tools-dbgsym installs cleanly and runs

  * Modifications:
  The backport needs some modifications to build:
  - run autoreconf/systemd dh helpers
  - use the older debhelper B-D
  - revert to compat 10 (which is the latest supported in xenial)
  Modifications are made available as git tree for easy review.
  => 
https://code.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+ref/backport-xenial-lp1741390

  You might need to get the tarballs first to build so I recommend:
  $ pull-lp-source open-vm-tools
  $ git clone -b backport-xenial-lp1741390 
https://git.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools
  Then you can review/modify/build locally
  $ cd open-vm-tools
  $ dpkg-buildpackage -S -nc -d -sa -v2:10.0.7-3227872-5ubuntu1~16.04.1

  If you are a "git ubuntu" user you could also do
  $ git ubuntu clone open-vm-tools
  $ git ubuntu remote add paelzer
  $ git checkout backport-xenial-lp1741390

  Reverse dependencies:
  =
  The following reverse-dependencies need to be tested against the new version 
of open-vm-tools. For reverse-build-dependencies (-Indep), please test that the 
package still builds against the new open-vm-tools. For rev

[Group.of.nepali.translators] [Bug 1764668] Re: guest cleanup script fails to iterate

[ChristianEhrhardt]

Submitted upstream as https://www.redhat.com/archives/libvir-
list/2018-April/msg01408.html

** Changed in: libvirt (Ubuntu)
   Status: New => In Progress

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Bionic)
   Importance: Undecided
   Status: In Progress

** Also affects: libvirt (Ubuntu Artful)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1764668

Title:
  guest cleanup script fails to iterate

Status in libvirt package in Ubuntu:
  In Progress
Status in libvirt source package in Xenial:
  Confirmed
Status in libvirt source package in Artful:
  Confirmed
Status in libvirt source package in Bionic:
  In Progress

Bug description:
  The recent fix to libvirt-guests.sh.in works for what it intended to fix
  (variable scope) but failed to adapt the loop in check_guests_shutdown 
correctly.
  Due to that it currently detects all guests as "Failed to determine state of 
guest".

  It all works, but guests are just assumed dead and logs are spilled
  with false-positive warnings.

  A suggested fix is at:
  
https://git.launchpad.net/~paelzer/libvirt/commit/?id=2ccca91678cd1091163490fd0b466b58c8be2b79

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1764668/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 955379] Re: cmake hangs with qemu-arm-static

[ChristianEhrhardt]

That means our assumption taken in comment #63 that it was fixed in
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=014628a705bdaf31c09915
either was wrong (unset fix released) - or this is a similar but not the
same issue (which would imply a new bug since this already has plenty of
potentially mismatching history).

Given the time this was considered closed I'd vote for a new bug to analyze 
things from scratch.
@David - would you mind opening a new bug?

@TJ - before considering backporting something of the current solution to 
xenial, (all other releases are >=2.7) would you mind testing e.g. qemu 2.10 
via [1].
Also a trivial reproducer will help to make this SRUable, like David added his 
(for the probably new issue). Or is the one in comment #58 representing your 
case as well?

[1]: https://wiki.ubuntu.com/OpenStack/CloudArchive#Pike

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: qemu (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

Status in QEMU:
  Fix Released
Status in Linaro QEMU:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu-linaro package in Ubuntu:
  Confirmed
Status in qemu source package in Xenial:
  Incomplete
Status in qemu-linaro source package in Xenial:
  New

Bug description:
  I'm using git commit 3e7ecd976b06f... configured with --target-list
  =arm-linux-user --static in a chroot environment to compile some
  things. I ran into this problem with both pcl and opencv-2.3.1. cmake
  consistently freezes at some point during its execution, though in a
  different spot each time, usually during a step when it's searching
  for some libraries. For instance, pcl most commonly stops after:

  [snip]
  -- Boost version: 1.46.1
  -- Found the following Boost libraries:
  --   system
  --   filesystem
  --   thread
  --   date_time
  -- checking for module 'eigen3'
  --   found eigen3, version 3.0.1

  which is perplexing because it freezes after finding what it wants,
  not during the search. When it does get past that point, it does so
  almost immediately but freezes somewhere else.

  I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic
  with an Intel i5.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 955379] Re: cmake hangs with qemu-arm-static

[ChristianEhrhardt]

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: qemu-linaro (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

Status in QEMU:
  Fix Released
Status in Linaro QEMU:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu-linaro package in Ubuntu:
  Confirmed
Status in qemu source package in Xenial:
  Incomplete
Status in qemu-linaro source package in Xenial:
  New

Bug description:
  I'm using git commit 3e7ecd976b06f... configured with --target-list
  =arm-linux-user --static in a chroot environment to compile some
  things. I ran into this problem with both pcl and opencv-2.3.1. cmake
  consistently freezes at some point during its execution, though in a
  different spot each time, usually during a step when it's searching
  for some libraries. For instance, pcl most commonly stops after:

  [snip]
  -- Boost version: 1.46.1
  -- Found the following Boost libraries:
  --   system
  --   filesystem
  --   thread
  --   date_time
  -- checking for module 'eigen3'
  --   found eigen3, version 3.0.1

  which is perplexing because it freezes after finding what it wants,
  not during the search. When it does get past that point, it does so
  almost immediately but freezes somewhere else.

  I'm using 64-bit Ubuntu 11.10 with kernel release 3.0.0-16-generic
  with an Intel i5.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1723914] Re: ubuntu-kvm-unit test failed with emulator test on ppc64le

[ChristianEhrhardt]

Regression tests good as well, moving it to x-unapproved for the SRU Team to 
consider.
=> qemu_2.5+dfsg-5ubuntu10.25_source.changes

** Changed in: qemu (Ubuntu Xenial)
   Status: Triaged => In Progress

** Changed in: qemu (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1723914

Title:
  ubuntu-kvm-unit test failed with emulator test on ppc64le

Status in The Ubuntu-power-systems project:
  In Progress
Status in linux package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  New
Status in qemu source package in Xenial:
  In Progress
Status in linux source package in Artful:
  New
Status in qemu source package in Artful:
  Fix Released

Bug description:
  [Impact]

   * on start of qemu-system-ppc64 MSR_SF is not set correctly
     So it doesn't start 64bit as it should

   * Todays guests usually work around this and are fine, but it is
     incorrect and might be an issue down the road. Furthermore this is also
     a fixup to some verification tests at the same time.

  [Test Case]

   * 1. deploy xenial + HWE kernel on a ppc64el box
     2. sudo apt-get install qemu-kvm -y
     3. git clone --depth=1 
https://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git
     4. cd kvm-unit-tests
     5. ./configure --endian=little; make
     6. sudo ppc64_cpu --smt=off
     7. sudo ./run_tests.sh -v

  [Regression Potential]

   * The changes are ppc only and provided by IBM so the potential risk is
     retained to the owner of the Area.
     Further the change is very small, so it has a very low amount of being
     misunderstood.

  [Other Info]

   * n/a

  ---

  Similar to bug 1723904, bug 1712803.
  The failed "emulator" test from kvm-unit-test will pass with qemu-2.7.1 built 
from source.

  ubuntu@modoc:~/kvm-unit-tests$ sudo /bin/bash -c "TESTNAME=emulator 
TIMEOUT=90s ACCEL= ./powerpc/run powerpc/emulator.elf -smp 1
  > "
  timeout -k 1s --foreground 90s /usr/bin/qemu-system-ppc64 -nodefaults 
-machine pseries,accel=kvm -bios powerpc/boot_rom.bin -display none -serial 
stdio -kernel powerpc/emulator.elf -smp 1 # -initrd /tmp/tmp.BJ2sE7V2Jc
  FAIL: emulator: 64bit: detected
  PASS: emulator: invalid: exception
  PASS: emulator: lswx: alignment
  PASS: emulator: lswi: alignment
  SUMMARY: 4 tests, 1 unexpected failures

  EXIT: STATUS=3

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.10.0-37-generic 4.10.0-37.41~16.04.1
  ProcVersionSignature: User Name 4.10.0-37.41~16.04.1-generic 4.10.17
  Uname: Linux 4.10.0-37-generic ppc64le
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: ppc64el
  Date: Mon Oct 16 10:10:46 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcLoadAvg: 0.00 0.00 0.57 1/1457 83356
  ProcLocks:
   1: POSIX  ADVISORY  WRITE 1604 00:14:19651 0 EOF
   2: POSIX  ADVISORY  WRITE 2937 00:14:55331 0 EOF
   3: FLOCK  ADVISORY  WRITE 3046 00:14:67623 0 EOF
   4: POSIX  ADVISORY  WRITE 3124 00:14:57398 0 EOF
   5: POSIX  ADVISORY  WRITE 3047 00:14:87068 0 EOF
  ProcSwaps:
   Filename TypeSizeUsedPriority
   /swap.img   file 8388544 0   -1
  ProcVersion: Linux version 4.10.0-37-generic (buildd@bos01-ppc64el-026) (gcc 
version 5.4.0 20160609 (User Name/IBM 5.4.0-6ubuntu1~16.04.4) ) 
#41~16.04.1-User Name SMP Fri Oct 6 22:44:24 UTC 2017
  SourcePackage: linux-hwe
  UpgradeStatus: No upgrade log present (probably fresh install)
  cpu_cores: Number of cores present = 20
  cpu_coreson: Number of cores online = 20
  cpu_smt: SMT is off

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1723914/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1723904] Re: ubuntu-kvm-unit test failed with sprs test on ppc64le

[ChristianEhrhardt]

Since the fix is in 2.9 only Xenial is considered for the SRU as
>=Artful is good

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: qemu (Ubuntu)
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1723904

Title:
  ubuntu-kvm-unit test failed with sprs test on ppc64le

Status in linux package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  New
Status in qemu source package in Xenial:
  Triaged

Bug description:
  The sprs test has failed on ppc64le
  This issue can be spotted on Zesty and Xenial. There is no history for this 
test on Artful

  $ sudo /bin/bash -c "MIGRATION=yes TESTNAME=sprs TIMEOUT=90s ACCEL= 
./powerpc/run powerpc/sprs.elf -smp 1 -append '-w'"
  run_migration timeout -k 1s --foreground 90s /usr/bin/qemu-system-ppc64 
-nodefaults -machine pseries,accel=kvm -bios powerpc/boot_rom.bin -display none 
-serial stdio -kernel powerpc/sprs.elf -smp 1 -append -w # -initrd 
/tmp/tmp.RUTL6E2JSi
  Settings SPRs to 0xcafefacec0debabe...
  Now migrate the VM, then press a key or send NMI...
  Checking SPRs...
  PASS: SPR 3:  0x00debabe <==> 0x00debabe
  PASS: SPR 13: 0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 17: 0x00debabe <==> 0x00debabe
  PASS: SPR 18: 0xc0debabe <==> 0xc0debabe
  PASS: SPR 19: 0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 29: 0xcafefacec0debabe <==> 0xcafefacec0debabe
  FAIL: SPR 61: 0x4054504440541014 <==> 00
  PASS: SPR 153:0x0a84 <==> 0x0a84
  PASS: SPR 157:0xcfcfc0cf <==> 0xcfcfc0cf
  FAIL: SPR 159:0xc0debabe <==> 00
  PASS: SPR 256:0xc0debabe <==> 0xc0debabe
  PASS: SPR 259:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 274:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 275:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 769:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 770:0xcafefacec006babe <==> 0xcafefacec006babe
  PASS: SPR 771:0xc0debabe <==> 0xc0debabe
  PASS: SPR 772:0xc0debabe <==> 0xc0debabe
  PASS: SPR 773:0xc0debabe <==> 0xc0debabe
  PASS: SPR 774:0xc0debabe <==> 0xc0debabe
  PASS: SPR 775:0xc0debabe <==> 0xc0debabe
  PASS: SPR 776:0xc0debabe <==> 0xc0debabe
  PASS: SPR 779:0xfa8b1afe <==> 0xfa8b1afe
  PASS: SPR 780:0xcafefacec0debabc <==> 0xcafefacec0debabc
  PASS: SPR 781:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 782:0xcafefacec0debabe <==> 0xcafefacec0debabe
  FAIL: SPR 784:0xcafefacec0debabe <==> 00
  PASS: SPR 785:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 786:0xcafefacec006babe <==> 0xcafefacec006babe
  PASS: SPR 787:0xc0debabe <==> 0xc0debabe
  PASS: SPR 788:0xc0debabe <==> 0xc0debabe
  PASS: SPR 789:0xc0debabe <==> 0xc0debabe
  PASS: SPR 790:0xc0debabe <==> 0xc0debabe
  PASS: SPR 791:0xc0debabe <==> 0xc0debabe
  PASS: SPR 792:0xc0debabe <==> 0xc0debabe
  PASS: SPR 795:0xfa8b1afe <==> 0xfa8b1afe
  PASS: SPR 796:0xcafefacec0debabc <==> 0xcafefacec0debabc
  PASS: SPR 797:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 798:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 800:0x8000c000 <==> 0x8000c000
  PASS: SPR 801:0x8000 <==> 0x8000
  PASS: SPR 802:0x8000c000 <==> 0x8000c000
  PASS: SPR 803:0x8000 <==> 0x8000
  PASS: SPR 804:0xcafefacec0debabe <==> 0xcafefacec0debabe
  PASS: SPR 805:0xcafefacec0debabc <==> 0xcafefacec0debabc
  PASS: SPR 806:0x8000c000 <==> 0x8000c000
  FAIL: SPR 815:0xcafefacec0debabe <==> 00
  SUMMARY: 47 tests, 4 unexpected failures

  EXIT: STATUS=3

  $ qemu-system-ppc --version
  QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.16), Copyright (c) 
2003-2008 Fabrice Bellard

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.10.0-37-generic 4.10.0-37.41~16.04.1
  ProcVersionSignature: User Name 4.10.0-37.41~16.04.1-generic 4.10.17
  Uname: Linux 4.10.0-37-generic p

[Group.of.nepali.translators] [Bug 1723914] Re: ubuntu-kvm-unit test failed with emulator test on ppc64le

[ChristianEhrhardt]

Since this fix is in 2.6 is is in >=Yakkety, so nonly considering Xenial
for the SRU

** Also affects: qemu (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1723914

Title:
  ubuntu-kvm-unit test failed with emulator test on ppc64le

Status in The Ubuntu-power-systems project:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  New
Status in linux source package in Xenial:
  New
Status in qemu source package in Xenial:
  Triaged
Status in linux source package in Artful:
  New
Status in qemu source package in Artful:
  Fix Released

Bug description:
  Similar to bug 1723904, bug 1712803.
  The failed "emulator" test from kvm-unit-test will pass with qemu-2.7.1 built 
from source.

  ubuntu@modoc:~/kvm-unit-tests$ sudo /bin/bash -c "TESTNAME=emulator 
TIMEOUT=90s ACCEL= ./powerpc/run powerpc/emulator.elf -smp 1
  > "
  timeout -k 1s --foreground 90s /usr/bin/qemu-system-ppc64 -nodefaults 
-machine pseries,accel=kvm -bios powerpc/boot_rom.bin -display none -serial 
stdio -kernel powerpc/emulator.elf -smp 1 # -initrd /tmp/tmp.BJ2sE7V2Jc
  FAIL: emulator: 64bit: detected
  PASS: emulator: invalid: exception
  PASS: emulator: lswx: alignment
  PASS: emulator: lswi: alignment
  SUMMARY: 4 tests, 1 unexpected failures

  EXIT: STATUS=3

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.10.0-37-generic 4.10.0-37.41~16.04.1
  ProcVersionSignature: User Name 4.10.0-37.41~16.04.1-generic 4.10.17
  Uname: Linux 4.10.0-37-generic ppc64le
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: ppc64el
  Date: Mon Oct 16 10:10:46 2017
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcLoadAvg: 0.00 0.00 0.57 1/1457 83356
  ProcLocks:
   1: POSIX  ADVISORY  WRITE 1604 00:14:19651 0 EOF
   2: POSIX  ADVISORY  WRITE 2937 00:14:55331 0 EOF
   3: FLOCK  ADVISORY  WRITE 3046 00:14:67623 0 EOF
   4: POSIX  ADVISORY  WRITE 3124 00:14:57398 0 EOF
   5: POSIX  ADVISORY  WRITE 3047 00:14:87068 0 EOF
  ProcSwaps:
   Filename TypeSizeUsedPriority
   /swap.img   file 8388544 0   -1
  ProcVersion: Linux version 4.10.0-37-generic (buildd@bos01-ppc64el-026) (gcc 
version 5.4.0 20160609 (User Name/IBM 5.4.0-6ubuntu1~16.04.4) ) 
#41~16.04.1-User Name SMP Fri Oct 6 22:44:24 UTC 2017
  SourcePackage: linux-hwe
  UpgradeStatus: No upgrade log present (probably fresh install)
  cpu_cores: Number of cores present = 20
  cpu_coreson: Number of cores online = 20
  cpu_smt: SMT is off

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1723914/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1481272] Re: main-loop: WARNING: I/O thread spun for 1000 iterations

[ChristianEhrhardt]

Nice, thanks for the update.
I checked a few recent logs and agree that the message is gone since 2.9

Some might still encounter slow guests (for other reasons) and trigger
the message, but the most common TCG emulation case is solved by this
since Artful and later.

I think we don't want to backport all the prereqs (I/O thread locking
changes) to Xenial that allow to add this change here.

** Also affects: qemu (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: qemu (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: qemu (Ubuntu Bionic)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1481272

Title:
  main-loop: WARNING: I/O thread spun for 1000 iterations

Status in QEMU:
  New
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Artful:
  Fix Released
Status in qemu source package in Bionic:
  Fix Released

Bug description:
  I compile the latest qemu to launch a VM but the monitor output the
  "main-loop: WARNING: I/O thread spun for 1000 iterations".

  # /usr/local/bin/qemu-system-x86_64 -name rhel6 -S -no-kvm -m 1024M -realtime 
mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 
c9dd2a5c-40f2-fd3d-3c54-9cd84f8b9174 -rtc base=utc  -drive 
file=/home/samba-share/ubuntu.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none
 -device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=disk,serial=425618d4-871f-4021-bc5d-bcd7f1b5ca9c,bootindex=0
 -vnc :1 -boot menu=on -monitor stdio
  QEMU 2.3.93 monitor - type 'help' for more information
  (qemu) c
  (qemu) main-loop: WARNING: I/O thread spun for 1000 iterations   
<---

  qemu]# git branch -v
  * master   e95edef Merge remote-tracking branch 
'remotes/sstabellini/tags/xen-migration-2.4-tag' into staging

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1481272/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1755681] Re: pstree crashes on fclose(NULL)

[ChristianEhrhardt]

I think you are right here, not sure what happened to the triager of
march 14th.

23 is in Artful and Bionic already.
So the question here is to backport via an SRU to Xenial

** Also affects: psmisc (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: psmisc (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1755681

Title:
  pstree crashes on fclose(NULL)

Status in psmisc package in Ubuntu:
  Fix Released
Status in psmisc source package in Xenial:
  Confirmed

Bug description:
  I am on 16.04.4 LTS.  I am seeing pstree crash intermittently, and I
  tracked it down to an fclose(NULL):

  
https://gitlab.com/psmisc/psmisc/blob/28005b99fedef566b06286bd6ca72a7a4d673f20/src/pstree.c#L822

  I am guessing it is a race condition where the procfs entry disappears
  between dir listing and the fopen() call several lines above.

  This is fixed in the latest release (v23.0, released 9 months ago) but
  exists in the current version of psmisc for 16.04.4 (v22.21).

  Would this call for a bump of the upstream version, or an Ubuntu-
  specific patch to remove that fclose() call?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/psmisc/+bug/1755681/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1756987] Re: chrony install does not stop systemd-timesyncd

[ChristianEhrhardt]

The way the newer versions solve this is to have a native systemd
service and in there there is:

Conflicts=systemd-timesyncd.service openntpd.service

That ensures only one of these can be started.

Xenial has no systemd service at all, it has sysV and uses the systemd 
generator.
So there is no "just add the line" fix available.

Xenial as-is
$ timedatectl status
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no
systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
   └─disable-with-time-daemon.conf
   Active: active (running) since Wed 2018-03-21 16:00:19 UTC; 1min 30s ago

This isn't even fully protected if you install ntp (not chrony) as it
was the ntp server back in Xenial. (Right after install it still runs).

What stops it there for NTPd is that this uses a config dir which pulls in:
  /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

So any further starts will be blocked:
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

You see that if you check systemd-timesyncd.service:
$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
   └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Wed 2018-03-21 16:06:42 UTC; 44s ago
   ConditionFileIsExecutable=!/usr/sbin/ntpd was not met

After installing Chrony this is the same:

Condition: start condition failed at Wed 2018-03-21 16:11:37 UTC; 1s ago
   ConditionFileIsExecutable=!/usr/sbin/chronyd was not met

That is good (no special issue to chrony) and bad (actually all
timeservers "collide" right after install).

A reboot or restart will pick that up.
OTOH it is discouraged to start/stop/restart other packages services form a 
postinst - as the first thought would be to do refresh for that condition after 
installing any of these.

Given that there was not a single complaint about it in 2 years of
Xenial other than us now looking for it in detail I'd rate it low, but
it is a valid issue.

** Also affects: ntp (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: openntpd (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: ntp (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: ntp (Ubuntu Xenial)
   Importance: Undecided => Low

** Changed in: chrony (Ubuntu Bionic)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1756987

Title:
  chrony install does not stop systemd-timesyncd

Status in chrony package in Ubuntu:
  Fix Released
Status in ntp package in Ubuntu:
  New
Status in openntpd package in Ubuntu:
  New
Status in chrony source package in Xenial:
  New
Status in ntp source package in Xenial:
  Confirmed
Status in openntpd source package in Xenial:
  New
Status in chrony source package in Artful:
  New
Status in ntp source package in Artful:
  New
Status in openntpd source package in Artful:
  New
Status in chrony source package in Bionic:
  Fix Released
Status in ntp source package in Bionic:
  New
Status in openntpd source package in Bionic:
  New

Bug description:
  1.
  root@ubuntu:~# lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  2. 
  root@ubuntu:~# apt-cache policy systemd
  systemd:
Installed: 229-4ubuntu21.1
Candidate: 229-4ubuntu21.1
Version table:
   *** 229-4ubuntu21.1 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   229-4ubuntu4 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  root@ubuntu:~# apt-cache policy chrony
  chrony:
Installed: 2.1.1-1
Candidate: 2.1.1-1
Version table:
   *** 2.1.1-1 500
  500 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
  100 /var/lib/dpkg/status

  3. installing chrony should stop systemd-timesyncd so they both don't
  try to adjust time

  4. after chrony is installed both systemd-timesyncd and chronyd are
  running.

  root@ubuntu:~# ps aux | egrep "(ch

[Group.of.nepali.translators] [Bug 1741390] Re: Please backport open-vm-tools 2:10.2.0-3 (main) from bionic

[ChristianEhrhardt]

** Also affects: open-vm-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: open-vm-tools (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: open-vm-tools (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: open-vm-tools (Ubuntu Xenial)
   Importance: Undecided => High

** Description changed:

+ TODO - SRU Template
+ 
+ ---
+ 
+ This is no more intended to be a backport, but instead an SRU
+ Keep the content if ever needed again.
+ 
  Description:
  Please backport open-vm-tools 2:10.2.0-3 (main) from bionic to xenial.
  
  Reason for the backport:
  
  Newer versions of VMWare ESXi, especially newer features of those require the 
availability of newer open-vm-tools in the guest.
  Making that available as an SRU is at the moment considered to be too much of 
a risk due to the lack of a vast array of ESXi verification setups.
  But it seems good and somewhat tested, while OTOH important for several 
users, which is why it seems the backports pocket is just the right pocket to 
go to.
  
  Testing:
  
  A ppa is made available for testing at:
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3152
  You can test it with:
  sudo add-apt-repository ppa:ci-train-ppa-service/3152
  apt install open-vm-tools
  
  * xenial - build:
  [No - see below] Package builds without modification
  
  * xenial - install:
  (tested on VMWare Workstation 14 - upgrading to ppa version)
  [X] open-vm-tools installs cleanly and runs
  [X] open-vm-tools-desktop installs cleanly and runs
  [X] open-vm-tools-dev installs cleanly and runs
  (ppa builds with debug, so I enabled debug from ppa for these tests)
  [X] open-vm-tools-desktop-dbgsym installs cleanly and runs
  [X] open-vm-tools-dbgsym installs cleanly and runs
  
  * Modifications:
  The backport needs some modifications to build:
  - run autoreconf/systemd dh helpers
  - use the older debhelper B-D
  - revert to compat 10 (which is the latest supported in xenial)
  Modifications are made available as git tree for easy review.
  => 
https://code.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+ref/backport-xenial-lp1741390
  
  You might need to get the tarballs first to build so I recommend:
  $ pull-lp-source open-vm-tools
  $ git clone -b backport-xenial-lp1741390 
https://git.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools
  Then you can review/modify/build locally
  $ cd open-vm-tools
  $ dpkg-buildpackage -S -nc -d -sa -v2:10.0.7-3227872-5ubuntu1~16.04.1
  
  If you are a "git ubuntu" user you could also do
  $ git ubuntu clone open-vm-tools
  $ git ubuntu remote add paelzer
  $ git checkout backport-xenial-lp1741390
  
  Reverse dependencies:
  =
  The following reverse-dependencies need to be tested against the new version 
of open-vm-tools. For reverse-build-dependencies (-Indep), please test that the 
package still builds against the new open-vm-tools. For reverse-dependencies, 
please test that the version of the package currently in the release still 
works with the new open-vm-tools installed. Reverse- Recommends, Suggests, and 
Enhances don't need to be tested, and are listed for completeness-sake.
  
  open-vm-tools
  -
  * ubuntu-server
-   -- the base version is seeded, nothing to test-rebuild
-   [X] xenial (Reverse-Depends)
+   -- the base version is seeded, nothing to test-rebuild
+   [X] xenial (Reverse-Depends)
  * open-vm-tools-dkms
-   -- the newer version no more provides and no more depends on that
-   -- the breaks/replaces is very old and no issue
-   [X] xenial (Reverse-Recommends)
-   [X] xenial (Reverse-Replaces)
-   [X] xenial (Reverse-Breaks)
+   -- the newer version no more provides and no more depends on that
+   -- the breaks/replaces is very old and no issue
+   [X] xenial (Reverse-Recommends)
+   [X] xenial (Reverse-Replaces)
+   [X] xenial (Reverse-Breaks)
  * procps
-   -- very old break, no issue
-   [X] xenial (Reverse-Breaks)
+   -- very old break, no issue
+   [X] xenial (Reverse-Breaks)
  * usrmerge
-   -- very old conflict, no issue
-   [X] xenial (Reverse-Conflicts)
+   -- very old conflict, no issue
+   [X] xenial (Reverse-Conflicts)
  
  open-vm-tools-desktop-dbgsym
  
  
  open-vm-tools-dbgsym
  
  
  open-vm-tools-desktop
  -
  * open-vm-tools-dkms
-   -- the -dkms package is no more provided - no issue
-   [X] xenial (Reverse-Suggests)
+   -- the -dkms package is no more provided - no issue
+   [X] xenial (Reverse-Suggests)
  
  open-vm-tools-dev
  -
  
- 
  - original bug -
- 
  
  The latest Xenial open-vm-tools package is almost two years out of date.
  
  I'm building Xenial systems in an up-to-date VMware environment and I
  need VMware tools updated to the latest stable version.  We have
  experienced problems with VMware products when different components were
  mism

[Group.of.nepali.translators] [Bug 1688508] Re: libvirt-guests.sh fails to shutdown guests in parallel

[ChristianEhrhardt]

Thanks Dariusz,
TL;DR we want this to be cancelled from SRU and need to rework upstream.
>From there into Bionic (which would be released that way) and from there 
>reconsidering SRU.

Resetting Task status and verification tags.

** Tags added: 4.0.0-1ubuntu6 needs-upstreaming

** Tags removed: verification-needed verification-needed-artful 
verification-needed-xenial
** Tags added: verification-failed verification-failed-artful 
verification-failed-xenial

** Changed in: libvirt (Ubuntu Artful)
   Status: Fix Committed => Triaged

** Changed in: libvirt (Ubuntu Xenial)
   Status: Fix Committed => Triaged

** Changed in: libvirt (Ubuntu)
   Status: Fix Released => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1688508

Title:
  libvirt-guests.sh fails to shutdown guests in parallel

Status in libvirt:
  Fix Released
Status in libvirt package in Ubuntu:
  In Progress
Status in libvirt source package in Xenial:
  Triaged
Status in libvirt source package in Zesty:
  Won't Fix
Status in libvirt source package in Artful:
  Triaged

Bug description:
  [Environment]

  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  Codename: xenial

  [Impact]

  There is a bug/race condition on libvirt-guests.service, that prevents
  the shutdown of guests to happen in parallel.

  The critical chain for this service is:

  libvirt-guests.service +20ms
  └─libvirt-bin.service @2.784s +140ms
    └─remote-fs.target @2.777s
  └─remote-fs-pre.target @2.775s
    └─open-iscsi.service @2.554s +116ms
  └─iscsid.service @2.525s +18ms
    └─network-online.target @2.502s
  └─network.target @1.955s
    └─networking.service @1.625s +299ms
  └─network-pre.target @1.601s
    └─cloud-init-local.service @405ms +1.072s
  └─systemd-remount-fs.service @232ms +64ms
    └─systemd-journald.socket @178ms
  └─-.slice @117ms

  As an example, I have the following kvm host with 42 virtual
  machines.

  ubuntu@xenial-base:~$ virsh list --all
   IdName   State
  
   12locked-trusty-2running
   13locked-trusty-3running
  [...]
   41locked-trusty-42   running

  After rebooting the machine:

  [  250.999516] libvirt-guests.sh[4215]: Running guests on default URI: 
locked-trusty-2, locked-trusty-4, locked-trusty-12, locked-trusty-3, 
locked-trusty-5, locked-trusty-11, locked-trusty-10, locked-trusty-8, 
locked-trusty-9, locked-trusty-7, locked-trusty-6, locked-trusty-13, 
locked-trusty-14, locked-trusty-15, locked-trusty-16, locked-trusty-17, 
locked-trusty-18, locked-trusty-19, locked-trusty-20, locked-trusty-21, 
locked-trusty-22, locked-trusty-23, locked-trusty-24, locked-trusty-25, 
locked-trusty-26, locked-trusty-27, locked-trusty-28, locked-trusty-29, 
locked-trusty-30, locked-trusty-31, locked-trusty-32, locked-trusty-33, 
locked-trusty-34, locked-trusty-35, locked-trusty-36, locked-trusty-37, 
locked-trusty-38, locked-trusty-39, locked-trusty-40, locked-trusty-41, 
locked-trusty-42
  [  251.011367] libvirt-guests.sh[4215]: Shutting down guests on default URI...
  [  251.027072] libvirt-guests.sh[4215]: Starting shutdown on guest: 
locked-trusty-2
  [...]
  [  391.949941] libvirt-guests.sh[4215]: Waiting for 28 guests to shut down, 
10 seconds left
  [  398.074405] libvirt-guests.sh[4215]: Waiting for 28 guests to shut down, 5 
seconds left
  [  403.020479] libvirt-guests.sh[4215]: Timeout expired while shutting down 
domains
  [  OK  ] Stopped Suspend Active Libvirt Guests.
  [  OK  ] Stopped target System Time Synchronized.

  [Test Case]

   * Make sure the following variables are set in /etc/default/libvirt-
  guests (which are all default options):

  ON_SHUTDOWN=shutdown
  PARALLEL_SHUTDOWN=10
  SHUTDOWN_TIMEOUT=120

   * Create over 20 virtual machines (in my case, using uvt-kvm).

  $  for f in $(seq 0 40); do uvt-kvm create --memory 2000 --cpu 1
  locked-trusty-$f release=xenial arch=amd64 ; done

   * Reboot the machine and monitor the systemd service stop sequence
  or console output.

  (With systemd: systemctl start debug-shell and jumpt to ctrl+alt+f9)

  * Error message "Timeout expired while shutting down domains" should
  be displayed.

  [Regression Potential]

  * None identified.

  [Other Info]

  * There is a proposed patch in upstream already that has been already
  linked to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1450141

To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1688508/+subscriptions

___
Mailing 

[Group.of.nepali.translators] [Bug 40189] Re: [SRU] [xenial] autofs needs to be restarted to pick up some shares

[ChristianEhrhardt]

Thanks for the ping on this lnog standing bug @Tronde.
I updated the state accordingly.

If there is a change to be identified since Xenial->Bionic one could try to SRU 
fix it in Xenial.
But I took a (quick) look and found nothing obvious.
There are major changes like going from sysV init in /etc/init.d/autofs to a 
native systemd service in /lib/systemd/system/autofs.service.
One would need to debug if there is something that can be brought into the 
systemV init to fix it.

I appreciate your former steps to reproduce, but they failed for me :-/
Without having more time debugging why I can't reproduce atm I'd need to ask 
you (or others) to debug what the missing new bit might be to fix up xenial.

** Also affects: autofs (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: upstart (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: autofs5 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: autofs (Ubuntu)
   Status: Confirmed => Fix Released

** No longer affects: autofs5 (Ubuntu Xenial)

** No longer affects: upstart (Ubuntu Xenial)

** Changed in: autofs (Ubuntu Xenial)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/40189

Title:
  [SRU] [xenial] autofs needs to be restarted to pick up some shares

Status in autofs package in Ubuntu:
  Fix Released
Status in autofs5 package in Ubuntu:
  Invalid
Status in upstart package in Ubuntu:
  Invalid
Status in autofs source package in Xenial:
  Incomplete

Bug description:
  I am using autofs to access shares on a Windows XP machine from a
  Kubuntu AMD64 machine.  The problems applies in both Breezy and
  Dapper.

  EDIT:  confirmed with similar configuration on Intrepid with a NetApp
  filer hosting NFS.  Server OS removed from summary.

  When I first try to access the mount point via cd or in Konqueror it
  does not exist.  However,  if I then restart autofs
  (/etc/init.d/autofs restart) everythin then works OK.  My config files
  are:

  auto.master

  #
  # $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
  #
  # Sample auto.master file
  # This is an automounter map and it has the following format
  # key [ -mount-options-separated-by-comma ] location
  # For details of the format look at autofs(5).
  #/misc/etc/auto.misc --timeout=60
  #/misc/etc/auto.misc
  #/net /etc/auto.net

  /petunia /etc/petunia.misc --timeout=60

  
  petunia.misc

  #
  # $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
  #
  # This is an automounter map and it has the following format
  # key [ -mount-options-separated-by-comma ] location
  # Details may be found in the autofs(5) manpage

  cd  -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom

  tony  -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 
://192.168.1.2/tony
  chris -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 
://192.168.1.2/chris
  shared-fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 
://192.168.1.2/SharedDocs
  linuxbackups  -fstype=smbfs,defaults,password=xxx,fmask=777,dmask=777 
://192.168.1.2/linuxbackups

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/40189/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

[ChristianEhrhardt]

For open-vm-tools this issue will only exist with the planned backport of the 
newer version.
Since we will not ship the broken backport as we found it in pre-checks the 
correct state for open-vm-tools in xenial is invalid.

** Changed in: open-vm-tools (Ubuntu Xenial)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1750780

Title:
  Race with local file systems can make open-vm-tools fail to start

Status in cloud-init:
  Invalid
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  New
Status in open-vm-tools package in Debian:
  Incomplete

Bug description:
  Since the change in [1] open-vm-tools-service starts very (very) early.
  Not so much due to the 
  Before=cloud-init-local.service
  But much more by
  DefaultDependencies=no

  That can trigger an issue that looks like
  root@ubuntuguest:~# systemctl status -l open-vm-tools.service
  ● open-vm-tools.service - Service for virtual machines hosted on VMware
 Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: resources)

  
  As it is right now open-vm-tools can race with the other early start and then 
fail.
  In detail one can find a message like:
open-vm-tools.service: Failed to run 'start' task: Read-only file system"

  This is due to privtaeTmp=yes which is also set needing a writable
  /var/tmp [2]

  To ensure this works PrivateTmp would have to be removed (not good) or some 
after dependencies added that make this work reliably.
  I added
  After=local-fs.target
  which made it work for me in 3/3 tests.

  I' like to have an ack by the cloud-init Team that this does not totally kill 
the originally intended Before=cloud-init-local.service
  I think it does not as local-fs can complete before cloud-init-local, then 
open-vm-tools can initialize and finally cloud-init-local can pick up the data.

  To summarize:
  # cloud-init-local #
  DefaultDependencies=no
  Wants=network-pre.target
  After=systemd-remount-fs.service
  Before=NetworkManager.service
  Before=network-pre.target
  Before=shutdown.target
  Before=sysinit.target
  Conflicts=shutdown.target
  RequiresMountsFor=/var/lib/cloud

  # open-vm-tools #
  DefaultDependencies=no
  Before=cloud-init-local.service

  Proposed is to add to the latter:
  After=local-fs.target

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677
  [2]: https://github.com/systemd/systemd/issues/5610

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750780/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1753604] Re: libvirt-bin nwfilter deadlock

[ChristianEhrhardt]

Thanks for the report Pooja,
this is fixed in v1.3.5

By that this in anything newer than Xenial via being upstream.

I need to take a look at backporting the suggested change to Xenial, but
that will probably not happen this week as I'm traveling.


** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: libvirt (Ubuntu Xenial)
   Status: Confirmed => Triaged

** Changed in: libvirt (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1753604

Title:
  libvirt-bin nwfilter deadlock

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Triaged

Bug description:
  When deleting a VM, libvirt-bin intermittently hits a deadlock in nwfilter 
instantiation code.
  This is fixed in libvirt upstream, but the below commit is not cherrypicked 
in ubuntu yet:
  
https://github.com/libvirt/libvirt/commit/2f5e24ba00d93c25b87561cb1f5259de175d70f9

  Thread 5 (Thread 0x7f2ce1c4b700 (LWP 13866)):
  #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  #1  0x7f2cee30ce42 in __GI___pthread_mutex_lock (mutex=0x7f2c980008d0) at 
../nptl/pthread_mutex_lock.c:115
  #2  0x7f2cc7d7a62f in virNWFilterLockIface () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
  #3  0x7f2cc7d6ebf5 in ?? () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
  #4  0x7f2cc7d6f84c in virNWFilterTeardownFilter () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
  ---Type  to continue, or q  to quit---
  #5  0x7f2ceea32f0c in virDomainConfVMNWFilterTeardown () from 
/usr/lib/x86_64-linux-gnu/libvirt.so.0
  #6  0x7f2cc73d5a86 in qemuProcessStop () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
  #7  0x7f2cc7420577 in ?? () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
  #8  0x7f2ceea857cf in virDomainDestroy () from 
/usr/lib/x86_64-linux-gnu/libvirt.so.0
  #9  0x55c4ba3fe9db in ?? ()
  #10 0x7f2ceeaf8f69 in virNetServerProgramDispatch () from 
/usr/lib/x86_64-linux-gnu/libvirt.so.0
  #11 0x7f2ceeaf4478 in ?? () from /usr/lib/x86_64-linux-gnu/libvirt.so.0
  #12 0x7f2cee9eb566 in ?? () from /usr/lib/x86_64-linux-gnu/libvirt.so.0
  #13 0x7f2cee9eaae8 in ?? () from /usr/lib/x86_64-linux-gnu/libvirt.so.0
  #14 0x7f2cee30a6ba in start_thread (arg=0x7f2ce1c4b700) at 
pthread_create.c:333
  #15 0x7f2cee04041d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

  
  Thread 17 (Thread 0x7f2cc2801700 (LWP 8866)):
  #0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  #1  0x7f2cee30ce42 in __GI___pthread_mutex_lock (mutex=0x7f2cc7f8d280) at 
../nptl/pthread_mutex_lock.c:115
  #2  0x7f2cc7d6f6d3 in virNWFilterInstantiateFilterLate () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
  #3  0x7f2cc7d7a9b2 in ?? () from 
/usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
  #4  0x7f2cee9eab12 in ?? () from /usr/lib/x86_64-linux-gnu/libvirt.so.0
  #5  0x7f2cee30a6ba in start_thread (arg=0x7f2cc2801700) at 
pthread_create.c:333
  #6  0x7f2cee04041d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1753604/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1730661] Re: New upstream microreleases 9.3.20, 9.5.10 and 9.6.6

[ChristianEhrhardt]

** Changed in: postgresql-10 (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1730661

Title:
  New upstream microreleases 9.3.20, 9.5.10 and 9.6.6

Status in postgresql-10 package in Ubuntu:
  Fix Released
Status in postgresql-9.3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-9.6 package in Ubuntu:
  Invalid
Status in postgresql-9.3 source package in Trusty:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-9.6 source package in Zesty:
  Fix Released
Status in postgresql-9.6 source package in Artful:
  Fix Released

Bug description:
  Update to the new set of releases as per the standing micro-release
  exception these should land in stable Ubuntu releases.

  Current versions in releases: 
  
   postgresql-9.3 | 9.3.19-0ubuntu0.14.04 trusty
  
   postgresql-9.5 | 9.5.9-0ubuntu0.16.04  xenial
  
   postgresql-9.6 | 9.6.5-0ubuntu0.17.04  zesty 
  
   postgresql-9.6 | 9.6.5-1   artful
  

  
  No "special" cases known this time.   
  

  
  Last stable updates   
  
  PostgreSQL 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24  
  

  
  So the todo is to pick:   
  
  MRE: Trusty 9.3.20 from 
https://borka.postgresql.org/staging/5d4e3dcc636f182a69ff7ff51286c1a20e930c9e/postgresql-9.3.20.tar.gz
  MRE: Xenial 9.5.10 from 
https://borka.postgresql.org/staging/5d4e3dcc636f182a69ff7ff51286c1a20e930c9e/postgresql-9.5.10.tar.gz
  MRE: Zesty 9.6.6 from 
https://borka.postgresql.org/staging/5d4e3dcc636f182a69ff7ff51286c1a20e930c9e/postgresql-9.6.6.tar.gz
  Sync: Artful 9.6.6 as above   
  

  
  Standing MRE - Consider last updates as template: 
  
  - pad.lv/1637236  
  
  - pad.lv/1664478  
  
  - pad.lv/1690730  
  
  - pad.lv/1713979

  Note: opening private as it is not yet announced

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-10/+bug/1730661/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

[ChristianEhrhardt]

Installed another Xenial and Bionic in vmware to take a deper look.
- Xenial (with backported open-vm-tools): affected
- Bionic (with the interim fix reverted): no hit in several retries, 
explanation below

Systemd fixed it (via our assumed implicit dependency).
In Bionic the PrivateTmp gives it a dependency on systemd-tmpfile-setup.service 
(seen in systemd analyze, there might be more but not on crit path).
This is configured by default to include /var/tmp in 
/usr/lib/tmpfiles.d/tmp.conf.

In regard to your thoughts about later on changing cloud-init ordering
that won't help you, as the dependency is there (implicit or explicit
doesn't matter).

For the xenial case where I reliably hit the issue instead of stracing I cut 
things short.
A service with the following exposes exactly the same error:
[Unit]
Description=foo
DefaultDependencies=no

[Service]
PrivateTmp=yes
ExecStart=/bin/true

[Install]
WantedBy=multi-user.target

So back on Xenial it is privateTmp + too early that breaks it.

Xenial vs Bionic critical-chain according to "systemd-analyze critical-
chain open.vm-tools.service"

Xenial with fix:
open-vm-tools.service @3.482s
└─local-fs.target @3.460s
  └─local-fs-pre.target @3.460s
└─systemd-remount-fs.service @3.442s +9ms
  └─system.slice @220ms
└─-.slice @204m

Xenial without fix:
└─run-vmblock\x2dfuse.mount @6.076s +390ms
  └─sys-fs-fuse-connections.mount @5.510s +375ms
└─systemd-modules-load.service @1.996s +75ms
  └─system.slice @1.984s
└─-.slice @1.966s

Bionic
open-vm-tools.service @3.566s
└─systemd-tmpfiles-setup.service @3.421s +100ms
  └─systemd-journal-flush.service @3.054s +342ms
└─systemd-journald.service @825ms +2.219s
  └─syslog.socket @808ms
└─system.slice @621ms
  └─-.slice @613ms

To Summarize, we can:
- revert the fix for Bionic (or later) - just make it a sync when convenient 
down the road, it doesn't hurt for now as it is (almost) the same as the 
implicit dependency)
- add a xenials systemd bug task (probably too complex to fix as -upstream)
- until said systemd bug is fixed a backport of open-vm-tools needs this fix


** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: open-vm-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: open-vm-tools (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: systemd (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1750780

Title:
  Race with local file systems can make open-vm-tools fail to start

Status in cloud-init:
  Invalid
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Triaged
Status in systemd source package in Xenial:
  New
Status in open-vm-tools package in Debian:
  Incomplete

Bug description:
  Since the change in [1] open-vm-tools-service starts very (very) early.
  Not so much due to the 
  Before=cloud-init-local.service
  But much more by
  DefaultDependencies=no

  That can trigger an issue that looks like
  root@ubuntuguest:~# systemctl status -l open-vm-tools.service
  ● open-vm-tools.service - Service for virtual machines hosted on VMware
 Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: resources)

  
  As it is right now open-vm-tools can race with the other early start and then 
fail.
  In detail one can find a message like:
open-vm-tools.service: Failed to run 'start' task: Read-only file system"

  This is due to privtaeTmp=yes which is also set needing a writable
  /var/tmp [2]

  To ensure this works PrivateTmp would have to be removed (not good) or some 
after dependencies added that make this work reliably.
  I added
  After=local-fs.target
  which made it work for me in 3/3 tests.

  I' like to have an ack by the cloud-init Team that this does not totally kill 
the originally intended Before=cloud-init-local.service
  I think it does not as local-fs can complete before cloud-init-local, then 
open-vm-tools can initialize and finally cloud-init-local can pick up the data.

  To summarize:
  # cloud-init-local #
  DefaultDependencies=no
  Wants=network-pre.target
  After=systemd-remount-fs.service
  Before=NetworkManager.service
  Before=network-pre.target
  Before=shutdown.target
  Before=sysinit.target
  Conflicts=shutdown.target
  RequiresMountsFor=/var/lib/cloud

  # open-vm-tools #
  DefaultDependencies=no
  Before=cloud-init-local.service

  Proposed is to add to the latter:
  After=local-fs.target

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677
  [2]: https://github.com/system

[Group.of.nepali.translators] [Bug 1466926] Re: reload apache2 with mpm_event cause scoreboard is full

[ChristianEhrhardt]

Thanks Tobias for all the tests.

With all that prep done I'll try to push it to SRU review now.

** Changed in: apache2 (Ubuntu Trusty)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1466926

Title:
  reload apache2  with mpm_event cause  scoreboard is full

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Trusty:
  Won't Fix
Status in apache2 source package in Xenial:
  Incomplete
Status in apache2 source package in Zesty:
  Fix Released

Bug description:
  On the clean install Ubuntu 14.04 with Apache without almost any
  client load the Apache server with the command "service apache2
  reload" itself allocates slots marked with "Gracefully finishing" for
  which rejects new connections.

  For full rejection of new requests is sufficient to perform 4x command
  "service apache2 reload".

  Ubuntu 14.04.2 LTS
  Apache 2.4.7-ubuntu4.4 (mpm_event)
  Kernel 2.16.0-30-generic

  
  Reproduce problem:
  #
  1/ service apache2 start
  __W_
  ___.
  ..

  2/ service apache2 reload

  .GGG
  GGG__W__
  __

  3/ service apache2 reload

  ___W_GGG
  GGG__...
  ..

  4/ service apache2 reload

  
  G___
  W_

  5/ service apache2 reload -> Server Apache not responding 
  With logs in apache error log file:
  ... [mpm_event:error] [pid 9381:tid 1234563234] AH00485: scoreboard is full, 
not at MaxRequestWorkers
  ...
  #

  
  My workaround was change to  MPM module  from "mpm_event" to "mpm_worker".

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1466926/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1383704] Re: Can't switch off SSLv3 cipher groups in haproxy

[ChristianEhrhardt]

Passing haproxy bugs after the latest stable 1-8 has landed in Ubuntu 18.04.
This bug is old and I agree with the former comment - setting states.

** Also affects: haproxy (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: haproxy (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: haproxy (Ubuntu Bionic)
   Importance: High
   Status: Triaged

** Also affects: haproxy (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: haproxy (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: haproxy (Ubuntu Bionic)
   Status: Triaged => Fix Released

** Changed in: haproxy (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: haproxy (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: haproxy (Ubuntu Trusty)
   Status: New => Invalid

** Changed in: haproxy (Ubuntu Precise)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1383704

Title:
  Can't switch off SSLv3 cipher groups in haproxy

Status in haproxy package in Ubuntu:
  Fix Released
Status in haproxy source package in Precise:
  Invalid
Status in haproxy source package in Trusty:
  Invalid
Status in haproxy source package in Xenial:
  Fix Released
Status in haproxy source package in Artful:
  Fix Released
Status in haproxy source package in Bionic:
  Fix Released

Bug description:
  You don't seem to be able to switch off cipher groups in haproxy -
  which makes it difficult to deal with the POODLE problem by turning
  off sslv3.

  If you add the 'no-sslv3' option to an ssl configuration, stop and
  start haproxy, and then run nmap against it.

  nmap --script ssl-enum-ciphers -p 443 

  you still see the sslv3 ciphers listed.

  Host is up (0.035s latency).
  PORTSTATE SERVICE
  443/tcp open  https
  | ssl-enum-ciphers: 
  |   SSLv3: 
  | ciphers: 
  |   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
  |   TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
  |   TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |   TLS_RSA_WITH_DES_CBC_SHA - weak
  |   TLS_RSA_WITH_RC4_128_MD5 - strong
  |   TLS_RSA_WITH_RC4_128_SHA - strong
  |   TLS_RSA_WITH_SEED_CBC_SHA - strong
  | compressors: 
  |   NULL
  |   TLSv1.0: 
  | ciphers: 
  |   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
  |   TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
  |   TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |   TLS_RSA_WITH_DES_CBC_SHA - weak
  |   TLS_RSA_WITH_RC4_128_MD5 - strong
  |   TLS_RSA_WITH_RC4_128_SHA - strong
  |   TLS_RSA_WITH_SEED_CBC_SHA - strong
  | compressors: 
  |   NULL
  |   TLSv1.1: 
  | ciphers: 
  |   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_DES_CBC_SHA - weak
  |   TLS_DHE_RSA_WITH_SEED_CBC_SHA - strong
  |   TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
  |   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
  |   TLS_RSA_WITH_DES_CBC_SHA - weak
  |   TLS_RSA_WITH_RC4_128_MD5 - strong
  |   TLS_RSA_WITH_RC4_128_SHA - strong
  |   TLS_RSA_WITH_SEED_CBC_SHA - strong
  | compressors: 
  |   NULL
  |   TLSv1.2: 
  | ciphers: 
  |   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong
  |   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong
  |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong
  |   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong
  |   TLS_DHE_RSA_WITH_

[Group.of.nepali.translators] [Bug 1720109] Re: snmpd stop on host stops snmpd on LXD containers

[ChristianEhrhardt]

Note: since 5.7.3+dfsg-1.4 a native systemd file is used which uses type=simple 
and MAINPID tracking.
So >= Artful this is already fixed.

Setting the status to fixed, but adding a Xenial task as there the issue
still exists.

** Also affects: net-snmp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: net-snmp (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: net-snmp (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: net-snmp (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1720109

Title:
  snmpd stop on host stops snmpd on LXD containers

Status in net-snmp package in Ubuntu:
  Fix Released
Status in net-snmp source package in Xenial:
  Triaged

Bug description:
  If you have ubuntu 16.04 containers running snmpd and you stop the
  snmpd on the LXD host system, it will also shut down all the snmpd
  instances on the containers (but will not restart them if you restart
  them on the LXD host) .. in fact, you even need to go back into the
  container, stop the snmpd before you can start it again.

  See log below, viepovzat17 is the LXD host, viezmaaat10 is the ubuntu
  container:

    driver: lxc
    driver_version: 2.0.8
    kernel: Linux
    kernel_architecture: x86_64
    kernel_version: 4.4.0-87-generic
    server: lxd
    server_pid: 4426
    server_version: "2.16"
    storage: zfs
    storage_version: 0.6.5.6-0ubuntu16

  root@viezmaaat10:~# /etc/init.d/snmpd start
  [ ok ] Starting snmpd (via systemctl): snmpd.service.
  root@viezmaaat10:~# ps -eaf | grep snmp
  snmp  1271 1  0 10:50 ?00:00:00 /usr/sbin/snmpd -Lsd -Lf 
/dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
  root  1291   757  0 10:50 ?00:00:00 grep --color=auto snmp
  root@viezmaaat10:~#
  root@viezmaaat10:~# ps -eaf | grep snmp
  snmp  1271 1  0 10:50 ?00:00:00 /usr/sbin/snmpd -Lsd -Lf 
/dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
  root  1293   757  0 10:50 ?00:00:00 grep --color=auto snmp
  root@viezmaaat10:~# exit

  root@viepovzat17:~# ps -eaf | grep snmp
  snmp 22757 1  0 10:45 ?00:00:00 /usr/sbin/snmpd -Lsd -Lf 
/dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
  100116   24118  5222  0 10:50 ?00:00:00 /usr/sbin/snmpd -Lsd -Lf 
/dev/null -u snmp -g snmp -I -smux mteTrigger mteTriggerConf -p /run/snmpd.pid
  root 24153 21842  0 10:50 pts/100:00:00 grep --color=auto snmp
  root@viepovzat17:~# /etc/init.d/snmpd stop
  [ ok ] Stopping snmpd (via systemctl): snmpd.service.
  root@viepovzat17:~# ps -eaf | grep snmp
  root 24286 21842  0 10:50 pts/100:00:00 grep --color=auto snmp
  root@viepovzat17:~#

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/net-snmp/+bug/1720109/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1748122] Re: incorrect tools.conf template is shipped with Ubuntu

[ChristianEhrhardt]

** Also affects: open-vm-tools (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: open-vm-tools (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: open-vm-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: open-vm-tools (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: open-vm-tools (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: open-vm-tools (Ubuntu Artful)
   Status: New => In Progress

** Changed in: open-vm-tools (Ubuntu Trusty)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Changed in: open-vm-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Changed in: open-vm-tools (Ubuntu Artful)
 Assignee: (unassigned) => Dariusz Gadomski (dgadomski)

** Description changed:

  [Impact]
  
-  * The default tools.conf template shipped with the Ubuntu package is
+  * The default tools.conf template shipped with the Ubuntu package is
  useless - it gets cleared on the first run as it contains an
  unrecognized content.
  
  [Test Case]
  
-  * Install open-vm-tools.
-  * Check contents of /etc/vmware-tools/tools.conf.
-  * Start vmtoolsd service e.g. by systemctl start open-vm-tools.
-  * Check tools.conf contents again.
+  * Install open-vm-tools.
+  * Check contents of /etc/vmware-tools/tools.conf.
+  * Start vmtoolsd service e.g. by systemctl start open-vm-tools.
+  * Check tools.conf contents again.
  
  Expected result:
  Config is read an left untouched.
  
  Actual result:
  Config file is cleared.
  
  [Regression Potential]
  
-  * If any of the parameters in the template is set to a non-default value
+  * If any of the parameters in the template is set to a non-default value
  the behaviour of vmtoolsd may change slightly (e.g. different log verbosity, 
log target - file vs. syslog).
+But people will get the usual conffile changed prompts, so those who 
modified it will have to consciously decide which makes it safe.
  
  [Other Info]
-  
-  * Original bug description:
+ 
+  * Original bug description:
  
  The tools.conf template shipped with Ubuntu (debian/local/tools.conf) is
  incorrect.
  
  It's current contents:
  bindir = "/usr/bin"
  do not mean anything to open-vm-tools - it's not interpreted in any way by 
vmtoolsd.
  
  Moreover, on the first launch this content is cleared by a piece of code
  doing a "config upgrade".
  
  I believe replacing it with a more meaningful content is necessary.

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1748122

Title:
  incorrect tools.conf template is shipped with Ubuntu

Status in VMWare tools:
  New
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Trusty:
  In Progress
Status in open-vm-tools source package in Xenial:
  In Progress
Status in open-vm-tools source package in Artful:
  In Progress

Bug description:
  [Impact]

   * The default tools.conf template shipped with the Ubuntu package is
  useless - it gets cleared on the first run as it contains an
  unrecognized content.

  [Test Case]

   * Install open-vm-tools.
   * Check contents of /etc/vmware-tools/tools.conf.
   * Start vmtoolsd service e.g. by systemctl start open-vm-tools.
   * Check tools.conf contents again.

  Expected result:
  Config is read an left untouched.

  Actual result:
  Config file is cleared.

  [Regression Potential]

   * If any of the parameters in the template is set to a non-default value
  the behaviour of vmtoolsd may change slightly (e.g. different log verbosity, 
log target - file vs. syslog).
 But people will get the usual conffile changed prompts, so those who 
modified it will have to consciously decide which makes it safe.

  [Other Info]

   * Original bug description:

  The tools.conf template shipped with Ubuntu (debian/local/tools.conf)
  is incorrect.

  It's current contents:
  bindir = "/usr/bin"
  do not mean anything to open-vm-tools - it's not interpreted in any way by 
vmtoolsd.

  Moreover, on the first launch this content is cleared by a piece of
  code doing a "config upgrade".

  I believe replacing it with a more meaningful content is necessary.

To manage notifications about this bug go to:
https://bugs.launchpad.net/open-vm-tools/+bug/1748122/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1670408] Re: apparmor base abstraction needs backport of rev 3658 to fix several denies (tor, ntp, ...)

[ChristianEhrhardt]

** Changed in: apparmor (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: tor (Ubuntu)
   Status: Invalid => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1670408

Title:
  apparmor base abstraction needs backport of rev 3658 to fix several
  denies (tor, ntp, ...)

Status in apparmor package in Ubuntu:
  Fix Released
Status in ntp package in Ubuntu:
  Confirmed
Status in tor package in Ubuntu:
  Confirmed
Status in apparmor source package in Xenial:
  Triaged

Bug description:
  Using tor 0.2.9.9-1ubuntu1 with Linux 4.10.0-9-generic on Zesty, tor
  fails to start after installing the tor package. "systemctl status
  tor@default" reports:

  Mar 06 16:04:00 zesty systemd[1]: tor@default.service: Main process exited, 
code=killed, status=11/SEGV
  Mar 06 16:04:00 zesty systemd[1]: Failed to start Anonymizing overlay network 
for TCP.
  Mar 06 16:04:00 zesty systemd[1]: tor@default.service: Unit entered failed 
state.
  Mar 06 16:04:00 zesty systemd[1]: tor@default.service: Failed with result 
'signal'.

  There are two AppArmor denials in the kernel log:

  Mar  6 15:53:12 zesty-test kernel: [  102.699647] audit: type=1400
  audit(1488815592.268:35): apparmor="DENIED" operation="file_inherit"
  namespace="root//lxd-zesty_" profile="system_tor"
  name="/run/systemd/journal/stdout" pid=3520 comm="tor"
  requested_mask="wr" denied_mask="wr" fsuid=10 ouid=10

  Mar  6 15:53:12 zesty-test kernel: [  102.702418] audit: type=1400
  audit(1488815592.272:37): apparmor="DENIED" operation="file_mmap"
  namespace="root//lxd-zesty_" profile="system_tor"
  name="/usr/bin/tor" pid=3520 comm="tor" requested_mask="m"
  denied_mask="m" fsuid=10 ouid=10

  Workaround: add the following two lines to /etc/apparmor.d/system_tor:

  /usr/bin/tor m,
  /run/systemd/journal/stdout rw,

  I couldn't remember how to that that profile reloaded, so I rebooted,
  and after the reboot tor does start up successfully. "systemctl
  tor@default" reports it as running.

  I haven't checked to see if only one or other rule is actually
  required.

  Importance -> High since this bug makes the package unusable in its
  default configuration on Zesty. Since the AppArmor profile comes from
  Debian's 0.2.9.9-1, this should probably be fixed in Debian.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1670408/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1741227] Re: apparmor denial to several paths to binaries

[ChristianEhrhardt]

Bionic - ok
SRU Template - ok
Debdiff for X/T checked - ok
Tested A upload from ppa - ok.
(This issue in particular doesn't apply to Xenial, so dropping this task)

** No longer affects: ntp (Ubuntu Xenial)

** Changed in: ntp (Ubuntu Artful)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1741227

Title:
  apparmor denial to several paths to binaries

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Artful:
  Fix Committed

Bug description:
  [Impact]

   * Apparmor denies access to bin directories which the option parsing code 
 of ntp touches.

  [Test Case]

   1. get a container of target release
   2. install ntp
  apt install ntp
   3. watch dmesg on container-host
  dmesg -w
   4. restart ntp in container
  systemctl restart ntp
   => see (or no more after fix) apparmor denie:
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/sbin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r"
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/bin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r"

  [Regression Potential]

   * we are only slightly opening up the apparmor profile, but none of the
 changes poses a security risk so regression potential on it's own
 should be close to zero.

   * we discussed if this would be a security risk but came to the 
 conclusion that r-only should be ok (the same content anyone can grab 
 from the archive by installing the packages)

  [Other Info]

   * n/a

  Issue shows up (non fatal) as:
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/sbin/" pid=23933 comm="ntpd" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/bin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  Since non crit this is mostyl about many of us being curious why it
  actually does do it :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1741227/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1670408] Re: Missing apparmor rules cause tor to fail to start

[ChristianEhrhardt]

Correctly added a bug task for ntp to also be affected.
Dropping Artful (EOL)

** Also affects: ntp (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: apparmor (Ubuntu Yakkety)

** Changed in: apparmor (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: ntp (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1670408

Title:
  apparmor base abstraction needs backport of rev 3658 to fix several
  denies (tor, ntp, ...)

Status in apparmor package in Ubuntu:
  Fix Released
Status in ntp package in Ubuntu:
  Confirmed
Status in tor package in Ubuntu:
  Invalid
Status in apparmor source package in Xenial:
  Triaged

Bug description:
  Using tor 0.2.9.9-1ubuntu1 with Linux 4.10.0-9-generic on Zesty, tor
  fails to start after installing the tor package. "systemctl status
  tor@default" reports:

  Mar 06 16:04:00 zesty systemd[1]: tor@default.service: Main process exited, 
code=killed, status=11/SEGV
  Mar 06 16:04:00 zesty systemd[1]: Failed to start Anonymizing overlay network 
for TCP.
  Mar 06 16:04:00 zesty systemd[1]: tor@default.service: Unit entered failed 
state.
  Mar 06 16:04:00 zesty systemd[1]: tor@default.service: Failed with result 
'signal'.

  There are two AppArmor denials in the kernel log:

  Mar  6 15:53:12 zesty-test kernel: [  102.699647] audit: type=1400
  audit(1488815592.268:35): apparmor="DENIED" operation="file_inherit"
  namespace="root//lxd-zesty_" profile="system_tor"
  name="/run/systemd/journal/stdout" pid=3520 comm="tor"
  requested_mask="wr" denied_mask="wr" fsuid=10 ouid=10

  Mar  6 15:53:12 zesty-test kernel: [  102.702418] audit: type=1400
  audit(1488815592.272:37): apparmor="DENIED" operation="file_mmap"
  namespace="root//lxd-zesty_" profile="system_tor"
  name="/usr/bin/tor" pid=3520 comm="tor" requested_mask="m"
  denied_mask="m" fsuid=10 ouid=10

  Workaround: add the following two lines to /etc/apparmor.d/system_tor:

  /usr/bin/tor m,
  /run/systemd/journal/stdout rw,

  I couldn't remember how to that that profile reloaded, so I rebooted,
  and after the reboot tor does start up successfully. "systemctl
  tor@default" reports it as running.

  I haven't checked to see if only one or other rule is actually
  required.

  Importance -> High since this bug makes the package unusable in its
  default configuration on Zesty. Since the AppArmor profile comes from
  Debian's 0.2.9.9-1, this should probably be fixed in Debian.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1670408/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1748161] Re: improve britney hints for postgres MREs

[ChristianEhrhardt]

** Package changed: postgresql-9.5 (Ubuntu) => postgresql-common
(Ubuntu)

** Also affects: postgresql-common (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: postgresql-common (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: postgresql-common (Ubuntu)
   Status: New => Fix Released

** Changed in: postgresql-common (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: postgresql-common (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1748161

Title:
  improve britney hints for postgres MREs

Status in britney:
  New
Status in postgresql-common package in Ubuntu:
  Fix Released
Status in postgresql-common source package in Trusty:
  Triaged
Status in postgresql-common source package in Xenial:
  Triaged

Bug description:
  On every postgres MRE we mention some regular failing tests.
  Those were mostly caused by changes in the environment and fixes were done 
for later Ubuntu releases but not SRUable.
  We should not ask the release team to force them on every SRU but cover those 
where it is correct with badtest entries.

  So this is about collecting this information and adapting hints for
  britney accordingly.

  Due to changes from lxc -> lxd (documented by pitti and carried on since then)
  - trusty
- postgresql-9.3/armhf
  - Xenial
- postgresql-9.5/armhf
- mimeo/armhf

  FYI - there are also some long term always fail cases.
  Often had just 1-2 good runs on old pgsql versions and hen never again - 
resolved in latter releases. Those packages are in universe only and are 
already covered by hints.
  - Xenial
- pgfincore, see [1]
- orafce, see [2]
- postgresql-plproxy, see [3]
- pgpool2, since pgpool2/3.4.3-1 see [4] as an example

  Some others are known flaky tests are there as well, but I don't want to 
overrid all those to keep their coverage.
  E.g. dbconfig-common failed on artful due to mysql (but one can see in the 
log postgres is good which for this update is the important part).

  But for those above that are due to the LXC/LXD change there is no reason to 
bump it on every MRE.
  It won't change - so lets propose them unversioned to not need this over and 
over again.

  [1]: http://autopkgtest.ubuntu.com/packages/pgfincore/xenial/amd64
  [2]: http://autopkgtest.ubuntu.com/packages/orafce/xenial/amd64
  [3]: http://autopkgtest.ubuntu.com/packages/postgresql-plproxy/xenial/amd64
  [4]: http://autopkgtest.ubuntu.com/packages/pgpool2/xenial/amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/britney/+bug/1748161/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1749389] Re: ntpdate lock apparmor deny

[ChristianEhrhardt]

Missed the right format in changelog :-/, but this is fixed in Bionic by
https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p10+dfsg-5ubuntu7

** Changed in: ntp (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1749389

Title:
  ntpdate lock apparmor deny

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Artful:
  Triaged

Bug description:
  [Impact]

   * Apparmor denies access to lock it shares with ntpdate to ensure no 
 issues due to concurrent access

  [Test Case]

   1. get a container of target release
   2. install ntp
  apt install ntp
   3. watch dmesg on container-host
  dmesg -w 
   4. restart ntp in container
  systemctl restart ntp
   => see (or no more after fix) apparmor denie:
  apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"

  [Regression Potential]

   * we are only slightly opening up the apparmor profile, but none of the 
 changes poses a security risk so regression potential on it's own 
 should be close to zero.

   * There is a potential issue if the locking (that now can succeed) would 
 e.g. no more be freed up or the action behind the locking would cause 
 issues.

  [Other Info]
   
   * n/a

  
  On start/restart nto has an error in apparmor due to the locking it tries to 
avoid issues running concurrently with ntpdate.

  That looks like:
  apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/ntpd" 
name="/run/lock/ntpdate" pid=30113 comm="ntpd" requested_mask="w" 
denied_mask="w"

  The rule we need is:
  /run/lock/ntpdate wk,

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1749389/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1741227] Re: apparmor denial to several paths to binaries

[ChristianEhrhardt]

Hi Tony,
yeah this is so far only fixed in Bionic (18.04) onwards.
It it not really an issue other than a log message itself (it is not needed for 
the opt parsing).
It occurs "only" on NTP start/restart (since it is arg parsing) so it is not 
that frequent that it would fill up the log or similar secondary issues.

All that makes it a hard case for the SRU policy [1] to make this change in 
releases.
Until then everybody who bothers about the log message can add:
   /usr/local/{,s}bin/  r,
to
   /etc/apparmor.d/usr.sbin.ntpd

I'm adding X/A bug tasks and set won't fix to mark that more explicitly.

I'm happy to discuss if one thinks this case would qualify fot the SRU
policy - the change itself is easy enough to be done.

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

** Also affects: ntp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ntp (Ubuntu Artful)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1741227

Title:
  apparmor denial to several paths to binaries

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Triaged
Status in ntp source package in Artful:
  Triaged

Bug description:
  [Impact]

   * Apparmor denies access to bin directories which the option parsing code 
 of ntp touches.

  [Test Case]

   1. get a container of target release
   2. install ntp
  apt install ntp
   3. watch dmesg on container-host
  dmesg -w
   4. restart ntp in container
  systemctl restart ntp
   => see (or no more after fix) apparmor denie:
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/sbin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r"
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/bin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r"

  [Regression Potential]

   * we are only slightly opening up the apparmor profile, but none of the
 changes poses a security risk so regression potential on it's own
 should be close to zero.

   * we discussed if this would be a security risk but came to the 
 conclusion that r-only should be ok (the same content anyone can grab 
 from the archive by installing the packages)

  [Other Info]

   * n/a

  Issue shows up (non fatal) as:
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/sbin/" pid=23933 comm="ntpd" requested_mask="r" 
denied_mask="r" fsuid=0 ouid=0
   apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" 
name="/usr/local/bin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  Since non crit this is mostyl about many of us being curious why it
  actually does do it :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1741227/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1746630] Re: virsh api is stuck when vm is down with NFS borken

[ChristianEhrhardt]

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: New => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746630

Title:
  virsh api is stuck when vm is down with NFS borken

Status in Ubuntu Cloud Archive:
  New
Status in libvirt:
  Fix Released
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Triaged

Bug description:
  [Impact]

  virsh command is hang if there is broken VM on broken NFS

  This is affected to Xenial, UCA-Mitaka

  [Test Case]

  1. deploy VM with NFS storage ( running )
  2. block NFS via iptables
  - iptables -A OUTPUT -d NFS_SERVER_IP -p tcp --dport 2049 -j DROP ( on host 
machine )
  3. virsh blkdeviotune generic hda => hang
  4. virsh domstats => hang
  5. virsh list => lang

  [Regression]
  After patch, we can command domstats and list with short timeout. and 
libvirt-bin needs to be restarted. so if there are many VMs it will be affected 
short time while it is restarting.

  [Others]

  This bug is fixed in redhat bug report[1] and mailing list[2] and git
  commit[3][4][5]

  and it is merged 1.3.5 upstream

  
https://libvirt.org/git/?p=libvirt.git;a=blobdiff;f=docs/news.html.in;h=1ad8337f5f8443b5ac76450dc3370f95c51503fd;hp=d035f6833fb5eaaced8f5a7010872f3e61b6955b;hb=732bc70dcc3e2d1fe0baa640712efb99e273;hpb=d57e73d06fe5901ac4ab9c025b3531251292b509

  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1337073
  [2] https://www.redhat.com/archives/libvir-list/2016-May/msg01353.html
  [3] 
https://libvirt.org/git/?p=libvirt.git;a=commit;h=5d2b0e6f12b4e57d75ed1047ab1c36443b7a54b3
  [4] 
https://libvirt.org/git/?p=libvirt.git;a=commit;h=3aa5d51a9530a8737ca584b393c29297dd9bbc37
  [5] 
https://libvirt.org/git/?p=libvirt.git;a=commit;h=71d2c172edb997bae1e883b2e1bafa97d9f953a1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1746630/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1746081] Re: Daemon flags aren't supported ? or unclear how.

[ChristianEhrhardt]

** Bug watch added: Debian Bug tracker #889012
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889012

** Also affects: chrony (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889012
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746081

Title:
  Daemon flags aren't supported ? or unclear how.

Status in chrony package in Ubuntu:
  In Progress
Status in chrony source package in Xenial:
  Triaged
Status in chrony package in Debian:
  Unknown

Bug description:
  Using:

  Ubuntu 16.04.3 LTS
  Chrony package 2.1.1-1

  I wanted to limit a chrony install to be IPV4 only (-4 flag), but from
  the looks of /etc/init.d/chrony and /etc/defaults there doesn't appear
  to be a clean way to do so.

  /etc/init.d/chrony has FLAGS="defaults" set, but the variable never
  appears to be used.  There is also no reference to bring in anything
  from /etc/default/chrony (which doesn't exist either).

  Perhaps I'm overlooking something.  Is there any way to cleanly add a
  startup flag to the service?

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1746081/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1746081] Re: Daemon flags aren't supported ? or unclear how.

[ChristianEhrhardt]

there is /etc/defaults/chrony in later versions of it.
But even that is no more working since the native systemd service does not 
consider it.

I might take a look into this for 18.04 to be correct, but atm I have no plan 
to do so for 16.04.
You might take a look at later Ubuntu releases and take the adapted init.d 
script and /etc/default/chrony to adapt your system as needed.

I guess we are even up for volunteers to do so for 16.04 - it just is
not on my personal tsak list.

** Also affects: chrony (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: chrony (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: chrony (Ubuntu Xenial)
   Importance: Undecided => Wishlist

** Changed in: chrony (Ubuntu)
   Status: New => Triaged

** Changed in: chrony (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1746081

Title:
  Daemon flags aren't supported ? or unclear how.

Status in chrony package in Ubuntu:
  Triaged
Status in chrony source package in Xenial:
  Triaged

Bug description:
  Using:

  Ubuntu 16.04.3 LTS
  Chrony package 2.1.1-1

  I wanted to limit a chrony install to be IPV4 only (-4 flag), but from
  the looks of /etc/init.d/chrony and /etc/defaults there doesn't appear
  to be a clean way to do so.

  /etc/init.d/chrony has FLAGS="defaults" set, but the variable never
  appears to be used.  There is also no reference to bring in anything
  from /etc/default/chrony (which doesn't exist either).

  Perhaps I'm overlooking something.  Is there any way to cleanly add a
  startup flag to the service?

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1746081/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1532608] Re: Files moved around in clamav without appropriate Breaks/Replaces, causing upgrade failures

[ChristianEhrhardt]

Since all upgrades will go through LTS->LTS paths at least that should be good 
now in general.
I don't see a need to fix other ubuntu releases (I might miss some).

So instead of "In Progress → New" I'll set Fix Released.

@Andreas - if I miss why this needs a change in other versions please
explain why.

** Changed in: clamav (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1532608

Title:
  Files moved around in clamav without appropriate Breaks/Replaces,
  causing upgrade failures

Status in clamav package in Ubuntu:
  Fix Released
Status in clamav source package in Xenial:
  Fix Released

Bug description:
  
  [Impact] 

   * Upgrades can fail due to file collisions since SRUs that bumped the 
 version in trusty. Due to that the formerly breaks/replaces no more 
 applies correctly.

  [Test Case]

   * The following upgrade paths leads to an error without the fix (ok to be 
 run in a container)
 # install trusty
 $ apt install clamav-daemon
 # upgrade to Xenial repo
 $ apt update && apt upgrade

  [Regression Potential]

   * Since we "just" bump the breaks/replaces this should be fairly safe.
 The only case that comes to my mind is when old custom versions with 
 odd versions were installed, but even then it either does just trigger 
 the same issues. OTOH most likely even in that rare (and unsupported 
 case) they should be fine.

  [Other Info]
   
   * n/a


  ---

  This bug appeared updating from Ubuntu 14.04 to Ubuntu 15.04

  ProblemType: Package
  DistroRelease: Ubuntu 15.04
  Package: clamav-daemon 0.98.7+dfsg-0ubuntu0.15.04.1
  ProcVersionSignature: Ubuntu 3.19.0-43.49-generic 3.19.8-ckt10
  Uname: Linux 3.19.0-43-generic x86_64
  ApportVersion: 2.17.2-0ubuntu1.8
  Architecture: amd64
  Date: Sun Jan 10 21:18:16 2016
  DuplicateSignature: 
package:clamav-daemon:0.98.7+dfsg-0ubuntu0.15.04.1:intentando sobreescribir 
`/usr/share/man/man5/clamd.conf.5.gz', que está también en el paquete 
clamav-base 0.98.7+dfsg-0ubuntu0.14.04.1
  ErrorMessage: intentando sobreescribir `/usr/share/man/man5/clamd.conf.5.gz', 
que está también en el paquete clamav-base 0.98.7+dfsg-0ubuntu0.14.04.1
  InstallationDate: Installed on 2015-07-25 (168 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-3.19.0-43-generic 
root=UUID=b406f381-7240-484e-88db-5b321e59568d ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   dpkg 1.17.25ubuntu1.1
   apt  1.0.9.7ubuntu4.2
  SourcePackage: clamav
  Title: package clamav-daemon 0.98.7+dfsg-0ubuntu0.15.04.1 failed to 
install/upgrade: intentando sobreescribir 
`/usr/share/man/man5/clamd.conf.5.gz', que está también en el paquete 
clamav-base 0.98.7+dfsg-0ubuntu0.14.04.1
  UpgradeStatus: Upgraded to vivid on 2016-01-10 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1532608/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1717224] Re: virsh start of virtual guest domain fails with internal error due to low default aio-max-nr sysctl value

[ChristianEhrhardt]

Hi Heinz-Werner,
thanks for the ping.

I think we agreed back then that the config itself is a Ubuntu wide
thing - but I haven't seen any discussions on procps or in general to
lift it. But then as I outlined in comment #7 any limit can be too low.
I'll set the KVM task to won't fix to clearly mark it as "not a kvm
task".

The fix that you need thou is the kernel change to account correctly - so that 
part of the question goes to the Kernel Team if the change that was proposed 
back then was actually released.
@Joseph - we clearly passed the number, but was the change released with it?


** Changed in: kvm (Ubuntu)
   Status: Confirmed => Won't Fix

** No longer affects: kvm (Ubuntu Xenial)

** No longer affects: kvm (Ubuntu Zesty)

** No longer affects: kvm (Ubuntu Artful)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1717224

Title:
  virsh start of virtual guest domain fails with internal error due to
  low default aio-max-nr sysctl value

Status in Ubuntu on IBM z Systems:
  In Progress
Status in kvm package in Ubuntu:
  Won't Fix
Status in linux package in Ubuntu:
  In Progress
Status in procps package in Ubuntu:
  New
Status in linux source package in Xenial:
  In Progress
Status in procps source package in Xenial:
  New
Status in linux source package in Zesty:
  In Progress
Status in procps source package in Zesty:
  New
Status in linux source package in Artful:
  In Progress
Status in procps source package in Artful:
  New

Bug description:
  Starting virtual guests via on Ubuntu 16.04.2 LTS installed with its
  KVM hypervisor on an IBM Z14 system LPAR fails on the 18th guest with
  the following error:

  root@zm93k8:/rawimages/ubu1604qcow2# virsh start zs93kag70038
  error: Failed to start domain zs93kag70038
  error: internal error: process exited while connecting to monitor: 
2017-07-26T01:48:26.352534Z qemu-kvm: -drive 
file=/guestimages/data1/zs93kag70038.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none,aio=native:
 Could not open backing file: Could not set AIO state: Inappropriate ioctl for 
device

  The previous 17 guests started fine:

  root@zm93k8# virsh start zs93kag70020
  Domain zs93kag70020 started

  root@zm93k8# virsh start zs93kag70021
  Domain zs93kag70021 started

  .
  .

  root@zm93k8:/rawimages/ubu1604qcow2# virsh start zs93kag70036
  Domain zs93kag70036 started

  
  We ended up fixing the issue by adding the following line to /etc/sysctl.conf 
: 

  fs.aio-max-nr = 4194304

  ... then, reload the sysctl config file:

  root@zm93k8:/etc# sysctl -p /etc/sysctl.conf
  fs.aio-max-nr = 4194304

  
  Now, we're able to start more guests...

  root@zm93k8:/etc# virsh start zs93kag70036
  Domain zs93kag70036 started

  
  The default value was originally set to 65535: 

  root@zm93k8:/rawimages/ubu1604qcow2# cat /proc/sys/fs/aio-max-nr
  65536

  
  Note, we chose the 4194304 value, because this is what our KVM on System Z 
hypervisor ships as its default value.  Eg.  on our zKVM system: 

  [root@zs93ka ~]# cat /proc/sys/fs/aio-max-nr
  4194304

  ubuntu@zm93k8:/etc$ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 16.04.2 LTS
  Release:16.04
  Codename:   xenial
  ubuntu@zm93k8:/etc$

  ubuntu@zm93k8:/etc$ dpkg -s qemu-kvm |grep Version
  Version: 1:2.5+dfsg-5ubuntu10.8

  Is something already documented for Ubuntu KVM users warning them about the 
low default value, and some guidance as to
  how to select an appropriate value?   Also, would you consider increasing the 
default aio-max-nr value to something much
  higher, to accommodate significantly more virtual guests?  

  Thanks!

  ---uname output---
  ubuntu@zm93k8:/etc$ uname -a Linux zm93k8 4.4.0-62-generic #83-Ubuntu SMP Wed 
Jan 18 14:12:54 UTC 2017 s390x s390x s390x GNU/Linux
   
  Machine Type = z14 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   See Problem Description.

  The problem was happening a week ago, so this may not reflect that
  activity.

  This file was collected on Aug 7, one week after we were hitting the
  problem.  If I need to reproduce the problem and get fresh data,
  please let me know.

  /var/log/messages doesn't exist on this system, so I provided syslog
  output instead.

  All data have been collected too late after the problem was observed
  over a week ago.  If you need me to reproduce the problem and get new
  data, please let me know.  That's not a problem.

  Also, we would have to make special arrangements for login access to
  these systems.  I'm happy to run traces and data collection for you as
  needed.  If that's not sufficient, then we'll explore log in access
  for you.

  Thanks...   - Scott G.

  
  I was able to successfully recreate the problem and captured / attached new 
debug docs. 

  Recreate procedu

[Group.of.nepali.translators] [Bug 1712803] Re: spapr_hcall from ubuntu_kvm_unit_test failed on ppc64el with Z-hwe kernel

[ChristianEhrhardt]

Thanks for identifying the changes, both changes are in since 2.6 so I'm
first marking the bug tasks accordingly.

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: qemu (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1712803

Title:
  spapr_hcall from ubuntu_kvm_unit_test failed on ppc64el with Z-hwe
  kernel

Status in linux package in Ubuntu:
  Triaged
Status in qemu package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  New
Status in qemu source package in Xenial:
  Triaged

Bug description:
  kernel: 4.10.0-33.37~16.04.1

  I think this issue was introduced by the old qemu version (similar
  issue was spotted on Xenial before), will need to investigate this
  further.

  
  qemu-system-ppc64 -machine pseries,accel=kvm -bios powerpc/boot_rom.bin 
-display none -serial stdio -kernel powerpc/spapr_hcall.elf -smp 1
  FAIL: hypercall: h_set_sprg0: sprg0 = 0xcafebabedeadbeef
  FAIL: hypercall: h_set_sprg0: sprg0 = 0x
  FAIL: hypercall: h_set_sprg0: sprg0 = 0x41a588
  FAIL: hypercall: h_page_init: h_zero_page
  FAIL: hypercall: h_page_init: h_copy_page
  FAIL: hypercall: h_page_init: h_copy_page+h_zero_page
  FAIL: hypercall: h_page_init: h_zero_page unaligned dst
  FAIL: hypercall: h_page_init: h_copy_page unaligned src
  XFAIL: hypercall: h_random: h-call available

  SUMMARY: 9 tests, 8 unexpected failures, 1 expected failures

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1712803/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1726879] Re: Unescaped left brace in regex is deprecated

[ChristianEhrhardt]

This actually doesn't affect T/X as the pearl there is older and does not 
complain.
Thanks Ahasenack for spotting this before I started to build all the test ppa's!

** Changed in: spamassassin (Ubuntu Xenial)
   Status: Triaged => Invalid

** Changed in: spamassassin (Ubuntu Trusty)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1726879

Title:
  Unescaped left brace in regex is deprecated

Status in spamassassin package in Ubuntu:
  Fix Released
Status in spamassassin source package in Trusty:
  Invalid
Status in spamassassin source package in Xenial:
  Invalid
Status in spamassassin source package in Artful:
  Triaged
Status in spamassassin package in Debian:
  Fix Released

Bug description:
  When using sa-learn, you receive this notification:

  Unescaped left brace in regex is deprecated here (and will be fatal in
  Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.{ <--
  HERE ,200}).*$/ at /usr/share/perl5/Mail/SpamAssassin/PerMsgStatus.pm
  line 923.


  Bug similar to: 
  https://bugs.archlinux.org/task/54378

  Upstream patch to fix the issue:
  
https://github.com/apache/spamassassin/commit/edb00a8d76a625bf03227ee2f6e915c9a0d90bad.patch

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: spamassassin 3.4.1-7
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia wl
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Oct 24 16:03:14 2017
  InstallationDate: Installed on 2012-03-01 (2062 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
  PackageArchitecture: all
  SourcePackage: spamassassin
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.spamassassin.init.pre: [modified]
  modified.conffile..etc.spamassassin.v310.pre: [modified]
  modified.conffile..etc.spamassassin.v312.pre: [modified]
  modified.conffile..etc.spamassassin.v330.pre: [modified]
  modified.conffile..etc.spamassassin.v340.pre: [modified]
  modified.conffile..etc.spamassassin.v341.pre: [modified]
  mtime.conffile..etc.default.spamassassin: 2017-08-07T14:05:53.351115
  mtime.conffile..etc.spamassassin.init.pre: 2012-03-03T17:13:34.827338
  mtime.conffile..etc.spamassassin.v310.pre: 2012-03-03T17:16:33.359340
  mtime.conffile..etc.spamassassin.v312.pre: 2012-03-03T17:17:26.667341
  mtime.conffile..etc.spamassassin.v330.pre: 2012-03-03T17:17:53.215342
  mtime.conffile..etc.spamassassin.v340.pre: 2014-07-10T16:07:25.307684
  mtime.conffile..etc.spamassassin.v341.pre: 2016-11-12T12:43:21.082704

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1726879/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1726879] Re: Unescaped left brace in regex is deprecated

[ChristianEhrhardt]

** Changed in: spamassassin (Ubuntu Trusty)
   Status: Confirmed => Triaged

** Changed in: spamassassin (Ubuntu Xenial)
   Status: Confirmed => Triaged

** Changed in: spamassassin (Ubuntu Zesty)
   Status: Confirmed => Triaged

** Changed in: spamassassin (Ubuntu Artful)
   Status: Confirmed => Triaged

** No longer affects: spamassassin (Ubuntu Zesty)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1726879

Title:
  Unescaped left brace in regex is deprecated

Status in spamassassin package in Ubuntu:
  Fix Released
Status in spamassassin source package in Trusty:
  Triaged
Status in spamassassin source package in Xenial:
  Triaged
Status in spamassassin source package in Artful:
  Triaged
Status in spamassassin package in Debian:
  Fix Released

Bug description:
  When using sa-learn, you receive this notification:

  Unescaped left brace in regex is deprecated here (and will be fatal in
  Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.{ <--
  HERE ,200}).*$/ at /usr/share/perl5/Mail/SpamAssassin/PerMsgStatus.pm
  line 923.


  Bug similar to: 
  https://bugs.archlinux.org/task/54378

  Upstream patch to fix the issue:
  
https://github.com/apache/spamassassin/commit/edb00a8d76a625bf03227ee2f6e915c9a0d90bad.patch

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: spamassassin 3.4.1-7
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia wl
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Oct 24 16:03:14 2017
  InstallationDate: Installed on 2012-03-01 (2062 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111011)
  PackageArchitecture: all
  SourcePackage: spamassassin
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.spamassassin.init.pre: [modified]
  modified.conffile..etc.spamassassin.v310.pre: [modified]
  modified.conffile..etc.spamassassin.v312.pre: [modified]
  modified.conffile..etc.spamassassin.v330.pre: [modified]
  modified.conffile..etc.spamassassin.v340.pre: [modified]
  modified.conffile..etc.spamassassin.v341.pre: [modified]
  mtime.conffile..etc.default.spamassassin: 2017-08-07T14:05:53.351115
  mtime.conffile..etc.spamassassin.init.pre: 2012-03-03T17:13:34.827338
  mtime.conffile..etc.spamassassin.v310.pre: 2012-03-03T17:16:33.359340
  mtime.conffile..etc.spamassassin.v312.pre: 2012-03-03T17:17:26.667341
  mtime.conffile..etc.spamassassin.v330.pre: 2012-03-03T17:17:53.215342
  mtime.conffile..etc.spamassassin.v340.pre: 2014-07-10T16:07:25.307684
  mtime.conffile..etc.spamassassin.v341.pre: 2016-11-12T12:43:21.082704

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/spamassassin/+bug/1726879/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1630025] Re: Fails running In chroot with "ENGINE_by_id failed (crypto failure)"

[ChristianEhrhardt]

Hi Brian,
these versions are actually already in Artful and Bionic.
Given the time you opened this you found that on Xenial I'll add a task for an 
SRU.

@Andreas - you look at bind fixes every now and then - how about to
include this on your next run?

** Also affects: bind9 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: bind9 (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: bind9 (Ubuntu Xenial)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1630025

Title:
  Fails running In chroot with "ENGINE_by_id failed (crypto failure)"

Status in BIND:
  New
Status in bind9 package in Ubuntu:
  Fix Released
Status in bind9 source package in Xenial:
  Triaged
Status in bind9 package in Debian:
  Fix Released

Bug description:
  Running inside an OpenVZ guest, it is not possible to use the AppArmor
  as discussed, so I am trying to configure BIND9 to run in chroot.

  Then I got the following in the log:

  named[3398]: ENGINE_by_id failed (crypto failure)
  named[3398]: error:25070067:DSO support routines:DSO_load:could not load the 
shared library:dso_lib.c:233:
  named[3398]: error:260B6084:engine routines:DYNAMIC_LOAD:dso not 
found:eng_dyn.c:467:
  named[3398]: error:2606A074:engine routines:ENGINE_by_id:no such 
engine:eng_list.c:390:id=gost
  named[3398]: initializing DST: crypto failure
  named[3398]: exiting (due to fatal error)
  systemd[1]: bind9.service: Main process exited, code=exited, status=1/FAILURE

  This seems to be a bug that is found in Debian https://bugs.debian.org
  /cgi-bin/bugreport.cgi?bug=820974

To manage notifications about this bug go to:
https://bugs.launchpad.net/bind/+bug/1630025/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1727699] Re: SSL issue upgrading postfix

[ChristianEhrhardt]

I think I found it, the check to:
  if `dpkg --compare-versions "$2" lt 3.1.0-1~`; then
has no else clause that we could hit.

But by checking more in Detail I realized that this version check is not in all 
releases.
It was added in 3.1.3-1 and thereby is in all releases.
It is in Zesty and later but missing in Xenial and that is what hits you.

So this comes down to essentially https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=833103

** Bug watch added: Debian Bug tracker #833103
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833103

** Also affects: postfix (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: postfix (Ubuntu)
   Status: New => Fix Released

** Also affects: postfix (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833103
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1727699

Title:
  SSL issue upgrading postfix

Status in postfix package in Ubuntu:
  Fix Released
Status in postfix source package in Xenial:
  New
Status in postfix package in Debian:
  Unknown

Bug description:
  issue upgrading posfix on Ubuntu 16.04.3 LTS

  in file master.cf, line submission=

  the upgrade procedure has changed the field chroot to 'y', but it was
  '-'. 'y' is wrong

  #pre upgrade it was 
  submission inet  n   -   -   -   -   smtpd

  #then it become 
  submission inet  n   -   y   -   -   smtpd

  
  the 'y' is wrong

  
  http://www.postfix.org/master.5.html 

  sais "Chroot (default: Postfix >= 3.0: n, Postfix <3.0: y)"
   
  with 'y' the server rejects all SSL smtp mails

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1727699/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1727202] Re: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path

[ChristianEhrhardt]

While I see the non-crit "other" issue with opening its own binary I can
not confirm the disconnected path issue in a current xenial guest.

Since we knew this appears when trigging the running service to emit an error 
message I tried to force such an error message. I knew on later releases I 
could do so by e.g. spawning another virtual interface to bind on by starting a 
KVM guest (ntp would try to bind on that but fails).
On Xenial I see the error messages without any apparmor related issue.

While I don't know what is different on bug 1475019 (maybe ntp was
manually namespaced on that setup) this bug here "as reported" is a
regression in 17.10.

** Changed in: ntp (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: ntp (Ubuntu Zesty)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1727202

Title:
  [17.10 regression] AppArmor ntp denial: Failed name lookup -
  disconnected path

Status in ntp package in Ubuntu:
  Fix Released
Status in ntp source package in Xenial:
  Invalid
Status in ntp source package in Zesty:
  Invalid
Status in ntp source package in Artful:
  Fix Committed
Status in ntp source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * NTP has new isolation features which makes it trigger apparmor issues.
   * Those apparmor issues not only clutter the log and make other things
     less readable, they also prevent ntp from reporting its actual
     messages.
   * Fix is opening the apparmor profile to follow ntp through the
     disconnect by the isolation feature.

  [Test Case]

   * This is hard to trigger, but then also not. Which means it is not
     entirely sorted out when it triggers and when not, but the following
     does trigger it in tests of Pitti and also mine (while at the same time
     sometimes it does not - mabye I had other guests or kvm instead of lxd)

   * First install ntp in Artful (or above unless fixed)
     * Install ntp and check demsg for denies
     * Once an issue triggers instead of the error in syslog you'll see the
   apparmor Deny like:
     apparmor="DENIED" operation="sendmsg" info="Failed name lookup -
     disconnected path" error=-13 profile="/usr/sbin/ntpd"
     name="run/systemd/journal/dev-log" pid=5600 comm="ntpd"
     requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  [Regression Potential]

   * We are slightly opening up the apparmor profile which is far lower risk
     than adding more constraints. So safe from that POV.

   * OTOH one could think this might be a security issue, but in fact this
     isn't a new suggestion if you take a look at [1] with an ack by Seth of
     the Security Team.

  [Other Info]

   * n/a

  [1]: https://lists.ubuntu.com/archives/apparmor/2015-May/007858.html

  

  Merely installing and starting ntp.service in Ubuntu 17.10 now causes
  this AppArmor violation:

  audit: type=1400 audit(1508915894.215:25): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log"
  pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0

  (many times). This hasn't happened in earlier Ubuntu releases yet.

  This was spotted by Cockpit's integration tests, as our "ubuntu-
  stable" image now moved to 17.10 after its release.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: ntp 1:4.2.8p10+dfsg-5ubuntu3
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  Date: Wed Oct 25 03:19:34 2017
  SourcePackage: ntp
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1738864] Re: libvirt updates all iSCSI targets from host each time a pool is started

[ChristianEhrhardt]

You'd add [2] and always take packages from there non selectively.
So normal add-apt-repository and after that just update/upgrade as usual 
according to your maintenance policies.

I'd say that while libvirt/qemu can break things I'd have very rarely seen 
those to manifest as system instabilities - so I'd assume other changes would 
have caused this.
In general I'd recommend to do the change on a few systems only to begin with 
and see if they behave up to your expectation for a while.
Also maybe do not change the week before Christmas, but more in January :-)

On the SRU I think we agree that we will not change the version as in
Xenial for the reasons outlined before - thanks for your understanding.
I'm marking the bug task accordingly.

I'll stay subscribed here to help you with the general discussion.

** Changed in: libvirt (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1738864

Title:
  libvirt updates all iSCSI targets from host each time a pool is
  started

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Trusty:
  Won't Fix
Status in libvirt source package in Xenial:
  Won't Fix

Bug description:
  Hello everyone, I'm a little confused about the behavior of libvirt in
  Ubuntu 16.04.3.

  We have up to 140 iSCSI targets on a single storage host, and all of
  these are made available to our VM hosts. If I stop one of the iSCSI
  pools through virsh ("virsh pool-destroy iscsipool1") and start it
  back up again while running libvirt in debug, I see that it runs a
  discovery and proceeds to go through and update every single target
  available on that host -- even targets that we do not use, instead of
  simply connecting to that target.

  This turns a <1 second process into a minimum of 30 seconds, and I
  just ran it with the stopwatch and clocked it at 64 seconds. So if we
  are doing maintenance on these hosts and go for a reboot, it takes
  90-120+ minutes to finish auto starting all of the iSCSI pools. And of
  course, during this period of time, the server is completely worthless
  as a VM host. Libvirt is just stuck until it finishes connecting
  everything. Manually connecting to the targets using iscsiadm without
  doing all the same hubbub that libvirt is doing connects these targets
  immediately, as I would expect from libvirt.

  And for each of the 140 iSCSI targets, it goes through and runs an
  iscsiadm sendtargets and then updates every single target before
  finally connecting the respective pool.

  We also noticed that libvirt in Ubuntu 17.10 does not have this
  behavior. Well maybe it does, but it connects the iSCSI targets
  immediately. It is a much different process than Ubuntu 16.04.3.

  Any help would be greatly appreciated. Thank you so much.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1738864/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1738864] Re: libvirt updates all iSCSI targets from host each time a pool is started

[ChristianEhrhardt]

Hi Laz,
thank you for your report.

Thanks for the log, I mostly looked at the condensed version like:
$ awk '/iscsiadm/ {gsub("[0-9]*: debug : virCommandRunAsync:2429 :",""); 
gsub("+",""); gsub("^2017-12-18 ",""); print $0}' 20171218-libvirt.txt | 
pastebinit
=> http://paste.ubuntu.com/26214102/

The version in 17.10 is libvirt 3.6.
So something between 1.3.1 (Xenial) and 3.6 (Artful) must have fixed it 
upstream according to your report.

I think what you are seeing is the effect of [3] that is active and essentially 
iterates to set "node.startup=>manual" on all targets.
The fix for that came in 1.3.5 via [4] which makes use of iscsiadm option 
"nonpersistent" to get the same done in a better way.

That would mean for a fix in Xenial backporting [4], but I'm not sure if 
backporting those changes in newer libvirt would not impose too much general 
regression risk for an SRU [1].
I agree it is uncomfortably slow in your case, but the change is a rather big 
behavioral change (wanted in your case I totally agree), but I'm always afraid 
of [5] as I ran into issues almost like it.
And since it is "only slow" (I hate saying that being a performance engineer in 
the past) the severity isn't as high as if it is broken.

OTOH the code seems to apply and the option on iscsiadm is available
even in trusty (important for backports).

I wonder if instead of taking the risk of changing that in an SRU for
you the best option might be via [2] Ubuntu Cloud Archive which would
allow you to stick to 16.04 but at the same time get a supported newer
virtualization stack?

I'm tagging up the bug tasks accordingly and look forward to a
discussion about the best but also safe way for you and other Ubuntu
users overall.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates
[2]: https://wiki.ubuntu.com/OpenStack/CloudArchive
[3]: https://libvirt.org/git/?p=libvirt.git;a=commit;h=3c12b654
[4]: https://libvirt.org/git/?p=libvirt.git;a=commit;h=56057900
[5]: https://xkcd.com/1172/

** Also affects: libvirt (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Trusty)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: libvirt (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1738864

Title:
  libvirt updates all iSCSI targets from host each time a pool is
  started

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Trusty:
  Won't Fix
Status in libvirt source package in Xenial:
  Confirmed

Bug description:
  Hello everyone, I'm a little confused about the behavior of libvirt in
  Ubuntu 16.04.3.

  We have up to 140 iSCSI targets on a single storage host, and all of
  these are made available to our VM hosts. If I stop one of the iSCSI
  pools through virsh ("virsh pool-destroy iscsipool1") and start it
  back up again while running libvirt in debug, I see that it runs a
  discovery and proceeds to go through and update every single target
  available on that host -- even targets that we do not use, instead of
  simply connecting to that target.

  This turns a <1 second process into a minimum of 30 seconds, and I
  just ran it with the stopwatch and clocked it at 64 seconds. So if we
  are doing maintenance on these hosts and go for a reboot, it takes
  90-120+ minutes to finish auto starting all of the iSCSI pools. And of
  course, during this period of time, the server is completely worthless
  as a VM host. Libvirt is just stuck until it finishes connecting
  everything. Manually connecting to the targets using iscsiadm without
  doing all the same hubbub that libvirt is doing connects these targets
  immediately, as I would expect from libvirt.

  And for each of the 140 iSCSI targets, it goes through and runs an
  iscsiadm sendtargets and then updates every single target before
  finally connecting the respective pool.

  We also noticed that libvirt in Ubuntu 17.10 does not have this
  behavior. Well maybe it does, but it connects the iSCSI targets
  immediately. It is a much different process than Ubuntu 16.04.3.

  Any help would be greatly appreciated. Thank you so much.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1738864/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1614248] Re: Package autofs does not include autofs.service file

[ChristianEhrhardt]

Per Debian fix in 5.1.2-1
"AFAIKS, autofs is providing a .service now with an After=sssd"
This is in Ubuntu as of Zesty.

I'll mark the tasks accordingly.

Adding the service in Xenial in general might have too much risk to cause other 
regressions - not sure thou - I beg your pardon - this is just an area I rarely 
work on.
Is there a way to express this in the sysv that xenial has, maybe via [1].
I can envision a setup with autofs and no ssh, so it is not required, but maybe 
"should".
So maybe in header of /etc/init.d/autofs:
  Should-Start: ssh

I wonder how that carries over into the systemd generator used in
Xenial.

Could one affected give it a try instead of adding the full .service file to 
add that and then run the following to pick up the changes
$ sudo systemctl daemon-reload

** Also affects: autofs (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: autofs (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: autofs (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1614248

Title:
  Package autofs does not include autofs.service file

Status in autofs:
  Fix Released
Status in autofs package in Ubuntu:
  Fix Released
Status in autofs source package in Xenial:
  Confirmed

Bug description:
  Package autofs in Ubuntu 16.04 includes SysV startup script
  (/etc/init.d/autofs) and Upstart unit (/etc/init/autofs.conf), but
  does not include systemd service file. As a result, systemd starts
  autofs as part of its LSB (sysv) processing, which makes it difficult
  to ensure that autofs is started after services that it requires for
  proper functioning. In particular, unit autogenerated by systemd-sysv-
  generator for autofs does not include dependency on sssd.service.

  It appears that on the installation that I tested, systemd starts LSB
  services well after sssd is started, so the issue does not cause any
  visible problems, but this startup sequence is accidental. Given the
  number of other issues related to autofs startup in Xenial, requiring
  users to get their hands dirty just to have autofs run properly after
  boot, I think it would be advantageous to fix this simple oversight.
  (See bug 1566508, bug 1584818, bug 1588915)

  I attach an example service file for autofs that fixes this problem.
  In addition to sssd.service, this unit could also list nslcd.service,
  slapd.service and ypbind.service/nis.service in its After= line.
  However, these service files are also missing from their respective
  packages, and I am not even sure how NIS client service file would be
  called.

  $lsb_release -rd
  Description:Ubuntu 16.04.1 LTS
  Release:16.04

  $apt-cache policy autofs
  autofs:
Installed: 5.1.1-1ubuntu3
Candidate: 5.1.1-1ubuntu3

To manage notifications about this bug go to:
https://bugs.launchpad.net/autofs/+bug/1614248/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1734856] Re: Can't boot VM with more than 16 disks (slof buffer issue)

[ChristianEhrhardt]

Thanks for the bug, I see the patch is under active discussion atm.
Lets take a look to integrate once that discussion concludes.

Since it is packaged in slof I assigned that as the target and opened up
per release tasks.

** Package changed: qemu (Ubuntu) => slof (Ubuntu)

** Also affects: slof (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: slof (Ubuntu Bionic)
   Importance: Critical
 Assignee: David Britton (davidpbritton)
   Status: New

** Also affects: slof (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: slof (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Bug watch added: github.com/qemu/SLOF/issues #3
   https://github.com/qemu/SLOF/issues/3

** Also affects: slof via
   https://github.com/qemu/SLOF/issues/3
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1734856

Title:
  Can't boot VM with more than 16 disks (slof buffer issue)

Status in SLOF - Slimline Open Firmware:
  Unknown
Status in The Ubuntu-power-systems project:
  New
Status in slof package in Ubuntu:
  New
Status in slof source package in Xenial:
  New
Status in slof source package in Zesty:
  New
Status in slof source package in Artful:
  New
Status in slof source package in Bionic:
  New

Bug description:
  == Comment: #0 - RAHUL CHANDRAKAR  - 2017-11-28 03:40:37 
==
  ---Problem Description---
  Can't boot VM with more than 16 disks.
  It is an issue with qemu/SLOF (Bug: https://github.com/qemu/SLOF/issues/3) 
and it was fixed by Nikunj Amritlal Dadhnia.  He has made a patch available and 
it has been tested by PowerVC team.

  We need this fix in Ubuntu 16.04 and later releases.
   
  Machine Type = 8348-21C (P8 Habanero) 
   
  ---Steps to Reproduce---
   Steps to recreate:
  1. Create a VM
  2. Attach 50 disks
  3. Shutdown from OS
  4. Start again and let it boot
   
  ---uname output---
  Linux neo160.blr.stglabs.ibm.com 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 
18:29:11 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
   
  ---Debugger---
  A debugger is not configured
   

  Patch posted and awaiting response...

  http://patchwork.ozlabs.org/patch/842011/

To manage notifications about this bug go to:
https://bugs.launchpad.net/slof/+bug/1734856/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1732746] Re: [Trusty] iscsitarget-dkms 1.4.20.3+svn499-0ubuntu2.3 fails to build on linux-lts-xenial kernel

[ChristianEhrhardt]

Ok cascardo, that means it is fixed in Xenial and you'll take Trusty by
moving your existing fix there then - thanks for the info - updating
tasks.

** Changed in: iscsitarget (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: iscsitarget (Ubuntu Xenial)
   Status: Incomplete => Fix Released

** Changed in: iscsitarget (Ubuntu Trusty)
 Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1732746

Title:
  [Trusty] iscsitarget-dkms 1.4.20.3+svn499-0ubuntu2.3 fails to build on
  linux-lts-xenial kernel

Status in iscsitarget package in Ubuntu:
  Fix Released
Status in iscsitarget source package in Trusty:
  Triaged
Status in iscsitarget source package in Xenial:
  Fix Released

Bug description:
  iscsitarget ADT tests are failing on Trusty with linux-meta-lts-xenial
  4.4.0-101.124~14.04.1 due to iscsitarget-dkms
  1.4.20.3+svn499-0ubuntu2.3 compilation failure.

  amd64:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  trusty/trusty/amd64/i/iscsitarget/20171115_174514_4fc3d@/log.gz

  i386:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  trusty/trusty/i386/i/iscsitarget/20171115_174142_4fc3d@/log.gz

  ppc64el:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  trusty/trusty/ppc64el/i/iscsitarget/20171115_174421_4fc3d@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iscsitarget/+bug/1732746/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1732746] Re: [Trusty] iscsitarget-dkms 1.4.20.3+svn499-0ubuntu2.3 fails to build on linux-lts-xenial kernel

[ChristianEhrhardt]

Hmm, bug 1701697 lists Xenial - I'd wait for Cascardos comment but would
expect the same breakage there.

** Changed in: iscsitarget (Ubuntu)
 Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)

** Also affects: iscsitarget (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: iscsitarget (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: iscsitarget (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: iscsitarget (Ubuntu Xenial)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1732746

Title:
  [Trusty] iscsitarget-dkms 1.4.20.3+svn499-0ubuntu2.3 fails to build on
  linux-lts-xenial kernel

Status in iscsitarget package in Ubuntu:
  Triaged
Status in iscsitarget source package in Trusty:
  Triaged
Status in iscsitarget source package in Xenial:
  Incomplete

Bug description:
  iscsitarget ADT tests are failing on Trusty with linux-meta-lts-xenial
  4.4.0-101.124~14.04.1 due to iscsitarget-dkms
  1.4.20.3+svn499-0ubuntu2.3 compilation failure.

  amd64:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  trusty/trusty/amd64/i/iscsitarget/20171115_174514_4fc3d@/log.gz

  i386:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  trusty/trusty/i386/i/iscsitarget/20171115_174142_4fc3d@/log.gz

  ppc64el:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  trusty/trusty/ppc64el/i/iscsitarget/20171115_174421_4fc3d@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iscsitarget/+bug/1732746/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1731482] Re: outdated version of libvirt-python 1.3.1 crashes on call to getAllDomainStats

[ChristianEhrhardt]

Hi Felix,
thanks for your report.
Per SRU policy [1] we won't backport 1.3.4 or newer.
If you ever need soemthing like that take a look at UCA [2].

But backporting the fix is certainly the right thing to look at.

** Also affects: libvirt-python (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt-python (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1731482

Title:
  outdated version of libvirt-python 1.3.1 crashes on call to
  getAllDomainStats

Status in libvirt-python package in Ubuntu:
  Fix Released
Status in libvirt-python source package in Xenial:
  New

Bug description:
  The following bug is present in the curent version of libvirt-python
  in Xenial (1.3.1):

  https://bugzilla.redhat.com/show_bug.cgi?id=1326839

  This bug has been resolved in 1.3.4 by the following commit:

  https://gitlab.com/libvirt/libvirt-
  python/commit/e9c4e2abffef007a28112ebb40a9586b0128f10b

  This bug is e.g. triggered when using OpenStack Telemetry (Ceilometer)
  and configuring it to collect "cpu" metering data. This leads to the
  segmentation fault mentioned in the linked bug report.

  The version of libvirt-python in Xenial should be updated to >= 1.3.4
  or at least the linked fix should be backported.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt-python/+bug/1731482/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1726394] Re: Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

[ChristianEhrhardt]

Ok, thanks for the info Julian!

** Changed in: qemu (Ubuntu Xenial)
   Status: Triaged => Won't Fix

** Changed in: qemu (Ubuntu Zesty)
   Status: Triaged => Won't Fix

** Changed in: qemu (Ubuntu Artful)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1726394

Title:
  Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

Status in QEMU:
  In Progress
Status in qemu package in Ubuntu:
  Fix Committed
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Zesty:
  Won't Fix
Status in qemu source package in Artful:
  Won't Fix
Status in qemu package in Debian:
  Confirmed

Bug description:
  qemu-user passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER,
  address) unmodified, but the third argument is an address to a BPF
  filter, causing an EFAULT. Now, the filter is architecture-specifc, so
  you can't just rewrite the addresses, so the safest bet is to just
  return an error here.

  I guess you should just return EINVAL, but not sure. I'd really like
  something that can be identified, so seccomp errors can be ignored
  when it's not supported.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1726394/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1707999] Re: pod VM fails to PXE boot after receiving multiple DHCP offers, for different IPs, from the dhcp server

[ChristianEhrhardt]

Nothing from my POV, I expected Andres to propose or upload the same fix
for X/Z now as he did for Artful last month.

Btw I'll mark Artful correctly and add X/Z tasks.

** Also affects: ipxe (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: ipxe (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Changed in: ipxe (Ubuntu Artful)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1707999

Title:
  pod VM fails to PXE boot after receiving multiple DHCP offers, for
  different IPs, from the dhcp server

Status in MAAS:
  Invalid
Status in MAAS 2.2 series:
  Invalid
Status in ipxe package in Ubuntu:
  Fix Released
Status in ipxe source package in Xenial:
  Triaged
Status in ipxe source package in Zesty:
  Triaged
Status in ipxe source package in Artful:
  Fix Released
Status in ipxe source package in Bionic:
  Fix Released

Bug description:
  A VM failed to PXE boot after receiving multiple DHCP offers.

  You can see this here on a log from the secondary controller:
  http://paste.ubuntu.com/25221939/

  The node is offered both 10.245.208.201 and 10.245.208.120, tries to
  get 10.245.208.120, and is refused.

  One strange thing is that it seems like the DHCP server on both the primary 
controller and the secondary controller are responding.  The primary 
controller's log doesn't have the offer for 10.245.208.120 - only the offer for 
10.245.208.201:
  http://paste.ubuntu.com/25221952/

  This is in an HA setup: region API's are at 10.245.208.30,
  10.245.208.31 and 10.245.208.32. We're using hacluster to load
  balance, and a VIP in front at 10.245.208.33. There are rack
  controllers on 10.245.208.30 and 10.245.208.31. For the untagged vlan
  this VM is trying to boot from, 10.245.208.30 is set as the primary
  controller, and 10.245.208.31 is set as the secondary.

  Primary postgres is on 10.245.208.30, it's being replicated to backup
  postgres on 10.245.208.31. It has a VIP at 10.245.208.34.

  We don't hit this everytime - on this deployment only one machine out
  of about 30 hit this.

  We've also seen this on single node MAAS setups - non HA.  So, it's
  not an HA specific issue.

  I've attached logs from the maas servers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1707999/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1730661] Re: New upstream microreleases 9.3.20, 9.5.10 and 9.6.6

[ChristianEhrhardt]

So far tests hit some known issues lxd-testers and one about pgcluster
setup in some tests needing to avoid blocked ports. Those are all fixed
in later releases already and usually ignored on the SRU (:-/, but a
tradeoff of time).

That said it seems all known good tests are good still - pushing for SRU
review.

P.S. also the release is public now, so opening up the bug visibility.

** Information type changed from Private Security to Public

** Also affects: postgresql-10 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: postgresql-10 (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1730661

Title:
  New upstream microreleases 9.3.20, 9.5.10 and 9.6.6

Status in postgresql-10 package in Ubuntu:
  Fix Committed
Status in postgresql-9.3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-9.6 package in Ubuntu:
  Invalid
Status in postgresql-9.3 source package in Trusty:
  Triaged
Status in postgresql-9.5 source package in Xenial:
  Triaged
Status in postgresql-9.6 source package in Zesty:
  Triaged
Status in postgresql-9.6 source package in Artful:
  Triaged

Bug description:
  Update to the new set of releases as per the standing micro-release
  exception these should land in stable Ubuntu releases.

  Current versions in releases: 
  
   postgresql-9.3 | 9.3.19-0ubuntu0.14.04 trusty
  
   postgresql-9.5 | 9.5.9-0ubuntu0.16.04  xenial
  
   postgresql-9.6 | 9.6.5-0ubuntu0.17.04  zesty 
  
   postgresql-9.6 | 9.6.5-1   artful
  

  
  No "special" cases known this time.   
  

  
  Last stable updates   
  
  PostgreSQL 9.6.6, 9.5.10, 9.4.15, 9.3.20, 9.2.24  
  

  
  So the todo is to pick:   
  
  MRE: Trusty 9.3.20 from 
https://borka.postgresql.org/staging/5d4e3dcc636f182a69ff7ff51286c1a20e930c9e/postgresql-9.3.20.tar.gz
  MRE: Xenial 9.5.10 from 
https://borka.postgresql.org/staging/5d4e3dcc636f182a69ff7ff51286c1a20e930c9e/postgresql-9.5.10.tar.gz
  MRE: Zesty 9.6.6 from 
https://borka.postgresql.org/staging/5d4e3dcc636f182a69ff7ff51286c1a20e930c9e/postgresql-9.6.6.tar.gz
  Sync: Artful 9.6.6 as above   
  

  
  Standing MRE - Consider last updates as template: 
  
  - pad.lv/1637236  
  
  - pad.lv/1664478  
  
  - pad.lv/1690730  
  
  - pad.lv/1713979

  Note: opening private as it is not yet announced

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-10/+bug/1730661/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1487679] Re: CRITICAL BUG: Breaking ordering cycle by deleting job NetworkManager.service/start

[ChristianEhrhardt]

There are many potential affected packages I have no insight, but for
nbd this should be fixed since  1:3.14-1 by upstream now providing a
native systemd service.

That means >=Zesty should be fixed in that regard.
Not sure on backporting that - one would need to check the potential further 
context that needs to go back to Xenial, but that might be the proper solution 
that one might want to try.


** Also affects: nbd (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796633
   Importance: Unknown
   Status: Unknown

** Also affects: util-linux (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: nfs-utils (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: nbd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: avahi (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: network-manager (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: open-iscsi (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: rpcbind (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: nbd (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: nbd (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1487679

Title:
  CRITICAL BUG: Breaking ordering cycle by deleting job
  NetworkManager.service/start

Status in systemd:
  Fix Released
Status in avahi package in Ubuntu:
  Confirmed
Status in nbd package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Won't Fix
Status in nfs-utils package in Ubuntu:
  Confirmed
Status in open-iscsi package in Ubuntu:
  New
Status in rpcbind package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in util-linux package in Ubuntu:
  Confirmed
Status in avahi source package in Xenial:
  New
Status in nbd source package in Xenial:
  Triaged
Status in network-manager source package in Xenial:
  New
Status in nfs-utils source package in Xenial:
  New
Status in open-iscsi source package in Xenial:
  New
Status in rpcbind source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in util-linux source package in Xenial:
  New
Status in nbd package in Debian:
  Unknown

Bug description:
  
  $ lsb_release -rd
  Description:  Ubuntu 15.04
  Release:  15.04

  $ apt-cache policy nbd-client
  nbd-client:
    Installed: 1:3.8-4ubuntu0.1
    Candidate: 1:3.8-4ubuntu0.1
    Version table:
   *** 1:3.8-4ubuntu0.1 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ vivid-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   1:3.8-4 0
  500 http://ch.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

  I'm using the nbd-client to mount some raw disk images over the
  network but starting the nbd-client automatically during bootup does
  not happen due to the following:

  Aug 22 08:54:20 fractal kernel: [   11.875885] systemd[1]: Found dependency 
on nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875890] systemd[1]: Breaking ordering 
cycle by deleting job nbd-client.service/start
  Aug 22 08:54:20 fractal kernel: [   11.875891] systemd[1]: Job 
nbd-client.service/start deleted to break ordering cycle starting with 
basic.target/start

  Meaning after boot, I have to manually run `sudo ndb-client start`
  every time I want to access these images. Note that this is no
  diskless system, the images I mount via NBD do not contain the local
  system, they are totally unrelated.

  
  -
  Bug with NFS-server and RPC-bind is indicated by messages:

  $ journalctl | grep -i break
  ноя 06 22:49:57 norbert-vaio systemd[1]: network.target: Breaking ordering 
cycle by deleting job NetworkManager.service/start
  ноя 06 22:49:57 norbert-vaio systemd[1]: NetworkManager.service: Job 
NetworkManager.service/start deleted to break ordering cycle starting with 
network.target/start
  ноя 06 22:49:57 norbert-vaio systemd[1]: nfs-server.service: Breaking 
ordering cycle by deleting job rpcbind.socket/start
  ноя 06 22:49:57 norbert-vaio systemd[1]: rpcbind.socket: Job 
rpcbind.socket/start deleted to break ordering cycle starting with 
nfs-server.service/start

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1487679/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.

[Group.of.nepali.translators] [Bug 1710019] Re: support GICv3 ITS save/restore & migration

[ChristianEhrhardt]

Ok, Dann - thanks for the clarification.
So per the SRU rules to not regress on updates that would then be Zesty, 
Artful, Bionic.
With Qemu being ok since Artful and Kernel needing your backports in Zesty 4.10 
and Artful 4.13 then.

I'm setting up the tasks correctly then.
Do you want me to eval the Qemu changes in zesty right now (based on your 
debdiff), or do you want to prep the kernel changes first so that you have 
verified them for the actual feature?

** Also affects: qemu (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Artful)
   Status: New => In Progress

** Changed in: linux (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: qemu (Ubuntu Artful)
   Status: New => Fix Released

** Changed in: qemu (Ubuntu Xenial)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1710019

Title:
  support GICv3 ITS save/restore & migration

Status in linux package in Ubuntu:
  In Progress
Status in qemu package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in qemu source package in Xenial:
  Won't Fix
Status in linux source package in Zesty:
  In Progress
Status in qemu source package in Zesty:
  In Progress
Status in linux source package in Artful:
  In Progress
Status in qemu source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Virtual machines on GICv3-based ARM systems cannot be saved/restored or 
migrated.
  This feature was added in QEMU 2.10.

  [Test Case]
  ubuntu@grotrian:~$ sudo virsh save 7936-0 7936-0.sav

  Domain 7936-0 saved to 7936-0.sav

  ubuntu@grotrian:~$ sudo virsh restore 7396-0.sav
  error: Failed to restore domain from 7396-0.sav
  error: operation failed: job: unexpectedly failed

  ubuntu@grotrian:~$ sudo tail -3 /var/log/libvirt/qemu/7936-0.log 
  2017-08-10T21:26:38.217427Z qemu-system-aarch64: State blocked by 
non-migratable device 'arm_gicv3_its'
  2017-08-10T21:26:38.217565Z qemu-system-aarch64: load of migration failed: 
Invalid argument
  2017-08-10 21:26:38.217+: shutting down, reason=failed

  [Regression Risk]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1710019/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1684295] Re: sssd fails with 'Exiting the SSSD. Could not restart critical service [tpad].

[ChristianEhrhardt]

** Also affects: sssd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: sssd (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: sssd (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: sssd (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: sssd (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1684295

Title:
  sssd fails with 'Exiting the SSSD.  Could not restart critical service
  [tpad].

Status in sssd package in Ubuntu:
  Fix Released
Status in sssd source package in Xenial:
  In Progress

Bug description:
  [Impact]
  In this particular configuration, when ldap_rfc2307_fallback_to_local_users 
is set to true in /etc/sss/sssd.conf and a local user is a member of an ldap 
group and does not exist in the directory (other scenarios are possible), the 
sssd_be process segfaults and logins might be prevented.

  The original scenario is a bit more complex and involves setting up an
  Active Directory server, but with the help from the bug reporter
  (thanks @pam-s!) we managed to narrow it down to this simple test
  case.

  [Test Case]

  # Install the packages. When prompted, choose any password for the ldap admin
  $ sudo apt update; sudo apt install sssd slapd

  # create the sssd config
  $ sudo tee /etc/sssd/sssd.conf 

[Group.of.nepali.translators] [Bug 1729858] Re: virt-clone fails with: Unknown driver 'iso'

[ChristianEhrhardt]

Hi Jürg,
thanks for using the tool - I rarely do so I appreciate your testing.
Furthermore identifying the fix is nice.

So this went into libvirt in 3.2, so >=Artful is fixed.


** Also affects: libvirt (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Zesty)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1729858

Title:
  virt-clone fails with: Unknown driver 'iso'

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Triaged
Status in libvirt source package in Zesty:
  Triaged

Bug description:
  Cloning a uvt VM fails with error: Unknown driver 'iso'

  To reproduce:

  uvt-simplestreams-libvirt sync release=xenial arch=amd64
  uvt-kvm create test-vm release=xenial arch=amd64
  virsh destroy test-vm
  virt-clone -o test-vm -n cloned-vm --auto-clone

  Which results in:

  WARNING  The requested volume capacity will exceed the available pool space 
when the volume is fully allocated. (8192 M requested capacity > 3898 M 
available)
  Allocating 'cloned-vm.qcow'   
   | 
8.0 GB  00:00:01 
  ERRORCouldn't create storage volume 'test-vm-ds-clone.qcow': 'internal 
error: Child process (/usr/bin/qemu-img convert -f iso -O iso 
/var/lib/uvtool/libvirt/images/test-vm-ds.qcow 
/var/lib/uvtool/libvirt/images/test-vm-ds-clone.qcow) unexpected exit status 1: 
qemu-img: Could not open '/var/lib/uvtool/libvirt/images/test-vm-ds.qcow': 
Unknown driver 'iso'
  '

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1729858/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1696066] Re: Postfix module - Mailman wrapper - Couldn't write data/aliases.db and data/virtual-mailman.db files

[ChristianEhrhardt]

Ok, I'm not gettign to this soon, but there are also a few steps we have to 
wait for.
So for now I document the next steps and subscribe the team to look at this 
again later on:

1. 2.1.25 in Debian
2. 2.1.25 in Ubuntu (Bionic)
3. SRU fix into X-A releases


** Also affects: mailman (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: mailman (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: mailman (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Tags added: server-next

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1696066

Title:
  Postfix module - Mailman wrapper - Couldn't write data/aliases.db and
  data/virtual-mailman.db files

Status in GNU Mailman:
  Fix Released
Status in mailman package in Ubuntu:
  Triaged
Status in mailman source package in Xenial:
  New
Status in mailman source package in Zesty:
  New
Status in mailman source package in Artful:
  New
Status in mailman package in Debian:
  New

Bug description:
  Dear project leader

  At least in version 2.1.23, there is a bug regarding permissions set
  for Mailman data/aliases table and Mailman data/virtual-mailman map
  when these files are created from scratch.

  Here I describe the current behavior for the Mailman data/aliases
  table only but the problem is identical for the Mailman data/virtual-
  mailman map.

  In order, the following conditions have to be met:

  - Postfix need read access to the aliases.db file
  - Mailman like to be owner of those files and the Mailman group needs write 
access to them

  I. Postfix needs a read access to the aliases.db file

  We can either set permissions as 0660 and add postfix user to mailman
  group (what I've done), or set the permissions as 0664

  II. Mailman group needs a write access to those files at any time

  The following behavior has been observed:

  When creating a new list on command line, using bin/newlist script as
  follow:

  # newlist -u virtualhost foobar

  the files will be created as follow:

  -rw-rw 1 root list aliases
  -rw-r- 1 root list aliases.db

  The same thing has been observed when recreating the file from scratch
  using bin/genaliases:

  -rw-rw 1 root list aliases
  -rw-r- 1 root list aliases.db

  Note that in both cases, files were not present. Thus, they were
  created from scratch.

  As you can see here, the Mailman data/aliases file is created with the
  expected group and permissions but the data/aliases.db file is only
  writable by owner. From the POSTALIAS(1) command point of view, that
  is the expected behavior: The file is created with the same group and
  other read permissions as their source file.

  The problem here is that with those permissions, creating a list
  through Mailman interface later on will result in a permissions denied
  error because the Mailman group, through the wrapper, cannot write
  (update) the aliases.db file (no write permissions).

  That is really a problem. Of course, one can just pre-create the files
  as follow:

  # cd /var/lib/mailman
  # sg list -c "touch data/aliases && postalias data/aliases"
  # chmod 0660 data/aliases*

  but that seem tedious. What if at some point (for any reason), the
  files get recreated from scratch?

  So, from my point of view, the MTA/Postfix.py module should always set
  correct permissions on *.db file,  to be sure that Mailman group has
  write permissions, at least when the files are created from scratch.
  Eg:

  IF NOT EXISTS aliases:
     Touch data/aliases data/aliases.db with correct permissions (066x)
     Add alias entries into aliases as usually
     Run POSTALIAS(1) command as usually

  Then, we are fine.

  Thank you.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mailman/+bug/1696066/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1727366] Re: virsh start/destroy is too slow after adding firewall rule

[ChristianEhrhardt]

virExec:
for (fd = 3; fd < openmax; fd++) {  
 
if (fd == childin || fd == childout || fd == childerr)  
 
continue;   
 
if (!virCommandFDIsSet(cmd, fd)) {  
 
tmpfd = fd; 
 
VIR_MASS_CLOSE(tmpfd);  
 
} else if (virSetInherit(fd, true) < 0) {   
 
virReportSystemError(errno, _("failed to preserve fd %d"), fd); 
 
goto fork_error;
 
}   
 
}

openmax is the limit that gets indirectly derived from that systemd limit.
But with [1] Im not sure ho much more one can do.

[1]: https://stackoverflow.com/questions/899038/getting-the-highest-
allocated-file-descriptor/918469#918469

** Changed in: libvirt (Ubuntu)
   Status: In Progress => Opinion

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1727366

Title:
  virsh start/destroy is too slow after adding firewall rule

Status in libvirt package in Ubuntu:
  Opinion
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Zesty:
  Won't Fix

Bug description:
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  libvirt-bin:
Installed: 1.3.1-1ubuntu10.14
Candidate: 1.3.1-1ubuntu10.14

  The starting/stopping time of the domain is dramatically increased
  after adding nw-filter rule:

  Actual timings:
  --

  # time virsh destroy 9000
  Domain 9000 destroyed

  
  real  0m9.252s
  user  0m0.024s
  sys   0m0.000s

  Expected timings: (without active filterref item)
  

  $ time virsh destroy 9000
  Domain 9000 destroyed

  real0m0.633s
  user0m0.012s
  sys 0m0.008s

  Steps to reproduce:
  --

  1. Enable any firewall rule, which is shipped with a package. In
  example it could be allow-arp:

  





  

  2. Stop domain:

  $ virsh destroy 9000

  3. Start domain:

  $ LIBVIRT_DEBUG=debug virsh start 9000

  Debug output attached as libvirt-debug.log

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1727366/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1727366] Re: virsh start/destroy is too slow after adding firewall rule

[ChristianEhrhardt]

Not sure if it is a strace artifact, but in the slow case I see way more system 
calls.
Those extra calls are what consumes the time.

It seems that after the call it does some cleanup.
But it does not a guided cleanup (e.g. closing all FDs it knows).
No - instead it seems to run a loop closing all FDs possible.

Now on Artful that runs 1-8192 (14bit), but on Zesty it is 1-1048575 (20 bit).
I think I remember having seen that close all FDs in the past, but can't 
remember exactly where.

But while I miss that I remember the limits I see here.
libvirtd before Artful had LimitNOFILE=infinity in its service file.
On Artful and later it has LimitNOFILE=8192 (actually we had to raise that 
recently for bigger installations, but never the less way smaller than 1M).

Adapting those limits makes it fast.

So summarizing what we know:
- some cleanup seems to clsoe all *possible* files
- the number of possible files got reduced in later libvirt version (for other 
reasons)
- We can't SRU a smaller limit anyway, but looking forward I want to look into 
the "close all" and which code does so.
- A solution for those affected is available by adapting LimitNOFILE in 
/lib/systemd/system/libvirtd.service

I'll mark this as Won't Fix for the reasons outline in older releases,
but want to take a look if that "close all" can be optimized.

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Zesty)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1727366

Title:
  virsh start/destroy is too slow after adding firewall rule

Status in libvirt package in Ubuntu:
  In Progress
Status in libvirt source package in Xenial:
  Won't Fix
Status in libvirt source package in Zesty:
  Won't Fix

Bug description:
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  libvirt-bin:
Installed: 1.3.1-1ubuntu10.14
Candidate: 1.3.1-1ubuntu10.14

  The starting/stopping time of the domain is dramatically increased
  after adding nw-filter rule:

  Actual timings:
  --

  # time virsh destroy 9000
  Domain 9000 destroyed

  
  real  0m9.252s
  user  0m0.024s
  sys   0m0.000s

  Expected timings: (without active filterref item)
  

  $ time virsh destroy 9000
  Domain 9000 destroyed

  real0m0.633s
  user0m0.012s
  sys 0m0.008s

  Steps to reproduce:
  --

  1. Enable any firewall rule, which is shipped with a package. In
  example it could be allow-arp:

  





  

  2. Stop domain:

  $ virsh destroy 9000

  3. Start domain:

  $ LIBVIRT_DEBUG=debug virsh start 9000

  Debug output attached as libvirt-debug.log

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1727366/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1668724] Re: fails to mount cgroupfs inside containers running on 16.04

[ChristianEhrhardt]

This was removed from Xenial-Proposed as well.
It is still in Y-proposed but that is EOL.


Given the time that has passed and the rather unclear state I'd consider this 
bug incomplete.
In comment #29 Serge outlined that for Trusty all of that not really applies 
(everyone is using backports there?)

I'll update the bug tasks to reflect all that.

@Serge - Please update if you still work on this or have a fix
somewhere.

** Changed in: cgroup-lite (Ubuntu Yakkety)
   Status: Fix Committed => Won't Fix

** Changed in: cgroup-lite (Ubuntu Xenial)
   Status: Fix Committed => Incomplete

** Changed in: cgroup-lite (Ubuntu Trusty)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1668724

Title:
  fails to mount cgroupfs inside containers running on 16.04

Status in cgroup-lite package in Ubuntu:
  Fix Released
Status in cgroup-lite source package in Precise:
  Won't Fix
Status in cgroup-lite source package in Trusty:
  Incomplete
Status in cgroup-lite source package in Xenial:
  Incomplete
Status in cgroup-lite source package in Yakkety:
  Won't Fix

Bug description:
  I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts,
  and have noticed that the cgroups-mount script for mounting the
  cgroups inside the containers has stopped working. This is because
  systemd now comounts multiple controllers on a single hierarchy, which
  prevents mounting them individually inside the container.

  ===  SRU Justification 
  Impact: nested containers fail to start
  Reproduce:  create a root owned container;  install lxc and cgroup-lite;  
create a container, and try to start it.  Starting will fail if cgroup-lite is 
running in the first level container without this patch.
  Regression potential:  should be low, it's possible that the regexp is simply 
wrong for some cases.
  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1583503] Re: keepalived fails to start when PID file is empty

[ChristianEhrhardt]

Cleaning this after a while, no further action is needed.
- T/X have a workaround in Neutron
- Latter versions of keepalive use systemd MAINPID tracking which is somewhat 
more robust in this regard

That said in the context this appeared it is fixed, lets set the old
tasks to Won't Fix unless there is a real need.

** Changed in: keepalived (Ubuntu Xenial)
   Status: Incomplete => Won't Fix

** Changed in: keepalived (Ubuntu Trusty)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1583503

Title:
  keepalived fails to start when PID file is empty

Status in neutron:
  Fix Released
Status in keepalived package in Ubuntu:
  Fix Released
Status in keepalived source package in Trusty:
  Won't Fix
Status in keepalived source package in Xenial:
  Won't Fix

Bug description:
  After a crash of a network node, we were left with empty PID files for
  some keepalived processes:

   root@network-node14:~# ls -l 
/var/lib/neutron/ha_confs/0ab5f647-1e04-4345-ae9b-ee66c6f08882.pid
  -rw-r--r-- 1 root root 0 May 19 08:41 
/var/lib/neutron/ha_confs/0ab5f647-1e04-4345-ae9b-ee66c6f08882.pid

  This causes the L3 agent to log the following errors repeating every
  minute:

  2016-05-19 08:46:44.525 13554 ERROR neutron.agent.linux.utils [-] Unable to 
convert value in 
/var/lib/neutron/ha_confs/0ab5f647-1e04-4345-ae9b-ee66c6f08882.pid
  2016-05-19 08:46:44.526 13554 ERROR neutron.agent.linux.external_process [-] 
keepalived for router with uuid 0ab5f647-1e04-4345-ae9b-ee66c6f08882 not found. 
The process should not have died
  2016-05-19 08:46:44.526 13554 WARNING neutron.agent.linux.external_process 
[-] Respawning keepalived for uuid 0ab5f647-1e04-4345-ae9b-ee66c6f08882
  2016-05-19 08:46:44.526 13554 ERROR neutron.agent.linux.utils [-] Unable to 
convert value in 
/var/lib/neutron/ha_confs/0ab5f647-1e04-4345-ae9b-ee66c6f08882.pid
  2016-05-19 08:46:44.526 13554 ERROR neutron.agent.linux.utils [-] Unable to 
convert value in 
/var/lib/neutron/ha_confs/0ab5f647-1e04-4345-ae9b-ee66c6f08882.pid-vrrp

  and the keepalived process fails to start. As a result, the routers
  hosted by this agent are non-functional.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1583503/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1726017] Re: dnsmasq prematurely returns REFUSED, breaking resolver

[ChristianEhrhardt]

Hi Martin,
thanks for your great pre-analysis.
I agree to the general issue and the changes are small enough to review 
although the context it implies is a lot.

Also we need to be clear that this has two stages of not-correct:
2.76: 4ace25c5d6: Treat REFUSED (not SERVFAIL) as an unsuccessful upstream 
response
2.77: 68f6312d4b: Stop treating SERVFAIL as a successful response from upstream 
servers.

So:
- Xenial is lacking both
- Zesty is lacking the second
- Artful is good

Since I rarely patch dsnsmasq I wanted to ask for a check before going to an 
SRU with that.
I provided a ppa at [1] with test builds for Xenial and Zesty.

If you could try those out that would be very kind.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3003

** Also affects: dnsmasq (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: dnsmasq (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: dnsmasq (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1726017

Title:
  dnsmasq prematurely returns REFUSED, breaking resolver

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Xenial:
  New
Status in dnsmasq source package in Zesty:
  New

Bug description:
  Seen with dnsmasq 2.75-1ubuntu0.16.04.3, after Trusty->Xenial update.

  In my local network, I have two DNS servers; 192.168.1.1 is the local
  DHCP/DNS server configured to reply to queries inside the local
  network, and 192.168.1.4 is the forwarder in my DSL Router,
  responsible to answer queries about the outside world. THe DHCP server
  returns these in the order 192.168.1.4,192.168.1.1. The internal
  server replies REFUSED to queries about external domains.

  This configuration has worked well with Ubuntu 14.04 and other Linux
  Distros (using Fedora and OpenSUSE internally here), as well as
  various other OSes.

  It does not work with Ubuntu 16.04. NetworkManager's dnsmasq instance
  pushes the REFUSED reply from 192.168.1.1 to applications and ignores
  the successful reply from 2.168.1.4. This causes all DNS queries to
  external servers to fail.

  I believe this is fixed in dnsmasq 2.76 and related to

  http://lists.thekelleys.org.uk/pipermail/dnsmasq-
  discuss/2016q1/010263.html

  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=68f6312d4bae30b78daafcd6f51dc441b8685b1e
  http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=object;h=4ace25c5d6

  According to these sources, the bug was introduced with 
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=object;h=51967f9807665dae403f1497b827165c5fa1084b

  In my local setup at least, I can work around the problem by using the
  "strict-order" option to dnsmasq.

  echo strict-order >/etc/NetworkManager/dnsmasq.d/order.conf

  But that's not a general solution. If dnsmasq has several forwarders,
  and some return SERVFAIL or REFUSED and others return SUCCESS, the
  successful answer should be returned to clients, independent of the
  strict-order setting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1726017/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1349941] Re: qemu-ppc segfault on simple hello world

[ChristianEhrhardt]

Hi,
nothing happened since then.
I was trying to reproduce but it seems (to me) down to none of us knowing how 
to correctly resolve libraries.

So before here people reported:
- static builds work
- dynamic builds fail for some with ld.so failing and crashing for others
- dynamic builds fail

To resolve this a bit one has to follow [1] which also needs [2].
Once you did that the issue of the missing ld.so (of the target arch) is 
resolved.

Doing that I can re-create the issue - even on xenial still with a much newer 
qemu.
I can also confirm that doing the same e.g. with armhf is working - so it must 
be ppc specific.
Given the fact that this is a super rare case to need it and OTOH powerpc is 
mostly dropped in more recent releases this is still a low prio issue.

So even if it is low prio for me, I hope the links help if a community member 
wants to get onto this. to not let this bug hang-on for another few years I'll 
mark the tasks incomplete to see if one is still caring and might have a 
suggestion.
If for quite long again nobody volunteers to help or has a suggestion we might 
end up closing it.
Sorry but better honest than faking activity here :-/

[1]: https://wiki.debian.org/QemuUserEmulation
[2]: https://wiki.debian.org/Multiarch/HOWTO#Setting_up_apt_sources

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: qemu (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: qemu (Ubuntu Trusty)
   Status: Confirmed => Incomplete

** Changed in: qemu (Ubuntu)
   Status: Fix Released => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1349941

Title:
  qemu-ppc segfault on simple hello world

Status in qemu package in Ubuntu:
  Won't Fix
Status in qemu source package in Trusty:
  Incomplete
Status in qemu source package in Xenial:
  Incomplete

Bug description:
  qemu ppc fails to execute even a simple hello world app.

  jruble@jruble-linux:~/ppc_qemu_test$ cat test.c
  #include 

  int main(){
  printf("asdf\n");
  return 0;
  }

  
  jruble@jruble-linux:~/ppc_qemu_test$ powerpc-linux-gnu-gcc --version
  powerpc-linux-gnu-gcc (Ubuntu 4.8.2-16ubuntu3) 4.8.2
  Copyright (C) 2013 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

  
  jruble@jruble-linux:~/ppc_qemu_test$ powerpc-linux-gnu-gcc test.c 

  
  jruble@jruble-linux:~/ppc_qemu_test$ file a.out 
  a.out: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=714f9cfad9e06d0478bcd238ccbcbd10468741fc, not stripped

  
  jruble@jruble-linux:~/ppc_qemu_test$ qemu-ppc -version
  qemu-ppc version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.1), Copyright (c) 
2003-2008 Fabrice Bellard

  
  jruble@jruble-linux:~/ppc_qemu_test$ qemu-ppc ./a.out 
  Invalid data memory access: 0xfa98c008
  NIP f67e2b9c   LR f67e2c40 CTR  XER 
  MSR 6040 HID0   HF 6000 idx 0
  TB  
  GPR00 f67e2c1c f6ffe720  feb6c010
  GPR04 f67ec784 000b 0002 
  GPR08 0030 083c0010 f67ac00a 80808080
  GPR12 f67dcfc8   f67fe8c4
  GPR16 f67fe900 f6ffe998 f6ffe99c f67feaf0
  GPR20 f67fd6c4 000a feb6c010 f67fd320
  GPR24 fa98bff4 f7c5ef8d 11f9 041dfff4
  GPR28 f67fe900 5604 f67fdff4 2b027fff
  CR 44284042  [ G  G  E  L  G  -  G  E  ] RES 
  FPR00    
  FPR04    
  FPR08    
  FPR12    
  FPR16    
  FPR20    
  FPR24    
  FPR28    
  FPSCR 
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault (core dumped)
  jruble@jruble-linux:~/ppc_qemu_test$

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: qemu-user 2.0.0+dfsg-2ubuntu1.1
  ProcVersionSignature: Ubuntu 3.13.0-32.57-generic 3.13.11.4
  Uname: Linux 3.13.0-32-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.2
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Tue Jul 2

[Group.of.nepali.translators] [Bug 1716964] Re: VLAN network script if-up.d/ip limits rp_filter value to 0 or 1

[ChristianEhrhardt]

** Also affects: vlan (Ubuntu Artful)
   Importance: Medium
 Assignee: Dan Streetman (ddstreet)
   Status: In Progress

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1716964

Title:
  VLAN network script if-up.d/ip limits rp_filter value to 0 or 1

Status in vlan package in Ubuntu:
  In Progress
Status in vlan source package in Trusty:
  In Progress
Status in vlan source package in Xenial:
  In Progress
Status in vlan source package in Zesty:
  In Progress
Status in vlan source package in Artful:
  In Progress
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  Using ifupdown, an interface's rp-filter value cannot be set to 2.

  [test case]

  On any system using ifupdown to manage interfaces, add to an
  interface's config:

  if-rp-filter 2

  When the interface is brought up, its
  /proc/sys/net/ipv4/conf/$IFACE/rp_filter value will be set to 1
  instead of 2.  With the fixed vlan package, its value will correctly
  be set to 2.

  [regression potential]

  problems with this change could affect the value of an interface's
  rp_filter value.

  [other]

  the upstream debian bug for this has been open for 3 years without
  change, so it is unlikely debian will fix this.

  [original description]

  When configuring a VLAN interface on /etc/network/interfaces, setting
  the ip-rp-filter value to 2 (loose mode reverse filtering) gets
  overridden by the /etc/network/if-up.d/ip script, which only allows
  for values 0 and 1.

  This is the relevant configuration in /etc/network/interfaces

  # The primary network interface
  auto eno1
  iface eno1 inet static
   address 10.1.2.36
   netmask 255.255.0.0
   gateway 10.1.1.2
   dns-search xxx.yy
   dns-nameservers 10.1.2.22 10.1.2.24

  # The administrative network
  auto eno1.2
  iface eno1.2 inet static
   address 172.16.1.8
   netmask 255.255.0.0
   ip-rp-filter 2
   vlan-raw-device eno1

  But it does not get correctly set

  ~# cat /proc/sys/net/ipv4/conf/eno1.2/rp_filter
  1

  And this is the script overriding the configuration

  ~# cat /etc/network/if-up.d/ip
  #!/bin/sh
  # This should probably go into ifupdown
  # But usually only those with lots of interfaces (vlans) need these
  if [ -d "/proc/sys/net/ipv4/conf/$IFACE" ]
  then
   if [ -n "$IF_IP_PROXY_ARP" ]; then
    if [ "$IF_IP_PROXY_ARP" -eq "1" ]; then
     echo 1 > "/proc/sys/net/ipv4/conf/$IFACE/proxy_arp"
    else
     echo 0 > "/proc/sys/net/ipv4/conf/$IFACE/proxy_arp"
    fi
   fi
   if [ -n "$IF_IP_RP_FILTER" ]; then
    if [ "$IF_IP_RP_FILTER" -eq "0" ]; then
     echo 0 > "/proc/sys/net/ipv4/conf/$IFACE/rp_filter"
    else
     echo 1 > "/proc/sys/net/ipv4/conf/$IFACE/rp_filter"
    fi
   fi
  fi

  It checks if $IF_IP_RP_FILTER is 0 and sets it as 0, otherwise sets it
  as 1, so it never allows to set is to 2 (loose mode).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1716964/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1658469] Re: mod_http2 is not available under Apache 2.4.23 / Ubuntu 17.04 xenial

[ChristianEhrhardt]

Keeping Development open (waiting for statements on 17.10/18.04) but
denying the Xenial/Zesty tasks according to c#10

** Changed in: apache2 (Ubuntu Zesty)
   Status: Confirmed => Won't Fix

** Changed in: apache2 (Ubuntu Xenial)
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1658469

Title:
  mod_http2 is not available under Apache 2.4.23 / Ubuntu 17.04 xenial

Status in apache2 package in Ubuntu:
  Triaged
Status in apache2 source package in Xenial:
  Won't Fix
Status in apache2 source package in Zesty:
  Won't Fix

Bug description:
  mod_http2 for HTTP/2 is not available in folder /etc/apache2/mods-available
  (/etc/apache2/mods-available/http2.load does not exist)

  HTTP/2 (originally named HTTP/2.0) is the second major version of the
  HTTP network protocol used by the World Wide Web.

  In January 2016 it was decided not to put http/2 in Ubuntu 16.04 LTS
  because the code is too young and not compatible with a 5 years
  support: https://lists.ubuntu.com/archives/ubuntu-
  release/2016-January/003499.html

  "Don't build experimental http2 module for LTS:"
  => https://launchpad.net/ubuntu/zesty/+source/apache2/+changelog

  Ubuntu 17.04 has a support of 9 months and the http/2 code exists for
  2 years. It is no longer necessary to disable http/2.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1658469/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1559317] Re: [xenial] No write access to VirtFS (9p) in qemu VM run by libvirt

[ChristianEhrhardt]

I wasn't awake this morning it seems (or did to omuch at once), so I beg
your pardon and resummarize.

Also I had the chance to try the fs forwarding on a zestyl level
libvirt/qemu and it worked fine.

- The /srv/video rule obviously is just the case reported for a share that 
exports this source.
  That is the actual bug here that a rule for that has to be generated.

On Zesty that seems to work, for a xml entry like the following:
  
 

 
 
 
  

I got generated apparmor rules:
"/home/paelzer/work/libvirt/libvirt-upstream-git-root/**" rwl,  
   
"/home/paelzer/work/libvirt/libvirt-upstream-git-root/" r,

And it works with rw all the way (sharing a git tree shared between host
and guest).

1. So since this bug is about the rule creation it seems that exists,
needs to be identified and backported for Xenial.

2. about the report by sgofferj this morning I wonder as I have no 
fowner/fsetid denials.
   Maybe this is specific to exports based on zfs.
   @sgofferj - would you mind opening a new bug for this and attach your guest 
XML as well as a 
   description of your ZFS setup there? I want to understand and track down 
your case, but keep 
   it out of this bug here (which is about the source path not added to the 
rules)

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: libvirt (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1559317

Title:
  [xenial] No write access to VirtFS (9p) in qemu VM run by libvirt

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Confirmed

Bug description:
  Using virt-manager and libvirtd, I added a VirtFS filesystem
  passthrough to an existing qemu virtual machine also running Ubuntu.

  The XML code generated by libvirt looks like this:

  




  

  Inside the VM, I am able to mount the filesystem passthrough like
  this:

  mount -t 9p -o trans=virtio,version=9p2000.L,rw p9_mapped /mnt

  After mounting, it is possible to read the contents of the
  passthrough, but it is not possible to write into the directory. E.g.
  'touch /mnt/test' results in the error:

  touch: cannot touch ‘/mnt/test’: Permission denied

  Using the other p9 access modes 'passthrough' and 'squash' also does
  not work. Read is possible, write isn't.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: libvirt-bin 1.3.1-1ubuntu6
  ProcVersionSignature: Ubuntu 4.4.0-13.29-generic 4.4.5
  Uname: Linux 4.4.0-13-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Mar 18 22:12:34 2016
  SourcePackage: libvirt
  UpgradeStatus: Upgraded to xenial on 2016-02-06 (41 days ago)
  modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Keine 
Berechtigung: '/etc/libvirt/qemu.conf']
  modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: 
[Errno 13] Keine Berechtigung: '/etc/libvirt/qemu/networks/default.xml']

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1559317/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1677398] Re: Apparmor prevents using ZFS storage pools

[ChristianEhrhardt]

** Changed in: libvirt (Ubuntu Yakkety)
   Status: Confirmed => Won't Fix

** Changed in: libvirt (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: libvirt (Ubuntu Zesty)
 Assignee: ChristianEhrhardt (paelzer) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1677398

Title:
  Apparmor prevents using ZFS storage pools

Status in libvirt package in Ubuntu:
  In Progress
Status in libvirt source package in Xenial:
  Confirmed
Status in libvirt source package in Yakkety:
  Won't Fix
Status in libvirt source package in Zesty:
  Confirmed

Bug description:
  Apparmor prevents qemu-kvm guests from using ZFS volumes.

  [Impact]
  * ZFS storage pools are not usable.

  [Test Case]
  0) Create a zpool (system specific so not documented here)
  1) Create a ZFS storage pool (named like your zpool, "internal" here)
virsh pool-define-as internal zfs
virsh pool-start internal
  2) Create a volume
virsh vol-create-as internal foo 2G
  2) Create a KVM guest
  4) Edit the guest's XML profile to use the ZFS volume (zvol)
  



  
  5) Start the guest

  The guest refuses to start:

# virsh start nms
error: Failed to start domain foo
error: internal error: process exited while connecting to monitor: 
2017-03-29T22:07:31.507017Z qemu-system-x86_64: -drive 
file=/dev/zvol/internal/foo,format=raw,if=none,id=drive-virtio-disk0,cache=none:
 Could not open '/dev/zvol/internal/foo': Permission denied

  dmesg reveals the culprit:

  apparmor="DENIED" operation="open" 
profile="libvirt-988a8c25-5190-4762-8170-55dc75fc66ca" name="/dev/zd224" 
pid=23052 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=109 
ouid=109
  apparmor="DENIED" operation="open" 
profile="libvirt-988a8c25-5190-4762-8170-55dc75fc66ca" name="/dev/zd224" 
pid=23052 comm="qemu-system-x86" requested_mask="wr" denied_mask="wr" fsuid=109 
ouid=109

  Checking /etc/apparmor.d/libvirt/libvirt-$UUID.files shows that no
  "/dev/zdXX" has been added.

  
  [Additional info]

  # lsb_release -rd
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04

  # apt-cache policy libvirt-bin apparmor linux-image-generic
  libvirt-bin:
Installed: 1.3.1-1ubuntu10.8
Candidate: 1.3.1-1ubuntu10.8
Version table:
   *** 1.3.1-1ubuntu10.8 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   1.3.1-1ubuntu10 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  apparmor:
Installed: 2.10.95-0ubuntu2.5
Candidate: 2.10.95-0ubuntu2.5
Version table:
   *** 2.10.95-0ubuntu2.5 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.10.95-0ubuntu2 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  linux-image-generic:
Installed: 4.4.0.70.76
Candidate: 4.4.0.70.76
Version table:
   *** 4.4.0.70.76 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   4.4.0.21.22 500
  500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: libvirt-bin 1.3.1-1ubuntu10.8
  ProcVersionSignature: Ubuntu 4.4.0-70.91-generic 4.4.49
  Uname: Linux 4.4.0-70-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  Date: Wed Mar 29 17:48:06 2017
  SourcePackage: libvirt
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.default.libvirt-guests: [modified]
  modified.conffile..etc.libvirt.qemu.conf: [modified]
  modified.conffile..etc.libvirt.qemu.networks.default.xml: [modified]
  mtime.conffile..etc.default.libvirt-guests: 2016-08-29T21:09:57.632048
  mtime.conffile..etc.libvirt.qemu.conf: 2017-03-29T17:26:03.924234
  mtime.conffile..etc.libvirt.qemu.networks.default.xml: 
2016-04-23T19:24:13.505208

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1709877] Re: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1, 16-17' for 'cpuset.mems': Invalid argument"

[ChristianEhrhardt]

** Changed in: libvirt (Ubuntu Xenial)
   Status: Invalid => Triaged

** Changed in: libvirt (Ubuntu Xenial)
   Importance: Undecided => Low

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709877

Title:
  CPU hotplug fails in the system with empty numa nodes, "Invalid value
  '0-1,16-17' for 'cpuset.mems': Invalid argument"

Status in The Ubuntu-power-systems project:
  Invalid
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Triaged

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2017-07-19 
04:13:18 ==
  CPU hotplug operation fails in the host with empty numa nodes(with no memory) 
even though VM placement is static and with/without numad is running.
  ..
   32
  ...

  
  # virsh setvcpus virt-tests-vm1 6 --live
  error: Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument

  
  # numactl --hardware
  available: 4 nodes (0-1,16-17)
  node 0 cpus: 0 8 16 24 32 40
  node 0 size: 16188 MB
  node 0 free: 1119 MB
  node 1 cpus: 48 56 64 72 80 88
  node 1 size: 32630 MB
  node 1 free: 13233 MB
  node 16 cpus: 96 104 112 120 128 136
  node 16 size: 0 MB
  node 16 free: 0 MB
  node 17 cpus: 144 152 160 168 176 184
  node 17 size: 0 MB
  node 17 free: 0 MB
  node distances:
  node   0   1  16  17 
0:  10  20  40  40 
1:  20  10  40  40 
   16:  40  40  10  20 
   17:  40  40  20  10 

  # cat /sys/fs/cgroup/cpuset/cpuset.mems 
  0-1

  Host:
  #uname -a
  Linux powerkvm4-lp1 4.10.0-27-generic #30~16.04.2-Ubuntu SMP Thu Jun 29 
16:06:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  ii  libvirt-bin1.3.1-1ubuntu10.11 
  ii  numad  0.5+20150602-4 
  qemu-kvm   1:2.5+dfsg-5ubuntu10.14

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1709877/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1690730] Re: New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

[ChristianEhrhardt]

** Changed in: postgresql-9.5 (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: postgresql-9.6 (Ubuntu)
   Status: Triaged => Fix Released

** Changed in: postgresql-9.3 (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1690730

Title:
  New upstream microreleases 9.3.17, 9.5.7 and 9.6.3

Status in postgresql-9.3 package in Ubuntu:
  Fix Released
Status in postgresql-9.5 package in Ubuntu:
  Fix Released
Status in postgresql-9.6 package in Ubuntu:
  Fix Released
Status in postgresql-9.3 source package in Trusty:
  Fix Released
Status in postgresql-9.5 source package in Xenial:
  Fix Released
Status in postgresql-9.5 source package in Yakkety:
  Fix Released
Status in postgresql-9.6 source package in Zesty:
  Fix Released

Bug description:
  https://www.postgresql.org/about/news/1746/

  As per the standing micro-release exception these should land in
  stable Ubuntu releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.3/+bug/1690730/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1615722] Re: TPM driver doesn't load in qemu Windows guest

[ChristianEhrhardt]

Thanks for coming back to this Kelvin.

I must admit I lack the TPM setup and in depth knowlegde to confirm or
deny if there is still something missing, but it sounds like it - either
that or a setup issue I don't know about.

Good to hear that at least this particular bug here is fixed as assumed.
Since it is unclear how a Xenial SRU would have to be actioned I set that to 
"opinion".

For your remaining issue I'd ask you to open a new bug on launchpad against 
"qemu" not "qemu (ubuntu)".
There is too much old context in here, otherwise I'd say we just add a task for 
that project.
It is your choice which you prefer.

Before you do open that report (or add that task) you could also move to the 
current development release (Artful) which has the brand new qemu 2.10.
You'll sooner or later have to recheck with that anyway for a proper upstream 
report.

If you happen to open a new bug it would be very kind if you could
report the bug number you get here, so I can subscribe myself.

** Changed in: qemu (Ubuntu Xenial)
   Status: Incomplete => Opinion

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1615722

Title:
  TPM driver doesn't load in qemu Windows guest

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Opinion

Bug description:
  When passing through a TPM device to a qemu Windows 10 guest Windows
  will fail to initialize the TMP driver with the reason: 'device cannot
  find enough free resources'.  The bug was investigated and a patch
  provided upstream for qemu relesae 2.6 onwards.  See original bugzilla
  thread here https://bugzilla.redhat.com/show_bug.cgi?id=1281413.

  I've confirmed this bug also affects the stock qemu package (1:2.5
  +dfsg-5ubuntu10.4) in 16.04.  To resolve I built the qemu 2.6.1
  tarball and tested which solved the problem.

  My understanding is that qemu 2.6 is slated for 16.10 only, can this
  updated code be brought into the 16.04 LTS family also?

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: qemu-system-x86 1:2.5+dfsg-5ubuntu10.4
  ProcVersionSignature: Ubuntu 4.4.0-34.53-generic 4.4.15
  Uname: Linux 4.4.0-34-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Aug 22 17:08:50 2016
  InstallationDate: Installed on 2016-04-24 (119 days ago)
  InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-34-generic.efi.signed 
root=UUID=2de8fff7-85ef-4fa4-ac98-ba5118e3d3c9 ro intel_iommu=on 
intremap=no_x2apic_optout
  SourcePackage: qemu
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/17/2016
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: P2.70
  dmi.board.name: Z97 Extreme6
  dmi.board.vendor: ASRock
  dmi.chassis.asset.tag: To Be Filled By O.E.M.
  dmi.chassis.type: 3
  dmi.chassis.vendor: To Be Filled By O.E.M.
  dmi.chassis.version: To Be Filled By O.E.M.
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvrP2.70:bd05/17/2016:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnZ97Extreme6:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
  dmi.product.name: To Be Filled By O.E.M.
  dmi.product.version: To Be Filled By O.E.M.
  dmi.sys.vendor: To Be Filled By O.E.M.
  modified.conffile..etc.modprobe.d.qemu-system-x86.conf:
   options kvm_intel nested=1
  mtime.conffile..etc.modprobe.d.qemu-system-x86.conf: 
2016-08-19T21:18:23.866234

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1615722/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1689488] Re: vnc console accepts only 8 characters

[ChristianEhrhardt]

** Changed in: qemu (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1689488

Title:
  vnc console accepts only 8 characters

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Incomplete
Status in qemu source package in Yakkety:
  Won't Fix

Bug description:
  We have an issue when send message via vnc console. The vnc accepts
  only the first 8 characters.

  The issue happens on ubuntu 15.05/15.10/16.04/16.10, but does not
  exist in ubuntu 14.04 and ubuntu 17.04.

  After investigation, I found the issue is caused by commit
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=2deb4acc7c7ee770a0e0e75fd321effd916ca7df

  and fixed by commit (it is already included in qemu v2.7.0, and ubuntu 
17.04/qemu-2.8)
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c5ce83334465ee5acb6789a2f22d125273761c9e

  Can we include the fix in next minor release of qemu-2.5 for ubuntu
  16.04 ?

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1689488/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1670481] Re: Backport "populate PCI DT in reverse order" patch

[ChristianEhrhardt]

Hi,
I'm checking bugs dormant too long to update their tracking.
On this one I highly appreciate the report and the fixing we did in zesty (and 
later is done due to it being upstream) - it is ok to change that on a new 
release which zesty was.

But as outlined in comment #4 SRU'ing it would be as much chance for a
regression to some users as it would fix others.

Those affected (Like the reporter) already likely have workarounds in
place, but others could be impacted by the reverse order.

I asked to make it a more compelling case to drive the SRU in comment #7, but 
nothing happened.
Thereby "timing out" the Xenial task and setting incomplete->invalid to clear 
the view for the issues currently actionable.

If that still is a concern please provide the arguments needed for the
SRU [1] and set it back to new or confirmed.

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

P.S. Yakkety is EOL, so I set won't fix for that one

** Changed in: qemu (Ubuntu Yakkety)
   Status: Incomplete => Won't Fix

** Changed in: qemu (Ubuntu Xenial)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1670481

Title:
  Backport "populate PCI DT in reverse order" patch

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Invalid
Status in qemu source package in Yakkety:
  Won't Fix
Status in qemu source package in Zesty:
  Fix Released

Bug description:
  == Comment: #0 - MIKHAIL S. MEDVEDEV  - 2017-03-03 
14:21:43 ==
  ---Problem Description---
  On ppc64el qemu the order of device scanning was recently changed, causing 
device names to be in reverse order compared to e.g. x86. This is creating a 
need for all sorts of work arounds to make the code that assumes certain order 
of devices to work on Power.

  The fix has been proposed and it appears it would go into Qemu 2.9, see [1]. 
It might be awhile until qemu 2.9 gets widely adopted as default. It would be 
beneficial if the fix can be backported to an earlier versions of Qemu.
   
  [1] http://patchwork.ozlabs.org/patch/731061/

  ---uname output---
  Linux devstack-xenial-ppc64-84615 4.8.0-39-generic #42~16.04.1-Ubuntu SMP Mon 
Feb 20 15:09:38 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = 8247-21L 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---

   
  Contact Information = Mikhail Medvedev mmedv...@us.ibm.com / Tiago Rodrigues 
de Mello tme...@br.ibm.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1670481/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1646240] Re: qemu-image creats broken vmdk file

[ChristianEhrhardt]

Hi,
I'm currently cleaning out the tracking on dormant qemu/libvirt bugs.

On this one I'm still waiting for a check on newer vmware to make a
valid case for SRU (still reproducible) or consider it solved due to
other updates (in vmware in this case).

Lacking the feedback I'll consider the incomplete task timed out and mark it 
invalid.
Please take no offense and once the info that was asked is provided feel free 
to set back to new/confirmed.

** Changed in: qemu (Ubuntu Xenial)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1646240

Title:
  qemu-image creats broken vmdk file

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Invalid

Bug description:
  qemu-img create function produce VMDK image files with unsupported
  format option for an OVA file for importing a virtual machine into
  VMware vSphere/ESXi.

  
  VMDK file created by qemu-img failes during import with error message "Not a 
supported disk format (sparse VMDK version too old)"

  Ubuntu 16.04 LTS
  qemu version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.6)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1646240/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1589923] Re: https websockets not working in 2.5 or 2.6

[ChristianEhrhardt]

** Changed in: qemu (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1589923

Title:
  https websockets not working in 2.5 or 2.6

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Triaged
Status in qemu source package in Yakkety:
  Won't Fix
Status in Arch Linux:
  New

Bug description:
  % gdb --args ./x86_64-softmmu/qemu-system-x86_64 -vnc 
0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701 
  
  GNU gdb (GDB) 7.11
  Copyright (C) 2016 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-pc-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./x86_64-softmmu/qemu-system-x86_64...done.
  (gdb) run
  Starting program: /home/ben/qemu/qemu-2.6.0/x86_64-softmmu/qemu-system-x86_64 
-vnc 0.0.0.0:1,tls,x509=/etc/pki/libvirt-le,websocket=5701
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/usr/lib/libthread_db.so.1".
  [New Thread 0x7fffe16f6700 (LWP 12767)]
  [New Thread 0x7fffde2d4700 (LWP 12768)]
  [New Thread 0x7fffd3fff700 (LWP 12769)]
  Initializing VNC server with x509 no auth
  Client sioc=0x5874d6b0 ws=1 auth=1 subauth=0
  New client on socket 0x5874d6b0
  vnc_set_share_mode/0x5874d6b0: undefined -> connecting
  TLS Websocket connection required
  Start TLS WS handshake process
  Handshake failed TLS handshake failed: The TLS connection was non-properly 
terminated.
  Closing down client sock: protocol error
  vnc_set_share_mode/0x5779f510: connecting -> disconnected
  Client sioc=0x5873c6a0 ws=1 auth=1 subauth=0
  New client on socket 0x5873c6a0
  vnc_set_share_mode/0x5873c6a0: undefined -> connecting
  TLS Websocket connection required
  Start TLS WS handshake process
  TLS handshake complete, starting websocket handshake
  Websocket negotiate starting
  Websock handshake complete, starting VNC protocol
  Write Plain: Pending output 0x57b91c60 size 4096 offset 12. Wait SSF 0
  Wrote wire 0x57b91c60 12 -> 12

  Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
  0x0001 in ?? ()
  (gdb) thread apply all bt

  Thread 4 (Thread 0x7fffd3fff700 (LWP 12769)):
  #0  0x7fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from 
/usr/lib/libpthread.so.0
  #1  0x55a20bd9 in qemu_cond_wait (cond=cond@entry=0x587267e0, 
  mutex=mutex@entry=0x58726810) at util/qemu-thread-posix.c:123
  #2  0x559770ab in vnc_worker_thread_loop 
(queue=queue@entry=0x587267e0)
  at ui/vnc-jobs.c:228
  #3  0x559775e8 in vnc_worker_thread (arg=0x587267e0) at 
ui/vnc-jobs.c:335
  #4  0x7fffef354474 in start_thread () from /usr/lib/libpthread.so.0
  #5  0x7fffea43c69d in clone () from /usr/lib/libc.so.6

  Thread 3 (Thread 0x7fffde2d4700 (LWP 12768)):
  #0  0x7fffef35a09f in pthread_cond_wait@@GLIBC_2.3.2 () from 
/usr/lib/libpthread.so.0
  #1  0x55a20bd9 in qemu_cond_wait (cond=, 
  ---Type  to continue, or q  to quit---
  emu_global_mutex>) at util/qemu-thread-posix.c:123
  #2  0x55715edf in qemu_tcg_wait_io_event (cpu=0x564ee840) at 
/home/ben/qemu/qemu-2.6.0/cpus.c:1015
  #3  qemu_tcg_cpu_thread_fn (arg=) at 
/home/ben/qemu/qemu-2.6.0/cpus.c:1161
  #4  0x7fffef354474 in start_thread () from /usr/lib/libpthread.so.0
  #5  0x7fffea43c69d in clone () from /usr/lib/libc.so.6

  Thread 2 (Thread 0x7fffe16f6700 (LWP 12767)):
  #0  0x7fffea438229 in syscall () from /usr/lib/libc.so.6
  #1  0x55a20ee8 in futex_wait (val=, ev=) at util/qemu-thread-posix.c:292
  #2  qemu_event_wait (ev=ev@entry=0x5641ece4 ) at 
util/qemu-thread-posix.c:399
  #3  0x55a2f2ae in call_rcu_thread (opaque=) at 
util/rcu.c:250
  #4  0x7fffef354474 in start_thread () from /usr/lib/libpthread.so.0
  #5  0x7fffea43c69d in clone () from /usr/lib/libc.so.6

  Thread 1 (Thread 0x77f5bb00 (LWP 12763)):
  #0  0x0001 in ?? ()
  #1  0x559efb53 in qio_task_free (task=0x58212140) at io/task.c:58
  #2  0x559efd89 in qio_task_complete (task=task@entry=0x58212140) 
at io/task.c:145
  #3  0x559ef5aa in qio_c

[Group.of.nepali.translators] [Bug 1709877] Re: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1, 16-17' for 'cpuset.mems': Invalid argument"

[ChristianEhrhardt]

Lacking feedback on how real the case is to make a compelling SRU statement for 
the SRU Team.
Please see my comment #4 and reply with the details needed to make a SRU 
possible.

Until that was provided I set this back from incomplete to invalid (no
offense, consider it a timeout on the "incomplete" to clear the view for
currently actionable items), please set back to new once the data was
provided.

** Changed in: libvirt (Ubuntu Xenial)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709877

Title:
  CPU hotplug fails in the system with empty numa nodes, "Invalid value
  '0-1,16-17' for 'cpuset.mems': Invalid argument"

Status in The Ubuntu-power-systems project:
  Incomplete
Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Invalid

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2017-07-19 
04:13:18 ==
  CPU hotplug operation fails in the host with empty numa nodes(with no memory) 
even though VM placement is static and with/without numad is running.
  ..
   32
  ...

  
  # virsh setvcpus virt-tests-vm1 6 --live
  error: Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument

  
  # numactl --hardware
  available: 4 nodes (0-1,16-17)
  node 0 cpus: 0 8 16 24 32 40
  node 0 size: 16188 MB
  node 0 free: 1119 MB
  node 1 cpus: 48 56 64 72 80 88
  node 1 size: 32630 MB
  node 1 free: 13233 MB
  node 16 cpus: 96 104 112 120 128 136
  node 16 size: 0 MB
  node 16 free: 0 MB
  node 17 cpus: 144 152 160 168 176 184
  node 17 size: 0 MB
  node 17 free: 0 MB
  node distances:
  node   0   1  16  17 
0:  10  20  40  40 
1:  20  10  40  40 
   16:  40  40  10  20 
   17:  40  40  20  10 

  # cat /sys/fs/cgroup/cpuset/cpuset.mems 
  0-1

  Host:
  #uname -a
  Linux powerkvm4-lp1 4.10.0-27-generic #30~16.04.2-Ubuntu SMP Thu Jun 29 
16:06:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  ii  libvirt-bin1.3.1-1ubuntu10.11 
  ii  numad  0.5+20150602-4 
  qemu-kvm   1:2.5+dfsg-5ubuntu10.14

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1709877/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1709224] Re: libvirt lxc can't stop all process when destroy vm.

[ChristianEhrhardt]

Hi, sorry but since I can't reproduce (even without the ppa to test) I can't 
continue on a fix for now.
Please come back once you found the time to check 
1. the ppa I provided for your case (since there are newer versions you need to 
force install that version from the ppa [1])
2. On the error case as I outlined it doesn't reproduce for me, please describe 
your case more in Detail and provide the full console log while it triggers. 
(We will need the steps to reproduce anyway if we eventually want to push to 
Xenial via SRU)

Until then I consider this timed out and set invalid, please set back to
new once you found the time to provide the extra data.

[1]: https://askubuntu.com/questions/92019/how-to-install-specific-
ubuntu-packages-with-exact-version

** Changed in: libvirt (Ubuntu Xenial)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709224

Title:
  libvirt lxc  can't stop all process when destroy vm.

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Invalid

Bug description:
  Environments:
  System: zesty
  libvirt version: 2.5.0-3ubuntu5
  vm rootfs release: ubuntu:16.04

  Reproduce:
  1. Run command "virsh -c lxc:// start vm" and the release of vm is xenial
  2. Run command "pa aux|grep init" ,you would find the pid of init launch by 
vm.
  3. Run command "virsh -c lxc:// destroy vm".
  4. Run command "virsh -c lxc:// list --all" and "ps aux|grep init" ,you could 
find that vm is shutoff, but the init process launch by vm is still running.

  Infact I have found the case of this bug, there is a patch after 1.3.1
  that import this bug.

  -
  Commit: dc576025c360a1d2c89da410d0f3f0da55d0143f [dc57602]
  Parents: 511e7c5bba
  Author: Daniel P. Berrange 
  Date: 2016年1月23日 GMT+8 上午12:07:18
  Commit Date: 2016年1月27日 GMT+8 上午12:11:32
  lxc: don't try to hide parent cgroups inside container
  -

  Cgroups inside container does't hide parent, so the process of container can 
change it own cgroup to  another cgroup.
  lxc destroy process by read cgroup tasks file,if process change it own 
cgroup,it can't destroy container process normally.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709224/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1621121] Re: VM fails to start when vcpu placement='auto'

[ChristianEhrhardt]

I'm passing through old bugs, lacking further discussion and any
"forcing" argument why that would be needed in Xenial (which would be
feature enablement in SRU, so that would have to be a very good
argument) I'm closing the Xenial task to clean up.

Also if needed users have the option to get this in Xenial by using the
Cloud-Archive Ocata or Pike.

** Changed in: libvirt (Ubuntu Xenial)
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1621121

Title:
  VM fails to start when vcpu placement='auto'

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Won't Fix

Bug description:
  ---Problem Description---
  VM fails to start when vcpu placement='auto'
   
  ---uname output---
  Linux ltc-test-ci1 4.4.0-9134-generic #53-Ubuntu SMP Thu Aug 18 05:21:43 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = power 8 ppc64le 

  ---Steps to Reproduce---

  1. Define the VM with xml attached
  virsh define vm.xml
  2. Start the VM
  virsh start virt-tests-vm1
  error: Failed to start domain virt-tests-vm1
  error: unsupported configuration: numad is not available on this host

   
  Userspace tool common name: ii  libvirt-bin  
2.1.0-1ubuntu3  ppc64el  programs for the libvirt 
library 
   
  The userspace tool has the following bit modes: both 

  Userspace rpm: ii  libvirt-bin  2.1.0-1ubuntu3
  ppc64el  programs for the libvirt library

  
  ii  numad0.5+20150602-4  
ppc64el  User-level daemon that monitors NUMA topology and usage

  attached debug log by enabling flag, export LIBVIRT_DEBUG=1

  Not much info on qemu vm log
  cat libvirt/qemu/virt-tests-vm1.log
  2016-08-29 16:09:19.092+: shutting down
  2016-08-29 16:16:08.378+: shutting down
  2016-08-29 16:16:37.811+: shutting down
  2016-08-29 16:16:45.579+: shutting down
  2016-08-30 05:35:21.199+: shutting down
  2016-08-30 05:40:28.999+: shutting down
  2016-08-30 05:41:15.155+: shutting down
  2016-08-30 05:44:04.427+: shutting down
  2016-08-30 05:44:16.099+: shutting down
  2016-08-30 05:49:12.327+: shutting down
  2016-08-30 05:53:19.455+: shutting down
  2016-08-30 05:53:56.171+: shutting down

  
  service numad status
  ? numad.service - numad - The NUMA daemon that manages application locality.
 Loaded: loaded (/lib/systemd/system/numad.service; enabled; vendor preset: 
enabled)
 Active: active (running) since Mon 2016-08-22 04:12:30 CDT; 1 weeks 0 days 
ago
   Docs: man:numad
   Main PID: 3563 (numad)
  Tasks: 2 (limit: 12288)
 Memory: 1.5M
CPU: 6min 43.046s
 CGroup: /system.slice/numad.service
 ??3563 /usr/bin/numad -i 15

  Aug 22 04:12:29 ltc-test-ci1 systemd[1]: Starting numad - The NUMA daemon 
that manages application locality
  Aug 22 04:12:30 ltc-test-ci1 systemd[1]: Started numad - The NUMA daemon that 
manages application locality..

  looks more like a configuration issue, suspecting that libvirt package
  is configured without numa support

  Can Canonical confirm if the libvirt package provides numa support?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1621121/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1571209] Re: Sockfile check retries too short for a busy system boot

[ChristianEhrhardt]

Changed the order of status and list to get it even better while testing on 
Xenial.
Also the system was even slower which is good I think (for the test).

So things are good on Xenial onward (with systemd).

$ sudo ./test-restart.sh 
+ date
Mi 6. Sep 09:03:35 UTC 2017
+ sudo systemctl start libvirtd
+ date
Mi 6. Sep 09:03:36 UTC 2017
+ /bin/true
+ ls -laF /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirtd 0 Sep   6 09:03 /var/run/libvirt/libvirt-sock=
+ sudo systemctl status libvirtd --no-pager
* libvirt-bin.service - Virtualization daemon
   Loaded: loaded (/lib/systemd/system/libvirt-bin.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Mi 2017-09-06 09:03:36 UTC; 48ms ago
 Docs: man:libvirtd(8)
   http://libvirt.org
 Main PID: 261895 (libvirtd)
Tasks: 20
   Memory: 30.5M
  CPU: 75ms
   CGroup: /system.slice/libvirt-bin.service
   |-  3932 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_...
   |-  3933 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_...
   |-261895 /usr/sbin/libvirtd
   `-261913 /usr/sbin/libvirtd

Sep 06 09:03:35 s1lp04 systemd[1]: Starting Virtualization daemon...
Sep 06 09:03:36 s1lp04 systemd[1]: Started Virtualization daemon.
+ virsh list
 IdName   State

 1 artful-test2   running
 2 artful-test13  running
 3 artful-test27  running
 4 artful-test28  running
 5 artful-test17  running
 6 artful-test26  running
 7 artful-test25  running
 8 artful-test20  running
 9 artful-test21  running
 10artful-test11  running
 11artful-test23  running
 12artful-test16  running
 13artful-test10  running
 14artful-test30  running
 15artful-test8   running
 16artful-test18  running
 17artful-test5   running
 18artful-test3   running
 19artful-test4   running
 20artful-test12  running
 21artful-test24  running
 22artful-test9   running
 23artful-test14  running
 24artful-test19  running
 25artful-test1   running
 26artful-test15  running
 27artful-test29  running
 28artful-test6   running
 29artful-test7   running
 30artful-test22  running

+ date
Mi 6. Sep 09:04:55 UTC 2017
+ sleep 2s

** Changed in: libvirt (Ubuntu Xenial)
   Status: Incomplete => Fix Released

** Changed in: libvirt (Ubuntu Zesty)
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1571209

Title:
  Sockfile check retries too short for a busy system boot

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Precise:
  Won't Fix
Status in libvirt source package in Trusty:
  Incomplete
Status in libvirt source package in Wily:
  Won't Fix
Status in libvirt source package in Xenial:
  Fix Released
Status in libvirt source package in Zesty:
  Fix Released
Status in libvirt source package in Artful:
  Fix Released

Bug description:
  [ problem description ]

  sockfile_check_retries is first introduced by #1455608, for preventing
  the failure case of sockfile not ready, but it was default to a hard-
  coded value "5", it might be too short for a busy system boot.

  #1455608 -
  https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1455608

  
  [ step to reproduce ]

  setup a clean install system (Ubuntu Server 14.04.4 LTS), and assemble
  os disk as RAID-1, boot up some guest instances (count > 10, start-at-
  boot), force shutdown host by pressing power-button for 3s ~ 5s, or
  via IPMI command, then power-on afterward. it may sometimes failed to
  get sockfile ready after in "post-start" script, with an line of error
  in /var/log/syslog,

  ==> kernel: [ 313.059830] init: libvirt-bin post-start process (2430)
  terminated with status 1 <==

  since there's multiple VMs Read/Write before a non-graceful shutdown,
  RAID devices need to re-sync after boot, and lead to a slow response,
  but start-up script for libvirt-bin can only wait 5 cycles, 2 seconds
  wait for each cycle, so it will timed-out after 10s, and exit with
  "1".

  
  [ possible solution ]

  extend the retry times for sockfile waiting,

[Group.of.nepali.translators] [Bug 1571209] Re: Sockfile check retries too short for a busy system boot

[ChristianEhrhardt]

To check on the systemd case I picked a rather slow system and spawned 30 
guests.
I set all those to autostart and then shut them down.

Starting them sequentially as well as concurrently takes about ~20
seconds.

/var/run/libvirt/libvirt-sock is gone after the service is stopped.

With the following script this can be tested:
$ cat test-restart.sh 
#!/bin/bash
set -uxe
date
sudo systemctl start libvirtd
date
# right after start (1-2 seconds usually) check status of sockets and guests
while /bin/true; do
ls -laF /var/run/libvirt/libvirt-sock
virsh list
sudo systemctl status libvirtd --no-pager
date
sleep 2s
done

You will see that the "virsh list" is kind of blocking until other internal 
tasks are done.
That pretty much ends up after the ~20 seconds that I counted until it goes on.
All guests are started then and things are good.
But the socket is available right after start, yet if you do a request you are 
enqueued and have to wait - which is fine.

Output:
$ ./test-restart.sh  
+ date
Mi 6. Sep 04:40:34 EDT 2017
+ sudo systemctl start libvirtd
+ date
Mi 6. Sep 04:40:34 EDT 2017
+ /bin/true
+ ls -laF /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirtd 0 Sep  6 04:40 /var/run/libvirt/libvirt-sock=
+ virsh list
 IdName   State

 1 artful-test30  running
 2 artful-test9   running
 3 artful-test8   running
 4 artful-test23  running
 5 artful-test13  running
 6 artful-test19  running
 7 artful-test11  running
 8 artful-test15  running
 9 artful-test10  running
 10artful-test17  running
 11artful-test5   running
 12artful-test24  running
 13artful-test26  running
 14artful-test20  running
 15artful-test2   running
 16artful-test29  running
 17artful-test22  running
 18artful-test27  running
 19artful-test14  running
 20artful-test6   running
 21artful-test25  running
 22artful-test12  running
 23artful-test3   running
 24artful-test21  running
 25artful-test7   running
 26artful-test16  running
 27artful-test28  running
 28artful-test18  running
 29artful-test1   running
 30artful-test4   running

+ sudo systemctl status libvirtd --no-pager
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Wed 2017-09-06 04:40:34 EDT; 23s ago
 Docs: man:libvirtd(8)
   http://libvirt.org
 Main PID: 171137 (libvirtd)
Tasks: 303 (limit: 32768)
   Memory: 93.7M
  CPU: 15.383s
   CGroup: /system.slice/libvirtd.service
   ├─  3848 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_…er
   ├─  3849 /usr/sbin/dnsmasq 
--conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro 
--dhcp-script=/usr/lib/libvirt/libvirt_…er
   ├─171137 /usr/sbin/libvirtd
   ├─171530 qemu-system-s390x -enable-kvm -name 
guest=artful-test30,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─171640 qemu-system-s390x -enable-kvm -name 
guest=artful-test9,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/v…on
   ├─171789 qemu-system-s390x -enable-kvm -name 
guest=artful-test8,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/v…on
   ├─171897 qemu-system-s390x -enable-kvm -name 
guest=artful-test23,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─171970 qemu-system-s390x -enable-kvm -name 
guest=artful-test13,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─172041 qemu-system-s390x -enable-kvm -name 
guest=artful-test19,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─172116 qemu-system-s390x -enable-kvm -name 
guest=artful-test11,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─172196 qemu-system-s390x -enable-kvm -name 
guest=artful-test15,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─172273 qemu-system-s390x -enable-kvm -name 
guest=artful-test10,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
   ├─172348 qemu-system-s390x -enable-kvm -name 
guest=artful-test17,debug-threads=on -S -object 
secret,id=masterKey0,format=raw,file=/…on
 

[Group.of.nepali.translators] [Bug 1571209] Re: Sockfile check retries too short for a busy system boot

[ChristianEhrhardt]

This bug was dead for quite some time, but the issue still exists for Trusty 
(were we could take the supposed change) and we have to check the systemd cases 
in >=Xenial.
Adapting tasks and will come back once I tested on >=Xenial.

** Also affects: libvirt (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Artful)
   Importance: High
 Assignee: Serge Hallyn (serge-hallyn)
   Status: Fix Released

** Changed in: libvirt (Ubuntu Artful)
   Status: Fix Released => Incomplete

** Changed in: libvirt (Ubuntu Zesty)
   Status: New => Incomplete

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Incomplete

** Changed in: libvirt (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Precise)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Artful)
 Assignee: Serge Hallyn (serge-hallyn) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1571209

Title:
  Sockfile check retries too short for a busy system boot

Status in libvirt package in Ubuntu:
  Incomplete
Status in libvirt source package in Precise:
  Won't Fix
Status in libvirt source package in Trusty:
  Triaged
Status in libvirt source package in Wily:
  Won't Fix
Status in libvirt source package in Xenial:
  Incomplete
Status in libvirt source package in Zesty:
  Incomplete
Status in libvirt source package in Artful:
  Incomplete

Bug description:
  [ problem description ]

  sockfile_check_retries is first introduced by #1455608, for preventing
  the failure case of sockfile not ready, but it was default to a hard-
  coded value "5", it might be too short for a busy system boot.

  #1455608 -
  https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1455608

  
  [ step to reproduce ]

  setup a clean install system (Ubuntu Server 14.04.4 LTS), and assemble
  os disk as RAID-1, boot up some guest instances (count > 10, start-at-
  boot), force shutdown host by pressing power-button for 3s ~ 5s, or
  via IPMI command, then power-on afterward. it may sometimes failed to
  get sockfile ready after in "post-start" script, with an line of error
  in /var/log/syslog,

  ==> kernel: [ 313.059830] init: libvirt-bin post-start process (2430)
  terminated with status 1 <==

  since there's multiple VMs Read/Write before a non-graceful shutdown,
  RAID devices need to re-sync after boot, and lead to a slow response,
  but start-up script for libvirt-bin can only wait 5 cycles, 2 seconds
  wait for each cycle, so it will timed-out after 10s, and exit with
  "1".

  
  [ possible solution ]

  extend the retry times for sockfile waiting, and make it possible to
  change via editing `/etc/default/libvirt-bin` file.

  

  
  [ sysinfo ]

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description: Ubuntu 14.04.4 LTS
  Release: 14.04
  Codename: trusty

  $ uname -a
  Linux host2 4.2.0-35-generic #40~14.04.1-Ubuntu SMP Fri Mar 18 16:37:35 UTC 
2016 x86_64 x86_64 x86_64 GNU/Linux

  
  [ related issue ]

  #1386465 -
  https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1386465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1571209/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1561019] Re: copied cpu flags don't match host cpu

[ChristianEhrhardt]

Given the (no) feedback and the fact that this actually is not part of
the virt cpu the old request is won't fix. Furthermore I spawned a task
to remove the patches that did add it in the past.

TL;DR:
- intentionally not enabled/added upstream
- long gone with a very low amount of people missing it
- still (and in future) available as opt-in by changing the config as outlined 
in comment #15
- will remove (disfunctional) related delta on next merge

** Changed in: libvirt (Ubuntu)
   Status: Incomplete => Won't Fix

** Changed in: libvirt (Ubuntu Wily)
   Status: New => Won't Fix

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1561019

Title:
  copied cpu flags don't match host cpu

Status in libvirt:
  Unknown
Status in libvirt package in Ubuntu:
  Won't Fix
Status in libvirt source package in Wily:
  Won't Fix
Status in libvirt source package in Xenial:
  Won't Fix

Bug description:
  Using wily (libvirt 1.2.16-2ubuntu11.15.10.3) in a AMD FX-8350 nested
  KVM doesn't work, unless in the definition of the vm the cpu is
  configured with  mode='host-passthrough', for other CPUs the
  manifestation could be different.

  Steps to reproduce:

  L0: wily

  $ uvt-kvm create --memory 2048 --cpu 2 vm-L1 release=wily arch=amd64  # the 
L1 guest can be trusty too, it doesn't really matter
  $ uvt-kvm ssh --insecure vm-L1
  (vm-L1)$ sudo apt-get install cpu-checker
  (vm-L1)$ sudo kvm-ok
  INFO: Your CPU does not support KVM extensions
  KVM acceleration can NOT be used
  (vm-L1)$ sudo modprobe kvm-amd
  modprobe: ERROR: could not insert 'kvm_amd': Operation not supported
  (vm-L1)$ dmesg | grep kvm | tail -n1
  [45890.075592] kvm: no hardware support

  Expected Result:

  kvm-ok says that virtualization is supported

  
  Workaround:

  1) Shutdown the VM (vm-L1)
  2) In the kvm host edit vm-L1 definition (sudo virsh edit vm-L1) and change 
the cpu definition to:

  3) power on the VM

  
  ProblemType: Bug
  DistroRelease: Ubuntu 15.10
  Package: libvirt-bin 1.2.16-2ubuntu11.15.10.3
  ProcVersionSignature: Ubuntu 4.2.0-34.39-generic 4.2.8-ckt4
  Uname: Linux 4.2.0-34-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.19.1-0ubuntu5
  Architecture: amd64
  Date: Wed Mar 23 11:20:11 2016
  InstallationDate: Installed on 2014-12-06 (472 days ago)
  InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
  SourcePackage: libvirt
  UpgradeStatus: Upgraded to wily on 2016-03-08 (14 days ago)
  modified.conffile..etc.apparmor.d.usr.lib.libvirt.virt.aa.helper: [modified]
  modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] 
Permission denied: '/etc/libvirt/qemu.conf']
  modified.conffile..etc.libvirt.qemu.networks.default.xml: [inaccessible: 
[Errno 13] Permission denied: '/etc/libvirt/qemu/networks/default.xml']
  mtime.conffile..etc.apparmor.d.usr.lib.libvirt.virt.aa.helper: 
2016-03-14T13:22:07.751461

To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/1561019/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1706818] Re: mismatched file locking since 1:4.2.8p4+dfsg-3ubuntu1 causes race leaving ntp dead on reboot

[ChristianEhrhardt]

Removing the last uncertainties, the related Debian bug being fixed fixed it in 
sysv init.
That now has:
 LOCKFILE=/run/lock/ntpdate

It has so e.g. in Artful.

And thereby we considered being fixed as well after merging that.
But versions >= that also have the systemd wrapper which doesn't lock at all.

Need to check Zesty if that might have no systemd wrapper yet but fixed 
sysv-init only.
...
Yep as I thought it really was fixed in Zesty by not (yet) having the systemd 
wrapper.

** Also affects: ntp (Ubuntu Artful)
   Importance: Undecided
   Status: Confirmed

** Also affects: ntp (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Changed in: ntp (Ubuntu Zesty)
   Status: New => Fix Released

** Changed in: ntp (Ubuntu Artful)
   Importance: Undecided => Critical

** Changed in: ntp (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1706818

Title:
  mismatched file locking since 1:4.2.8p4+dfsg-3ubuntu1 causes race
  leaving ntp dead on reboot

Status in ntp package in Ubuntu:
  Confirmed
Status in ntp source package in Xenial:
  Confirmed
Status in ntp source package in Zesty:
  Fix Released
Status in ntp source package in Artful:
  Confirmed
Status in ntp package in Debian:
  Fix Released

Bug description:
  ntpdate and ntp conflict on the NTP well-known-socket. If ntp and
  ntpdate 1:4.2.8p4+dfsg-3ubuntu5.5 are installed on Xenial, and there
  are 2 static interfaces configured, most often we find that ntpd is
  not running after a reboot.

  When the ntp service is started by systemd, ntp fails to bind the NTP
  socket because ntpdate is running in the background. It's intended
  that ntp and ntpdate try to avoid this conflict with a lock file, but
  the locking mechanism was changed in ntpdate.if-up (from lockfile to
  flock), but it was not changed in ntp.init. Previously the file
  locking prevented ntp from trying to start when ntpdate was running.
  Not any more.

  Having multiple interfaces causes a much longer period of the socket
  being unavailable, because the 2 ntpdate processes will get serialized
  by the lock, while the ntp service is looking for a different lock, so
  it just plows right in.  Attempts by netdate.if-up to stop and start
  ntp seem to overlap and when the final start is invoked, systemd seems
  to thing ntp is already running, though it has failed.

  In 1:4.2.8p4+dfsg-3ubuntu1 the following change was made:
debian/ntpdate.if-up: Drop lockfile mechanism as upstream is using flock 
now.
  Looks like corresponds to rev 371 of debian/ntpdate.if-up from upstream.

  This change diverged locking between ntpdate.if-up and ntp.init. This
  was rectified in rev 451 of ntp.init, to use compatible locking, but
  that doesn't appear in the Ubuntu version.

  
  System Information:

   lsb_release -rd:
 Description:Ubuntu 16.04.2 LTS
 Release:16.04

  
   apt-cache policy ntpdate:

 ntpdate:
   Installed: 1:4.2.8p4+dfsg-3ubuntu5.5
   Candidate: 1:4.2.8p4+dfsg-3ubuntu5.5
   Version table:
  *** 1:4.2.8p4+dfsg-3ubuntu5.5 100
 100 /var/lib/dpkg/status

   apt-cache policy ntp:

 ntp:
   Installed: 1:4.2.8p4+dfsg-3ubuntu5.5
   Candidate: 1:4.2.8p4+dfsg-3ubuntu5.5
   Version table:
  *** 1:4.2.8p4+dfsg-3ubuntu5.5 100
 100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1706818/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1706818] Re: mismatched file locking since 1:4.2.8p4+dfsg-3ubuntu1 causes race leaving ntp dead on reboot

[ChristianEhrhardt]

- Taking a Xenial and a Artful VM
- Installing ntp
- Check status of ntp
  - running fine on both systems
- Reboot the VM
- Check status of ntp
  - still ntp service ok on both systems
- install ntpdate
- Check status of ntp
  - still ntp service ok on both systems
- reboot
- Check status of ntp
  - failed for blocked known address being busy on both
- reboot (to check reproducibility)
- Check status of ntp
  - failed for blocked known address being busy on both
- Adding two extra devices in libvirt and configuring it on the guest
- restart
- Check status of ntp
  - failed for blocked known address being busy on both (likely even at a 
higher "risk")

ntp init mechanims:
Xenial: /etc/init.d/ntp locks LOCKFILE=/var/lock/ntpdate
Artful: /usr/lib/ntp/ntp-systemd-wrapper locks nothing at all

This races against the following hook (in both releases):
/etc/network/if-up.d/ntpdate which locks /run/lock/ntpdate

Seems reproducible enough to me, actually much better reproducible than in the 
past.
I checked and our recent cleanup of the mess around debian/ntpdate.if-up fixed 
a lot of things.
Among other it removed an accidential restart of ntp which kind of hid this 
issue here (no regression-update, just an issue existing before now more likely 
to be hit).

But now with things no more that racy the fix is easy and much better
testable.

** Changed in: ntp (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: ntp (Ubuntu)
   Status: Fix Released => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1706818

Title:
  mismatched file locking since 1:4.2.8p4+dfsg-3ubuntu1 causes race
  leaving ntp dead on reboot

Status in ntp package in Ubuntu:
  Confirmed
Status in ntp source package in Xenial:
  Confirmed
Status in ntp source package in Zesty:
  Fix Released
Status in ntp source package in Artful:
  Confirmed
Status in ntp package in Debian:
  Fix Released

Bug description:
  ntpdate and ntp conflict on the NTP well-known-socket. If ntp and
  ntpdate 1:4.2.8p4+dfsg-3ubuntu5.5 are installed on Xenial, and there
  are 2 static interfaces configured, most often we find that ntpd is
  not running after a reboot.

  When the ntp service is started by systemd, ntp fails to bind the NTP
  socket because ntpdate is running in the background. It's intended
  that ntp and ntpdate try to avoid this conflict with a lock file, but
  the locking mechanism was changed in ntpdate.if-up (from lockfile to
  flock), but it was not changed in ntp.init. Previously the file
  locking prevented ntp from trying to start when ntpdate was running.
  Not any more.

  Having multiple interfaces causes a much longer period of the socket
  being unavailable, because the 2 ntpdate processes will get serialized
  by the lock, while the ntp service is looking for a different lock, so
  it just plows right in.  Attempts by netdate.if-up to stop and start
  ntp seem to overlap and when the final start is invoked, systemd seems
  to thing ntp is already running, though it has failed.

  In 1:4.2.8p4+dfsg-3ubuntu1 the following change was made:
debian/ntpdate.if-up: Drop lockfile mechanism as upstream is using flock 
now.
  Looks like corresponds to rev 371 of debian/ntpdate.if-up from upstream.

  This change diverged locking between ntpdate.if-up and ntp.init. This
  was rectified in rev 451 of ntp.init, to use compatible locking, but
  that doesn't appear in the Ubuntu version.

  
  System Information:

   lsb_release -rd:
 Description:Ubuntu 16.04.2 LTS
 Release:16.04

  
   apt-cache policy ntpdate:

 ntpdate:
   Installed: 1:4.2.8p4+dfsg-3ubuntu5.5
   Candidate: 1:4.2.8p4+dfsg-3ubuntu5.5
   Version table:
  *** 1:4.2.8p4+dfsg-3ubuntu5.5 100
 100 /var/lib/dpkg/status

   apt-cache policy ntp:

 ntp:
   Installed: 1:4.2.8p4+dfsg-3ubuntu5.5
   Candidate: 1:4.2.8p4+dfsg-3ubuntu5.5
   Version table:
  *** 1:4.2.8p4+dfsg-3ubuntu5.5 100
 100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1706818/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1713979] Re: New upstream microreleases 9.3.19, 9.5.9 and 9.6.5

[ChristianEhrhardt]

This bug was fixed in the package postgresql-9.6 - 9.6.5-1

---
postgresql-9.6 (9.6.5-1) unstable; urgency=medium

  * Team upload.
  * New upstream version.

 -- Christoph Berg   Tue, 29 Aug 2017
12:15:37 +0200

** Changed in: postgresql-9.6 (Ubuntu)
   Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1713979

Title:
  New upstream microreleases 9.3.19, 9.5.9 and 9.6.5

Status in postgresql-9.3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-9.6 package in Ubuntu:
  Fix Released
Status in postgresql-9.3 source package in Trusty:
  In Progress
Status in postgresql-9.5 source package in Xenial:
  In Progress
Status in postgresql-9.6 source package in Zesty:
  In Progress
Status in postgresql-9.6 source package in Artful:
  Fix Released

Bug description:
  Update to the new set of releases as per the standing micro-release
  exception these should land in stable Ubuntu releases.

  Curren versions in releases:
   postgresql-9.3 | 9.3.18-0ubuntu0.14.04.1 | trusty-security | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el
   postgresql-9.5 | 9.5.8-0ubuntu0.16.04.1 | xenial-security | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el, s390x
   postgresql-9.6 | 9.6.4-0ubuntu0.17.04.1 | zesty-security | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
   postgresql-9.6 | 9.6.4-1| artful | source, amd64, 
arm64, armhf, i386, ppc64el, s390x

  This was a double bump within 2 weeks.
  As the last had upgrade regressions.
  But the Security Team already did the Bump on the latest so we effectively 
have
  the potential upgrade regression in the field and need to bump again.

  Last stable updates
  PostgreSQL 9.6.5, 9.5.9, 9.4.14, 9.3.19, 9.2.23

  So the todo is to pick:
  MRE: Trusty 9.3.19 from https://www.postgresql.org/ftp/source/v9.3.19/
  MRE: Xenial 9.5.9 from https://www.postgresql.org/ftp/source/v9.5.9/
  MRE: Zesty 9.6.5 from https://www.postgresql.org/ftp/source/v9.6.5/
  Sync: Artful 9.6.5 from https://www.postgresql.org/ftp/source/v9.6.5/

  Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/postgresql-9.3/+bug/1713979/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1576471] Re: broken link to raphael.min.js and missing settings in conf file

[ChristianEhrhardt]

** Also affects: nzbget (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: raphael (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: nzbget (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: raphael (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: nzbget (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: raphael (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Changed in: nzbget (Ubuntu Trusty)
   Status: New => Won't Fix

** Changed in: nzbget (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: nzbget (Ubuntu Zesty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1576471

Title:
  broken link to raphael.min.js and missing settings in conf file

Status in nzbget package in Ubuntu:
  Fix Released
Status in raphael package in Ubuntu:
  In Progress
Status in nzbget source package in Trusty:
  Won't Fix
Status in raphael source package in Trusty:
  New
Status in nzbget source package in Xenial:
  Won't Fix
Status in raphael source package in Xenial:
  New
Status in nzbget source package in Zesty:
  Won't Fix
Status in raphael source package in Zesty:
  New

Bug description:
  After a fresh install on 16.04 the symbolic link
  /usr/share/nzbget/webui/lib/raphael.min.js points a broken link. it
  *should* point to ../../../javascript/raphael/raphael-min.js

  also, the default conf file /usr/share/nzbget/webui/nzbget.conf does
  not have certain required settings set like WebDir and ConfigTemplate

  also, this can be used as the systemd file
  /etc/systemd/system/nzbget.service

  [Unit]
  Description=NZBGet Daemon
  Documentation=http://nzbget.net/Documentation
  After=network.target

  [Service]
  User=media
  Group=media
  Type=forking
  ExecStart=/usr/bin/nzbget -c /home/media/.nzbget.conf -D
  ExecStop=/usr/bin/nzbget -Q
  ExecReload=/usr/bin/nzbget -O
  KillMode=process
  Restart=on-failure

  [Install]
  WantedBy=multi-user.target

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nzbget/+bug/1576471/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1713979] [NEW] New upstream microreleases 9.3.19, 9.5.9 and 9.6.5

[ChristianEhrhardt]

Public bug reported:

Update to the new set of releases as per the standing micro-release
exception these should land in stable Ubuntu releases.

Curren versions in releases:
 postgresql-9.3 | 9.3.18-0ubuntu0.14.04.1 | trusty-security | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el
 postgresql-9.5 | 9.5.8-0ubuntu0.16.04.1 | xenial-security | source, amd64, 
arm64, armhf, i386, powerpc, ppc64el, s390x
 postgresql-9.6 | 9.6.4-0ubuntu0.17.04.1 | zesty-security | source, amd64, 
arm64, armhf, i386, ppc64el, s390x
 postgresql-9.6 | 9.6.4-1| artful | source, amd64, 
arm64, armhf, i386, ppc64el, s390x

This was a double bump within 2 weeks.
As the last had upgrade regressions.
But the Security Team already did the Bump on the latest so we effectively have
the potential upgrade regression in the field and need to bump again.

Last stable updates
PostgreSQL 9.6.5, 9.5.9, 9.4.14, 9.3.19, 9.2.23

So the todo is to pick:
MRE: Trusty 9.3.19 from https://www.postgresql.org/ftp/source/v9.3.19/
MRE: Xenial 9.5.9 from https://www.postgresql.org/ftp/source/v9.5.9/
MRE: Zesty 9.6.5 from https://www.postgresql.org/ftp/source/v9.6.5/
Sync: Artful 9.6.5 from https://www.postgresql.org/ftp/source/v9.6.5/

Consider last updates as template:
- pad.lv/1637236
- pad.lv/1664478
- pad.lv/1690730

** Affects: postgresql-9.3 (Ubuntu)
 Importance: Undecided
 Status: Invalid

** Affects: postgresql-9.5 (Ubuntu)
 Importance: Undecided
 Status: Invalid

** Affects: postgresql-9.6 (Ubuntu)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-9.3 (Ubuntu Trusty)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-9.5 (Ubuntu Xenial)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-9.6 (Ubuntu Zesty)
 Importance: Undecided
 Status: Triaged

** Affects: postgresql-9.6 (Ubuntu Artful)
 Importance: Undecided
 Status: Triaged

** Also affects: postgresql-9.3 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.6 (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.6 (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.6 (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.6 (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.3 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.5 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: postgresql-9.6 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** No longer affects: postgresql-9.3 (Ubuntu Xenial)

** No longer affects: postgresql-9.3 (Ubuntu Zesty)

** No longer affects: postgresql-9.3 (Ubuntu Artful)

** No longer affects: postgresql-9.5 (Ubuntu Trusty)

** No longer affects: postgresql-9.5 (Ubuntu Artful)

** No longer affects: postgresql-9.5 (Ubuntu Zesty)

** No longer affects: postgresql-9.6 (Ubuntu Xenial)

** No longer affects: postgresql-9.6 (Ubuntu Trusty)

** Changed in: postgresql-9.3 (Ubuntu Trusty)
   Status: New => Triaged

** Changed in: postgresql-9.5 (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: postgresql-9.6 (Ubuntu Zesty)
   Status: New => Triaged

** Changed in: postgresql-9.6 (Ubuntu Artful)
   Status: New => Triaged

** Changed in: postgresql-9.5 (Ubuntu)
   Status: New => Invalid

** Changed in: postgresql-9.3 (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1713979

Title:
  New upstream microreleases 9.3.19, 9.5.9 and 9.6.5

Status in postgresql-9.3 package in Ubuntu:
  Invalid
Status in postgresql-9.5 package in Ubuntu:
  Invalid
Status in postgresql-9.6 package in Ubuntu:
  Triaged
Status in postgresql-9.3 source package in Trusty:
  Triaged
Status in postgresql-9.5 source package in Xenial:
  Triaged
Status in postgresql-9.6 source package in Zesty:
  Triaged
Status in postgresql-9.6 source package in Artful:
  Triaged

Bug description:
  Update to the new set of releases as per the standing micro-release
  exception these should land in stable Ubuntu releases.

  Curren versions in releases:
   postgresq

[Group.of.nepali.translators] [Bug 1099947] Re: driver unable to connect to CyberPower UPS using usbhid-ups driver

[ChristianEhrhardt]

That is what happens when bugs are dormant for too long :-/.
It still seems to be an issue for Trusty, but you are right without the ability 
to reproduce we should cancel that bug here from the Xenial SRU.
I have to redo it anyway for Xenial as there is an FTBFS in the fix (that is 
the reason you don't see it), and on that I'll reduce it to the other bug that 
was part of the planned SRU.

Thanks for your quick response!
I'm marking Xenial as invalid now - and the follow on upload will revert the 
change for this bug here.

Do you have a setup to verify the change on Trusty?
Not that this was fixed by e.g. udev changes unknown to us as well without us 
noticing.

** Changed in: nut (Ubuntu Xenial)
   Status: Fix Committed => Invalid

** Changed in: nut (Ubuntu Xenial)
   Status: Invalid => Fix Released

** Changed in: nut (Ubuntu Xenial)
   Status: Fix Released => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1099947

Title:
  driver unable to connect to CyberPower UPS using usbhid-ups driver

Status in nut package in Ubuntu:
  Fix Released
Status in nut source package in Trusty:
  Fix Committed
Status in nut source package in Xenial:
  Invalid
Status in nut package in Debian:
  Fix Released
Status in nut package in Fedora:
  Unknown

Bug description:
  [Impact]

   * Plugging in a USB controlled UPS solution does fail to execute the udev 
 rules; Due to that the permissions are not set correctly

   * Fix is a backport from upstream which only changes the numbering on the 
 rule to execute at the right time.

  [Test Case]

   * Install nut-server
   * Plug in a usb controlled UPS of your choice
   * The device node created should be mode 664 and group "nut", but it is 
 not.
   * Install the proposed package
   * (It also fixes but 1540008, so no need to replug anymore to test if 
  successful)
   * it should now be created with proper permissions.

  [Regression Potential]

   * If people with the old set up have created something that would not be 
 able to access anymore that could cuase issues, but before it was 
 root:root and now nut:root; the group permission didn't change (was 6 
 before) - so anything before could only access with root and they still 
 can - therefore I consider this of low/no risk, yet in some obscure 
 setups it might be one.

  [Other Info]
   
   * n/a

  ---

  
  I hooked my new CyberPower UPS: CP685AVR-G on my Lucid server and got this 
error:

    Jan 15 12:06:33 xeon upsd[5441]: Can't connect to UPS [cyberpower] 
(usbhid-ups-cyberpower): No such file or directory
    Jan 15 12:06:38 xeon upsmon[5445]: Poll UPS [cyberpower@127.0.0.1] failed - 
Driver not connected

  After trying many things, I found
  https://bugzilla.redhat.com/show_bug.cgi?id=488368 that hint me in the
  right direction. The required change was to rename the udev rule like
  this:

    mv /lib/udev/rules.d/{5,6}2-nut-usbups.rules

  Now, everything works well, without requiring "user = root" in
  /etc/nut/ups.conf because the udev rule now ensures the device file is
  owned by the group "nut":

    # find /dev/bus/usb/ -ls
    15360 drwxr-xr-x  10 root root  200 Jan 15 12:40 
/dev/bus/usb/
    15790 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/008
    15800 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/008/001
    15730 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/007
    15740 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/007/001
    15670 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/006
    15680 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/006/001
    15610 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/005
    15620 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/005/001
    15550 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/004
    15560 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/004/001
    15490 drwxr-xr-x   2 root root   80 Jan 15 12:40 
/dev/bus/usb/003
    21630 crw-rw-r--   1 root nut   Jan 15 12:49 
/dev/bus/usb/003/002
    15500 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/003/001
    15430 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/002
    15440 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/002/001
    15370 drwxr-xr-x   2 root root   60 Jan 15 12:40 
/dev/bus/usb/001
    15380 crw-rw-r--   1 root root  Jan 15 12:41 
/dev/bus/usb/001/001

  Generic information:

  # lsb_release -rd
  Description:  Ubuntu 10.04.4 LTS
  Release:  10.0

[Group.of.nepali.translators] [Bug 1540008] Re: USB permissions not set at install time (udevd name changed?)

[ChristianEhrhardt]

** Changed in: nut (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1540008

Title:
  USB permissions not set at install time (udevd name changed?)

Status in nut package in Ubuntu:
  Fix Released
Status in nut source package in Trusty:
  Confirmed
Status in nut source package in Xenial:
  Triaged
Status in nut source package in Yakkety:
  Won't Fix
Status in nut source package in Zesty:
  Triaged
Status in nut package in Debian:
  New

Bug description:
  1) $ lsb_release -rd
  Description:  Ubuntu 14.04.3 LTS
  Release:  14.04

  2) nut-server: 2.7.1-1ubuntu1; udev: 204-5ubuntu20.15

  3) On a fresh install of Ubuntu 14.04 (amd64), I installed the nut-
  server package while the UPS was already connected via USB. After
  installation, the permissions described by /lib/udev/rules.d/52-nut-
  usbups.rules should have changed the group of the corresponding
  /dev/bus/usb/*/* node to 'nut'.

  4) The owner/group for the /dev/bus/usb node remained root:root.
  Manually running 'udevadm trigger --subsystem-match=usb
  --action=change' changed the group to 'nut'. (From past experience
  tracking down related udev+nut bugs, unplugging and re-plugging the
  USB cable would yield similar results.)

  However, that udevadm command is included in the postinst for nut-
  server, and it is guarded with a pidof check for 'udevd':

  # ask udev to check for new udev rules
  [ -x /etc/init.d/udev ] && pidof udevd > /dev/null \
&& udevadm trigger --subsystem-match=usb --action=change

  This most likely needs to be amended to include the current process
  name, 'systemd-udevd'. I checked the control files, and unless the
  udevd process name has changed back, I believe this will affect vivid,
  wily and xenial as well as trusty. (I will let someone else add those
  later tags if that turns out to be the case.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1540008/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1595242] Re: mongodb xenial s390x packages are needed (blocks ceilometer)

[ChristianEhrhardt]

Hi,
the sync [1] of a mongodb set this to fix released quite a while ago, but in 
fact it fails to build on arm64 [2].
To make things less debuggable, the build issue seems to be a hang, killed by 
builders timeout and not a clear "error: foo is wrong".

I was "encouraged :-)" [3] for my s390x experience to look into this since 
s390x wanted the newer version of mongodb to get rid of the extra ppa [4] 
solution we have atm (see comment #8 in this bug).
But while I took a few tests with cross compiles and super slow arm emulations 
I couldn't get any closer to the issue. After all I'm not the arm expert, so 
maybe we should reconsider who owns the current task.

Now this issue is kind of back where it started. This is the bug that was 
referenced on IRC as "wanted s390x support" to begin with and holds said ppa 
solution for Xenial.
Fortunately Dannf is susbcribed on this bug and a much bigger arm expert which 
is what is really needed now to look into [2].

Furthermore to make things worse according to Steve langasek in bug
1679792 this now is a all-arch FTBFS for gcc-7 on top of the former
issues.

Finally mongodb 3.4 has several more point releases (3.4.7 since last
week), but that is a question to Debian if they are not updated for a
reason.

IMHO this should be:
- tracked by JFH (for s390x needing the new version of mongodb)
- if possible debugged by Dannf (for arm expertise and the owner/driver of the 
former 3.2.4 ppa build)
- Both are also the former drivers/owners of this bug which just seems not 
resolved.

Since both are subscribed here already driving the old effort, maybe you
just need this ping to realize it is not that much "fix released" as
everybody thought (setting the task status now).

[1]: https://launchpad.net/ubuntu/+source/mongodb/1:3.4.1-3
[2]: 
https://launchpadlibrarian.net/311346682/buildlog_ubuntu-zesty-arm64.mongodb_1%3A3.4.1-3_CANCELLING.txt.gz
[3]: https://irclogs.ubuntu.com/2017/08/11/%23ubuntu-release.html#t18:15
[4]: https://launchpad.net/~ubuntu-s390x-community/+archive/ubuntu/mongodb

** Changed in: mongodb (Ubuntu)
   Status: Fix Released => Confirmed

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1595242

Title:
  mongodb xenial s390x packages are needed (blocks ceilometer)

Status in OpenStack ceilometer charm:
  Invalid
Status in OpenStack ceilometer-agent charm:
  Invalid
Status in MongoDB Charm:
  Confirmed
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in mongodb package in Ubuntu:
  Confirmed
Status in mongodb source package in Xenial:
  Won't Fix
Status in mongodb source package in Yakkety:
  Won't Fix
Status in ceilometer package in Juju Charms Collection:
  Invalid
Status in ceilometer-agent package in Juju Charms Collection:
  Invalid
Status in mongodb package in Juju Charms Collection:
  Invalid
Status in mongodb package in Debian:
  Fix Released

Bug description:
  The ceilometer and ceilometer-agent charms require the mongodb charm.

  s390x validation for ceilometer and ceilometer-agent is blocked on the
  absence of mongodb packages in s390x Xenial, and on the absence of a
  Xenial mongodb charm in general.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-ceilometer/+bug/1595242/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1708305] Re: Realtime feature mlockall: Cannot allocate memory

[ChristianEhrhardt]

Hi Jorge,
thanks for your prep work on this.
Checking prereqs.

#1 fixed in Dev?
I read the "there is a patch" before as "there is a -new- patch", but checked 
now.
This is in since version 3.2 which makes it fix released in Artful already.
While I work on 3.6 we don't need it to go on with this as a fix in the dev 
version is a prereq.

#2 Patch?
I reviewed your changes and I'm ok with the patch, headers and backport.
Also in general while I'm not so sure on unlimited in general I see why they 
can't set a better value int his case - and since this is as-upstream this is 
good.

#3 SRU Queue?
Last SRU just complete, I think we are good adding a new one to the queue.

#4 Regressions
Thanks for pre-testing on your side already, gives some extra confidence.
I also checked via a (very basic) sniff test, full tests will have to be done 
on proposed but that we always do.
Therefore ok for now to go on.

#5 SRU Template
You already provided half of it, it misses a few things like regression 
considerations.
I can add those, but then nothing seems to block us from sponsoring this for 
SRU review IMO.

** Changed in: libvirt (Ubuntu Artful)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1708305

Title:
  Realtime feature mlockall: Cannot allocate memory

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  In Progress
Status in libvirt source package in Zesty:
  In Progress
Status in libvirt source package in Artful:
  Fix Released

Bug description:
  [Environment]

  root@buneary:~# lsb_release -a
  No LSB modules are available.
  Distributor ID:   Ubuntu
  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04
  Codename: xenial

  root@buneary:~# uname -r
  4.10.0-29-generic

  Reproducible also with the 4.4 kernel.

  [Description]

  When a guest memory backing stanza is defined using the  stanza + 
hugepages,
  as follows:

    
  
    
    
  
  
  
    

  (Full guest definition: http://paste.ubuntu.com/25229162/)

  The guest fails to start due to the following error:

  2017-08-02 20:25:03.714+: starting up libvirt version: 1.3.1, package: 
1ubuntu10.12 (Christian Ehrhardt  Wed, 19 Jul 
2017 08:28:14 +0200), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), 
hostname: buneary.seg
  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name reproducer2 -S -machine 
pc-i440fx-2.5,accel=kvm,usb=off -cpu host -m 124928 -realtime mlock=on -smp 
32,sockets=16,cores=1,threads=2 -object 
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu,share=yes,size=64424509440,host-nodes=0,policy=bind
 -numa node,nodeid=0,cpus=0-15,memdev=ram-node0 -object 
memory-backend-file,id=ram-node1,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu,share=yes,size=66571993088,host-nodes=1,policy=bind
 -numa node,nodeid=1,cpus=16-31,memdev=ram-node1 -uuid 
2460778d-979b-4024-9a13-0c3ca04b18ec -no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-reproducer2/monitor.sock,server,nowait
 -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 
file=/var/lib/uvtool/libvirt/images/test-ds.qcow,format=qcow2,if=none,id=drive-virtio-disk0,cache=none
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on
  Domain id=14 is tainted: host-cpu
  char device redirected to /dev/pts/1 (label charserial0)

  mlockall: Cannot allocate memory

  2017-08-02T20:25:37.732772Z qemu-system-x86_64: locking memory failed
  2017-08-02 20:25:37.811+: shutting down

  This seems to be due to the setrlimit for RLIMIT_MEMLOCK is too low for 
mlockall
  to work given the large amount of memory.

  There is a libvirt upstream patch that enforces the existence of the
  hard_limit stanza when using with  in the memory backing settings.

  
https://github.com/libvirt/libvirt/commit/c2e60ad0e5124482942164e5fec088157f5e716a

  Memory locking can only work properly if the memory locking limit
  for the QEMU process has been raised appropriately: the default one
  is extremely low, so there's no way the guest will fit in there.

  The commit
  
https://github.com/libvirt/libvirt/commit/7e667664d28f90bf6916604a55ebad7e2d85305b
  is also required when using hugepages and the locked stanza.

  [Test Case] 
   * Define a guest that uses the following stanzas (See for a full guest 
reference: http://p

[Group.of.nepali.translators] [Bug 1709877] Re: CPU hotplug fails in the system with empty numa nodes, "Invalid value '0-1, 16-17' for 'cpuset.mems': Invalid argument"

[ChristianEhrhardt]

Change is in >=v2.3.0 which makes this Fix released for a while.
Lets add and consider SRU from there.

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709877

Title:
  CPU hotplug fails in the system with empty numa nodes, "Invalid value
  '0-1,16-17' for 'cpuset.mems': Invalid argument"

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  New

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2017-07-19 
04:13:18 ==
  CPU hotplug operation fails in the host with empty numa nodes(with no memory) 
even though VM placement is static and with/without numad is running.
  ..
   32
  ...

  
  # virsh setvcpus virt-tests-vm1 6 --live
  error: Invalid value '0-1,16-17' for 'cpuset.mems': Invalid argument

  
  # numactl --hardware
  available: 4 nodes (0-1,16-17)
  node 0 cpus: 0 8 16 24 32 40
  node 0 size: 16188 MB
  node 0 free: 1119 MB
  node 1 cpus: 48 56 64 72 80 88
  node 1 size: 32630 MB
  node 1 free: 13233 MB
  node 16 cpus: 96 104 112 120 128 136
  node 16 size: 0 MB
  node 16 free: 0 MB
  node 17 cpus: 144 152 160 168 176 184
  node 17 size: 0 MB
  node 17 free: 0 MB
  node distances:
  node   0   1  16  17 
0:  10  20  40  40 
1:  20  10  40  40 
   16:  40  40  10  20 
   17:  40  40  20  10 

  # cat /sys/fs/cgroup/cpuset/cpuset.mems 
  0-1

  Host:
  #uname -a
  Linux powerkvm4-lp1 4.10.0-27-generic #30~16.04.2-Ubuntu SMP Thu Jun 29 
16:06:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

  ii  libvirt-bin1.3.1-1ubuntu10.11 
  ii  numad  0.5+20150602-4 
  qemu-kvm   1:2.5+dfsg-5ubuntu10.14

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709877/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1655625] Re: ISST-LTE:pVM:roselp4:ubuntu 16.04.2: vmcore cannot be analysed by crash

[ChristianEhrhardt]

crash is in 7.1.7 whichi is in >= Zesty so dev is good

** Changed in: crash (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: crash (Ubuntu)
 Assignee: Nish Aravamudan (nacc) => (unassigned)

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1655625

Title:
  ISST-LTE:pVM:roselp4:ubuntu 16.04.2: vmcore cannot be analysed by
  crash

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in crash package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in crash source package in Xenial:
  Fix Released
Status in makedumpfile source package in Xenial:
  Fix Released

Bug description:
  [SRU justification]
  This fix is required to make the crash tool usable. It does also improve 
makedumpfile filtering of pages.

  [Impact]
  Kernel crashes cannot be analysed with the crash tool.
  makedumpfile incorrectly filter pages.

  [Fix]
  Cherry-pick upstream commits fixing those issues.

  [Test Case]
  Running crash tool on a kernel crash file will display something like :

  # crash -s usr/lib/debug/boot/vmlinux-4.8.0-34-generic
  crash: read error: kernel virtual address: 81e29ff0  type: 
"pv_init_ops"
  crash: this kernel may be configured with CONFIG_STRICT_DEVMEM, which
     renders /dev/mem unusable as a live memory source.
  crash: trying /proc/kcore as an alternative to /dev/mem

  crash: seek error: kernel virtual address: 81e29ff0  type: 
"pv_init_ops"
  crash: seek error: kernel virtual address: 82166130  type: 
"shadow_timekeeper xtime_sec"
  crash: seek error: kernel virtual address: 81e0d304  type: 
"init_uts_ns"
  crash: usr/lib/debug/boot/vmlinux-4.8.0-34-generic and 
/var/crash/201701191308/dump.201701191308 do not match!

  With the fix, the crash command will work as expected

  Running the crash tool on a vmcore file produced by makedumpfile may
  return :

  crash: page excluded: kernel virtual address: <> type:
  "fill_task_struct"

  [Regression]
  None expected as those modifications are part of the Zesty and upstream 
version.

  The makedumpfile patches are in Yakkety and Zesty 1.6.0 & after

  [Original description of the problem]
  vmcore captured by kdump cannot be opened with crash:

  % sudo crash -d1 /usr/lib/debug/boot/vmlinux-4.8.0-34-generic 
/var/crash/201612282137/dump.201612282137
  ... ...
  base kernel version: 0.8.0
  linux_banner:
  
  crash: /usr/lib/debug/boot/vmlinux-4 and 
/var/crash/201612282137/dump.201612282137 do not match!

  Usage:

    crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
    crash [OPTION]... [NAMELIST]  (live system form)

  Enter "crash -h" for details.

  Looks like the 'linux_banner' cannot be understood by crash.

  And when the vmcore was dumping, this message being showed:

  [  729.609196] kdump-tools[5192]: The kernel version is not supported.
  [  729.609447] kdump-tools[5192]: The makedumpfile operation may be 
incomplete.
  ---uname output---
  Linux roselp4 4.8.0-34-generic #36~16.04.1-Ubuntu SMP Wed Dec 21 18:53:20 UTC 
2016 ppc64le ppc64le ppc64le GNU/Linux

  Machine Type = lpar

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   1. config kdump
  2. trigger kdump
  3. analyse vmcore with crash

  Userspace tool common name: crash/makedumpfile

  The userspace tool has the following bit modes: 64-bit

  Userspace rpm: makedumpfile 1.5.9-5ubuntu0.3/crash 7.1.4-1ubuntu4

  Userspace tool obtained from project website:  na

  *Additional Instructions for Ping Tian Han/pt...@cn.ibm.com:
  -Post a private note with access information to the machine that the bug is 
occuring on.
  -Attach ltrace and strace of userspace application.

  xtime timespec.tv_sec: 586481e8: Wed Dec 28 21:24:24 2016
  utsname:
   sysname: Linux
  nodename: boblp1
   release: 4.8.0-32-generic
   version: #34~16.04.1-Ubuntu SMP Tue Dec 13 17:01:57 UTC 2016
   machine: ppc64le
    domainname: (none)
  base kernel version: 4.8.0
  verify_namelist:
  dumpfile /proc/version:
  Linux version 4.8.0-32-generic (buildd@bos01-ppc64el-001) (gcc version 5.4.0 
20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #34~16.04.1-Ubuntu SMP Tue Dec 
13 17:01:57 UTC 2016 (Ubuntu 4.8.0-32.34~16.04.1-generic 4.8.11)
  /usr/lib/debug/boot/vmlinux-4.8.0-32-generic:
  Linux version 4.8.0-32-generic (buildd@bos01-ppc64el-001) (gcc version 5.4.0 
20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #34~16.04.1-Ubuntu SMP Tue Dec 
13 17:01:57 UTC 2016 (Ubuntu 4.8.0-32.34~16.04.1-generic 4.8.11)

  hypervisor: (undetermined)
  crash: per_cpu_symbol_search(per_cpu__tvec_bases): NULL
  ppc64_vmemmap_init: vmemmap base: f000

  crash: PPC64: cannot find 'cpu_possible_map', 'cpu_present_map',
  'cpu_online_map' or 'cpu_active_map' symbols

  r

[Group.of.nepali.translators] [Bug 1709224] Re: libvirt lxc can't stop all process when destroy vm.

[ChristianEhrhardt]

Hi yuanzhicao,
thank you for your report and your analysis to a suggested fix.

The fix you refer to was released in 1.3.2, setting later releases to
fix-released.

In general Libvirt's lxc support is not of focus, I'd highly recommend
using lxd for system containers which is far more stable in my
experience (Setting prio low to reflect that).

I'll try to quickly come up with a ppa to test for you and get back
here.

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1709224

Title:
  libvirt lxc  can't stop all process when destroy vm.

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  New

Bug description:
  Environments:
  System: zesty
  libvirt version: 2.5.0-3ubuntu5
  vm rootfs release: ubuntu:16.04

  Reproduce:
  1. Run command "virsh -c lxc:// start vm" and the release of vm is xenial
  2. Run command "pa aux|grep init" ,you would find the pid of init launch by 
vm.
  3. Run command "virsh -c lxc:// destroy vm".
  4. Run command "virsh -c lxc:// list --all" and "ps aux|grep init" ,you could 
find that vm is shutoff, but the init process launch by vm is still running.

  Infact I have found the case of this bug, there is a patch after 1.3.1
  that import this bug.

  -
  Commit: dc576025c360a1d2c89da410d0f3f0da55d0143f [dc57602]
  Parents: 511e7c5bba
  Author: Daniel P. Berrange 
  Date: 2016年1月23日 GMT+8 上午12:07:18
  Commit Date: 2016年1月27日 GMT+8 上午12:11:32
  lxc: don't try to hide parent cgroups inside container
  -

  Cgroups inside container does't hide parent, so the process of container can 
change it own cgroup to  another cgroup.
  lxc destroy process by read cgroup tasks file,if process change it own 
cgroup,it can't destroy container process normally.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1709224/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1706058] Re: Windows VM crashes when restoring from file if balloon stats polling is enabled

[ChristianEhrhardt]

** Also affects: qemu (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1706058

Title:
  Windows VM crashes when restoring from file if balloon stats polling
  is enabled

Status in Ubuntu Cloud Archive:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  New
Status in qemu source package in Xenial:
  New

Bug description:
  [Impact]

   * Windows VMs BSOD when restoring from QEMUfile or during live migration if 
the virtio balloon stats polling is enabled.
   * Affected version: 1:2.5+dfsg-5ubuntu10.14 (xenial)

  [Test Case]

   * Install a Windows VM with virtio balloon drivers
   * Start the VM and enable stats polling [1]
   * Save the VM to savefile [2]
   * Restore the VM [3]
   * Enable stats polling [1] and VM will BSOD

  QMP examples:
   [1] 
{"execute":"qom-set","arguments":{"path":"//machine/i440fx/pci.0/child[7]","property":"guest-stats-polling-interval","value":10}}
   [2] {"execute": "migrate", "arguments": {"uri":"exec:gzip -c > 
/storage/cases/VM/savefiles/testVM3save.gz"}}
   [3] {"execute":"migrate-incoming","arguments":{"uri":"exec:gzip -c -d 
/storage/cases/VM/savefiles/testVM3save.gz"}}

  [Other Info]

   * This has been fixed upstream with commit 
4a1e48becab81020adfb74b22c76a595f2d02a01
  * Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1373600

  [Regression Potential]

   *

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1706058/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1705132] Re: Large memory guests, "error: monitor socket did not show up: No such file or directory"

[ChristianEhrhardt]

Referred change is upstream in Libvirt 3.2, so assuming that is fixed.
But check on X-Z SRUs

** Also affects: libvirt (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: libvirt (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: libvirt (Ubuntu)
   Status: New => Fix Released

** Changed in: libvirt (Ubuntu Xenial)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Yakkety)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Zesty)
   Status: New => Triaged

** Changed in: libvirt (Ubuntu Xenial)
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1705132

Title:
  Large memory guests, "error: monitor socket did not show up: No such
  file or directory"

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Incomplete
Status in libvirt source package in Yakkety:
  Triaged
Status in libvirt source package in Zesty:
  Triaged

Bug description:
  [Environment]

  Description:  Ubuntu 16.04.2 LTS
  Release:  16.04
  Codename: xenial

  root@buneary:/home/ubuntu# dpkg -l | grep kvm
  ii  qemu-kvm1:2.5+dfsg-5ubuntu10.14   
   amd64QEMU Full virtualization

  [Description]

  - Configured a machine with 32 static VCPUs, 160GB of RAM using 1G 
  hugepages on a NUMA capable machine.

  Domain definition (http://pastebin.ubuntu.com/25121106/)

  - Once started (virsh start).

  Libvirt log.

  LC_ALL=C
  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  QEMU_AUDIO_DRV=none /usr/bin/kvm-spice -name reproducer2 -S -machine
  pc-i440fx-2.5,accel=kvm,usb=off -cpu host -m 124928 -realtime
  mlock=off -smp 32,sockets=16,cores=1,threads=2 -object memory-backend-
  file,id=ram-node0,prealloc=yes,mem-
  path=/dev/hugepages/libvirt/qemu,share=yes,size=64424509440,host-
  nodes=0,policy=bind -numa node,nodeid=0,cpus=0-15,memdev=ram-node0
  -object memory-backend-file,id=ram-node1,prealloc=yes,mem-
  path=/dev/hugepages/libvirt/qemu,share=yes,size=66571993088,host-
  nodes=1,policy=bind -numa node,nodeid=1,cpus=16-31,memdev=ram-node1
  -uuid d7a4af7f-7549-4b44-8ceb-4a6c951388d4 -no-user-config -nodefaults
  -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-
  reproducer2/monitor.sock,server,nowait -mon
  chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
  -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
  -drive
  file=/var/lib/uvtool/libvirt/images/test.qcow,format=qcow2,if=none,id
  =drive-virtio-disk0,cache=none -device virtio-blk-
  pci,scsi=off,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,id=virtio-
  disk0,bootindex=1 -chardev pty,id=charserial0 -device isa-
  serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-
  vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-
  pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on

  Then the following error is raised.

  virsh start reproducer2
  error: Failed to start domain reproducer2
  error: monitor socket did not show up: No such file or directory

  
  [Possible Fix]

  
https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=85af0b803cd19a03f71bd01ab4e045552410368f;hp=67dcb797ed7f1fbb048aa47006576f424923933b

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1705132/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

[Group.of.nepali.translators] [Bug 1558196] Re: ypbind not able to socket activate rpcbind under systemd, fails at boot unless something else starts rpcbind

[ChristianEhrhardt]

As nis needs no change set that to invalid.

** Changed in: nis (Ubuntu Xenial)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1558196

Title:
  ypbind not able to socket activate rpcbind under systemd, fails at
  boot unless something else starts rpcbind

Status in nis package in Ubuntu:
  Fix Released
Status in rpcbind package in Ubuntu:
  Fix Released
Status in nis source package in Xenial:
  Invalid
Status in rpcbind source package in Xenial:
  Triaged
Status in nis package in Debian:
  Fix Released

Bug description:
  did apt-get update/upgrade  March 16, 2016 
  Description:Ubuntu Xenial Xerus (development branch)
  Release:16.04

  rpcbind does not start on boot, tried various systemd debugging steps
  with no clues. After boot systemctl start rpcbind works. There is  a
  /etc/init.d/rpcbind and a /lib/systemd/system/rpcbind.service config
  files which is confusing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nis/+bug/1558196/+subscriptions

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp