[Group.of.nepali.translators] [Bug 1793461] Re: Improvements to the kernel source package preparation

2018-10-08 Thread Thadeu Lima de Souza Cascardo 
** Also affects: linux-hwe-edge (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-hwe-edge (Ubuntu Bionic)
   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/1793461

Title:
  Improvements to the kernel source package preparation

Status in linux package in Ubuntu:
  Fix Committed
Status in linux-hwe-edge package in Ubuntu:
  New
Status in linux source package in Precise:
  Fix Committed
Status in linux-hwe-edge source package in Precise:
  New
Status in linux source package in Trusty:
  Fix Committed
Status in linux-hwe-edge source package in Trusty:
  New
Status in linux source package in Xenial:
  Fix Committed
Status in linux-hwe-edge source package in Xenial:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-hwe-edge source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Committed
Status in linux-hwe-edge source package in Cosmic:
  New

Bug description:
  We need to improve the automation of the process that we use to
  prepare kernel source packages. That requires changes in both the
  tooling and in the kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1793461/+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 1790605] Re: please include the kernel module IPIP

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package linux-kvm - 4.18.0-1002.2

---
linux-kvm (4.18.0-1002.2) cosmic; urgency=medium

  * linux-kvm: 4.18.0-1001.1 -proposed tracker (LP: #1795413)

  * Miscellaneous Ubuntu changes
- kvm: [Config] CONFIG_HARDENED_USERCOPY=y
- kvm: [Config] CONFIG_DEBUG_WX=y

 -- Seth Forshee   Mon, 01 Oct 2018 09:27:19
-0500

** Changed in: linux-kvm (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/1790605

Title:
  please include the kernel module IPIP

Status in cloud-images:
  Won't Fix
Status in linux-kvm package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  Fix Released
Status in linux-kvm source package in Bionic:
  Fix Released

Bug description:
  In order to run calico with ubuntu cloud image one needs the ipip
  kernel module, which is unfortunately not present.

  
  $ grep IPIP /boot/config-4.4.0-1032-kvm 
  # CONFIG_NET_IPIP is not set

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1790605/+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 1780773] Re: [18.10 FEAT] zKVM: CPU Model z14 ZR 1

2018-10-08 Thread Frank Heimes 
** Changed in: ubuntu-z-systems
   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/1780773

Title:
  [18.10 FEAT] zKVM: CPU Model z14 ZR 1

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * Backport definition of the new machine type as HW exploitation for 
 z14R1

   * Trivial change just making the type known to qemu will fulfill IBMs 
 need on this.

  [Test Case]

   * Use qemu/KVM on a z14R1 and check the cpu features.
 Lacking such a system the real verification relies on IBM who confirmed 
 to do it.
   * While unable to really use it for a lot of benefit, you can check the 
 definition exists at least with:
   $ qemu-system-s390x -cpu ? | grep z14
 After the fix this gets the two extra lines:
  s390 z14ZR1-base IBM z14 Model ZR1 GA1   (static, 
migration-safe)
  s390 z14ZR1  IBM z14 Model ZR1 GA1   (migration-safe)

  [Regression Potential]

   * I know we are encouraged to think about all possible regressions, but 
 here it is hard to find one. A one line change to a set of definitions
 that are checked against the machine type.
 I could only think of fake machine types 3907 environments changing 
 (doesn't exist)
 Well real z14R1 machines will after the change behave differently by 
 detecting the type correctly, but that is just what is requested in 
 this backport.

  
  [Other Info]
   
   * n/a

  

  Feature Description

  Provide the CPU model for the IBM z14 ZR1 to enable KVM guests to
  exploit new hardware features on the z14 ZR1

  The required patch is

  commit f0b9be93001e6215dc1195f3d75ad2da8b3b694a (qemu 3.0)

  s390x/cpumodels: add z14 Model ZR1

  Introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
  the cpu type differs (3906 vs. 3907)

  Business Case
  Support z14 ZR1 hardware features with KVM guests

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1780773/+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 1738153] Re: need backport the new scancode of dell-wmi for Microphone mute hotkey to xenial

2018-10-08 Thread Dimitri John Ledkov 
** Changed in: systemd (Ubuntu Artful)
   Status: Confirmed => Won't Fix

** Changed in: systemd (Ubuntu Xenial)
   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/1738153

Title:
  need backport the new scancode of dell-wmi for Microphone mute hotkey
  to xenial

Status in OEM Priority Project:
  Confirmed
Status in OEM Priority Project xenial series:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Artful:
  Won't Fix

Bug description:
  [Impact]
  dell-wmi expend the scan code of Microphone mute hotkey from 0x150 to 
0x100150, so need to add a new mapping for it.

  related commit:
  https://github.com/systemd/systemd/pull/5012

  [Test Case]
  1. install the udev package which applied patch.
  2. check if Microphone mute hotkey works.
  3. if it not works, please provide the log of evtest.

  [Regression Potential]
  low regression potential, because it just add one more mapping.

  also affect:
  LP: #1736352
  LP: #1740080
  LP: #1734609

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1738153/+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 1727237] Re: systemd-resolved is not finding a domain

2018-10-08 Thread Dimitri John Ledkov 
** Changed in: systemd (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/1727237

Title:
  systemd-resolved is not finding a domain

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Triaged
Status in systemd source package in Zesty:
  Won't Fix
Status in systemd source package in Artful:
  Won't Fix
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  
  [Impact] 

   * Certain WiFi captive portals do not support EDNS0 queries, as per RFC.
   * Instead of responding with the captive portal IP address, they resond with 
domain not found
   * This prevents the user from hitting the captive portal login page, able to 
authenticate, and gain access to the internets.

  [The Fix]

   * As per tcp dumps, the problem arrises from receiving NXDOMAIN when queried 
with EDNS0
   * And receiving the right response without EDNS0
   * The solution was to downgrade transactions, and retry EDNS0 + NXDOMAIN 
result without EDNS0 with a hope of getting the right answer.

  [Test Case]

  * systemd-resolve securelogin.example.com
  * journalctl -b -u systemd-resolve | grep DVE-2018

  You should obverse that a warning message that transaction was retried
  with a reduced feature level e.g. UDP or TCP.

  After this test case is performed the result will be cached, therefore
  to revert to pristine state perform

  * systemd-resolve --flush-caches

  [Regression Potential]

   * The code retries, and then caches, NXDOMAIN results for certain
  queries (those that have 'secure' in them) with and without EDNS0.

   * Thus initial query for these domains may take longer, but hopefully
  will manage to receive the correct response.

   * Manufacturers are encouraged to correctly support EDNS0 queries,
  with flag D0 set to zero.

  [Other Info]
   
   * This issue is tracked as a dns-violation at
  
https://github.com/dns-violations/dns-violations/blob/master/2018/DVE-2018-0001.md

  [Original Bug report]

  I have an odd network situation that I have so far managed to narrow
  down to the inability to resolve a domain via systemd-resolved which
  is resolvable with nslookup. If I use nslookup against the two
  nameservers on this network I get answers for the domain, but ping
  says it is unable to resolve the same domain (as do browsers and
  crucially the captive portal mechanism).

  Here are details:

  NSLOOKUP:

  ~$ nslookup securelogin.arubanetworks.com 208.67.220.220
  Server:   208.67.220.220
  Address:  208.67.220.220#53

  Non-authoritative answer:
  Name: securelogin.arubanetworks.com
  Address: 172.22.240.242

  ~$ nslookup securelogin.arubanetworks.com 208.67.222.222
  Server:   208.67.222.222
  Address:  208.67.222.222#53

  Non-authoritative answer:
  Name: securelogin.arubanetworks.com
  Address: 172.22.240.242

  PING:

  ~$ ping securelogin.arubanetworks.com
  ping: securelogin.arubanetworks.com: Name or service not known
  mark@mark-X1Y2:~$

  DIG:

  ~$ dig @208.67.222.222 securelogin.arubanetworks.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @208.67.222.222 securelogin.arubanetworks.com
  ; (1 server found)
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9416
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;securelogin.arubanetworks.com.   IN  A

  ;; AUTHORITY SECTION:
  arubanetworks.com.1991IN  SOA dns5.arubanetworks.com. 
hostmaster.arubanetworks.com. 1323935888 3600 200 1209600 86400

  ;; Query time: 34 msec
  ;; SERVER: 208.67.222.222#53(208.67.222.222)
  ;; WHEN: Wed Oct 25 10:31:10 CEST 2017
  ;; MSG SIZE  rcvd: 144

  MORE DIG:

  ~$ dig securelogin.arubanetworks.com

  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> securelogin.arubanetworks.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3924
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 65494
  ;; QUESTION SECTION:
  ;securelogin.arubanetworks.com.   IN  A

  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Wed Oct 25 10:34:01 CEST 2017
  ;; MSG SIZE  rcvd: 58

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1727237/+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 1709784] Re: KVM on 16.04.3 throws an error

2018-10-08 Thread Andrew Cloke 
As this ticket only relates to Xenial and 4.4 kernel, marking as "Fix
Released".

** Changed in: ubuntu-power-systems
   Status: Fix Committed => Fix Released

** Changed in: linux (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/1709784

Title:
  KVM on 16.04.3 throws an error

Status in The Ubuntu-power-systems project:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in qemu package in Ubuntu:
  Won't Fix
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Zesty:
  Invalid

Bug description:
  Problem Description
  
  KVM on Ubuntu 16.04.3 throws an error when used
   
  ---uname output---
  Linux bastion-1 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31 19:37:08 UTC 2017 
ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type =  8348-21C Habanero 
   
  ---Steps to Reproduce---
   Install 16.04.3

  install KVM like:

  apt-get install libvirt-bin qemu qemu-slof qemu-system qemu-utils

  then exit and log back in so virsh will work without sudo

  then run my spawn script

  $ cat spawn.sh
  #!/bin/bash

  img=$1
  qemu-system-ppc64 \
  -machine pseries,accel=kvm,usb=off -cpu host -m 512 \
  -display none -nographic \
  -net nic -net user \
  -drive "file=$img"

  with a freshly downloaded ubuntu cloud image

  sudo ./spawn.sh xenial-server-cloudimg-ppc64el-disk1.img

  And I get nothing on the output.

  and errors in dmesg

  
  ubuntu@bastion-1:~$ [  340.180295] Facility 'TM' unavailable, exception at 
0xd000148b7f10, MSR=90009033
  [  340.180399] Oops: Unexpected facility unavailable exception, sig: 6 [#1]
  [  340.180513] SMP NR_CPUS=2048 NUMA PowerNV
  [  340.180547] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp 
bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables 
iptable_filter ip_tables x_tables kvm_hv kvm binfmt_misc joydev input_leds 
mac_hid opal_prd ofpart cmdlinepart powernv_flash ipmi_powernv ipmi_msghandler 
mtd at24 uio_pdrv_genirq uio ibmpowernv powernv_rng vmx_crypto ib_iser rdma_cm 
iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi 
scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq raid1 raid0 multipath 
linear mlx4_en hid_generic usbhid hid uas usb_storage ast i2c_algo_bit bnx2x 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops mlx4_core drm 
ahci vxlan libahci ip6_udp_tunnel udp_tunnel mdio libcrc32c
  [  340.181331] CPU: 46 PID: 5252 Comm: qemu-system-ppc Not tainted 
4.4.0-89-generic #112-Ubuntu
  [  340.181382] task: c01e34c30b50 ti: c01e34ce4000 task.ti: 
c01e34ce4000
  [  340.181432] NIP: d000148b7f10 LR: d00014822a14 CTR: 
d000148b7e40
  [  340.181475] REGS: c01e34ce77b0 TRAP: 0f60   Not tainted  
(4.4.0-89-generic)
  [  340.181519] MSR: 90009033   CR: 22024848  
XER: 
  [  340.181629] CFAR: d000148b7ea4 SOFTE: 1 
  GPR00: d00014822a14 c01e34ce7a30 d000148cc018 c01e37bc 
  GPR04: c01db9ac c01e34ce7bc0   
  GPR08: 0001 c01e34c30b50 0001 d000148278f8 
  GPR12: d000148b7e40 cfb5b500  001f 
  GPR16: 3fff91c3 0080 3fffa8e34390 3fff9242f200 
  GPR20: 3fff92430010 01001de5c030 3fff9242eb60 100c1ff0 
  GPR24: 3fffc91fe990 3fff91c10028  c01e37bc 
  GPR28:  c01db9ac c01e37bc c01db9ac 
  [  340.182315] NIP [d000148b7f10] kvmppc_vcpu_run_hv+0xd0/0xff0 [kvm_hv]
  [  340.182357] LR [d00014822a14] kvmppc_vcpu_run+0x44/0x60 [kvm]
  [  340.182394] Call Trace:
  [  340.182413] [c01e34ce7a30] [c01e34ce7ab0] 0xc01e34ce7ab0 
(unreliable)
  [  340.182468] [c01e34ce7b70] [d00014822a14] 
kvmppc_vcpu_run+0x44/0x60 [kvm]
  [  340.182522] [c01e34ce7ba0] [d0001481f674] 
kvm_arch_vcpu_ioctl_run+0x64/0x170 [kvm]
  [  340.182581] [c01e34ce7be0] [d00014813918] 
kvm_vcpu_ioctl+0x528/0x7b0 [kvm]
  [  340.182634] [c01e34ce7d40] [c02fffa0] do_vfs_ioctl+0x480/0x7d0
  [  340.182678] [c01e34ce7de0] [c03003c4] SyS_ioctl+0xd4/0xf0
  [  340.182723] [c01e34ce7e30] [c0009204] system_call+0x38/0xb4
  [  340.182766] Instruction dump:
  [  340.182788] e92d02a0 e9290a50 e9290108 792a07e3 41820058 e92d02a0 e9290a50 
e9290108 
  [  340.182863] 7927e8a4 78e71f87 40820ed8 e92d02a0 <7d4022a6> f9490ee8 
e92d02a0 7d4122a6 
  [  340.182938] ---[ end trace bc5080cb7d18f102

[Group.of.nepali.translators] [Bug 1765364] Re: Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and possibly 14.04 LTS releases

2018-10-08 Thread Andrew Cloke 
** Also affects: ubuntu-power-systems/ubuntu-14.04
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems/ubuntu-14.04
   Importance: Undecided => Critical

** Changed in: ubuntu-power-systems/ubuntu-16.04
   Status: New => 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/1765364

Title:
  Backport spectre/meltdown fixes on qemu for ppc64 into 16.04 and
  possibly 14.04 LTS releases

Status in The Ubuntu-power-systems project:
  In Progress
Status in The Ubuntu-power-systems project ubuntu-14.04 series:
  New
Status in The Ubuntu-power-systems project ubuntu-16.04 series:
  In Progress
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  New

Bug description:
  == Comment: #0 - Satheesh Rajendran  - 2018-04-19 
04:26:51 ==
  ---Problem Description---
  Backport spectre/meltdown fixes on qemu for ppc64 into all LTS releases
   
  Contact Information = sathe...@in.ibm.com 
   
  ---uname output---
  -
   
  Machine Type = power8,power9 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   For pseries guests there are 3 tri-state -machine options/capabilities 
relating to Spectre/Meltdown mitigation: cap-cfpc, cap-sbbc, cap-ibs, which 
each correspond to a set of host machine capabilities advertised by the KVM 
kernel module in new/patched host kernels that can be used to mitigate various 
aspects of Spectre/Meltdown:

  cap-cfpc: Cache Flush on Privilege Change
  cap-sbbc: Speculation Barrier Bounds Checking
  cap-ibs: Indirect Branch Serialisation

  Details can be found here https://www.qemu.org/2018/02/14/qemu-2-11-1
  -and-spectre-update/

  Needed qemu commits:

  cb931c2108 target/ppc: Check mask when setting cap_ppc_safe_indirect_branch
  4f5b039d2b ppc/spapr-caps: Disallow setting workaround for spapr-cap-ibs
  8c5909c419 ppc/spapr-caps: Change migration macro to take full spapr-cap name
  c59704b254 target/ppc/spapr: Add H-Call H_GET_CPU_CHARACTERISTICS
  4be8d4e7d9 target/ppc/spapr_caps: Add new tristate cap safe_indirect_branch
  09114fd817 target/ppc/spapr_caps: Add new tristate cap safe_bounds_check
  8f38eaf8f9 target/ppc/spapr_caps: Add new tristate cap safe_cache
  6898aed77f target/ppc/spapr_caps: Add support for tristate spapr_capabilities
  8acc2ae5e9 target/ppc/kvm: Add 
cap_ppc_safe_[cache/bounds_check/indirect_branch]


  Optional commits to introduce a machine type variant pseries--sxxm, 
when used would set/enable the three machine capabilities explained above 
automatically, if host is capable(host kernel is supported). Bug 166426
  813f3cf655 ppc/spapr-caps: Define the pseries-2.12-sxxm machine type
  c76c0d3090 ppc/spapr-caps: Convert cap-ibs to custom spapr-cap
  aaf265ffde ppc/spapr-caps: Convert cap-sbbc to custom spapr-cap
  f27aa81e72 ppc/spapr-caps: Convert cap-cfpc to custom spapr-cap
  87175d1bc5 ppc/spapr-caps: Add support for custom spapr_capabilities

  
   
  Userspace tool common name: qemu-kvm 
   
  The userspace tool has the following bit modes: both 

  Userspace rpm: qemu-kvm

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for sathe...@in.ibm.com:
  -Attach ltrace and strace of userspace application.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1765364/+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 1780773] Re: [18.10 FEAT] zKVM: CPU Model z14 ZR 1

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.6

---
qemu (1:2.11+dfsg-1ubuntu7.6) bionic; urgency=medium

  [ Christian Ehrhardt ]
  * Add cpu model for z14 ZR1 (LP: #1780773)
  * d/p/ubuntu/lp-1789551-seccomp-set-the-seccomp-filter-to-all-threads.patch:
ensure that the seccomp blacklist is applied to all threads (LP: #1789551)
- CVE-2018-15746
  * improve s390x spectre mitigation with etoken facility (LP: #1790457)
- debian/patches/ubuntu/lp-1790457-s390x-kvm-add-etoken-facility.patch
- debian/patches/ubuntu/lp-1790457-partial-s390x-linux-headers-update.patch

  [ Phillip Susi ]
  * d/p/ubuntu/lp-1787267-fix-en_us-vnc-pipe.patch: Fix pipe, greater than and
less than keys over vnc when using en_us kemaps (LP: #1787267).

 -- Christian Ehrhardt   Wed, 29 Aug
2018 11:46:37 +0200

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

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-15746

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

Title:
  [18.10 FEAT] zKVM: CPU Model z14 ZR 1

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * Backport definition of the new machine type as HW exploitation for 
 z14R1

   * Trivial change just making the type known to qemu will fulfill IBMs 
 need on this.

  [Test Case]

   * Use qemu/KVM on a z14R1 and check the cpu features.
 Lacking such a system the real verification relies on IBM who confirmed 
 to do it.
   * While unable to really use it for a lot of benefit, you can check the 
 definition exists at least with:
   $ qemu-system-s390x -cpu ? | grep z14
 After the fix this gets the two extra lines:
  s390 z14ZR1-base IBM z14 Model ZR1 GA1   (static, 
migration-safe)
  s390 z14ZR1  IBM z14 Model ZR1 GA1   (migration-safe)

  [Regression Potential]

   * I know we are encouraged to think about all possible regressions, but 
 here it is hard to find one. A one line change to a set of definitions
 that are checked against the machine type.
 I could only think of fake machine types 3907 environments changing 
 (doesn't exist)
 Well real z14R1 machines will after the change behave differently by 
 detecting the type correctly, but that is just what is requested in 
 this backport.

  
  [Other Info]
   
   * n/a

  

  Feature Description

  Provide the CPU model for the IBM z14 ZR1 to enable KVM guests to
  exploit new hardware features on the z14 ZR1

  The required patch is

  commit f0b9be93001e6215dc1195f3d75ad2da8b3b694a (qemu 3.0)

  s390x/cpumodels: add z14 Model ZR1

  Introduce the new z14 Model ZR1 cpu model. Mostly identical to z14, only
  the cpu type differs (3906 vs. 3907)

  Business Case
  Support z14 ZR1 hardware features with KVM guests

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1780773/+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 1789551] Re: qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.6

---
qemu (1:2.11+dfsg-1ubuntu7.6) bionic; urgency=medium

  [ Christian Ehrhardt ]
  * Add cpu model for z14 ZR1 (LP: #1780773)
  * d/p/ubuntu/lp-1789551-seccomp-set-the-seccomp-filter-to-all-threads.patch:
ensure that the seccomp blacklist is applied to all threads (LP: #1789551)
- CVE-2018-15746
  * improve s390x spectre mitigation with etoken facility (LP: #1790457)
- debian/patches/ubuntu/lp-1790457-s390x-kvm-add-etoken-facility.patch
- debian/patches/ubuntu/lp-1790457-partial-s390x-linux-headers-update.patch

  [ Phillip Susi ]
  * d/p/ubuntu/lp-1787267-fix-en_us-vnc-pipe.patch: Fix pipe, greater than and
less than keys over vnc when using en_us kemaps (LP: #1787267).

 -- Christian Ehrhardt   Wed, 29 Aug
2018 11:46:37 +0200

** Changed in: qemu (Ubuntu Bionic)
   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/1789551

Title:
  qemu: CVE-2018-15746: seccomp: blacklist is not applied to all threads

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Trusty:
  Won't Fix
Status in qemu source package in Xenial:
  Won't Fix
Status in qemu source package in Bionic:
  Fix Released
Status in qemu source package in Cosmic:
  Fix Released
Status in qemu package in Debian:
  Confirmed

Bug description:
  [Impact]

   * Backport upstream CVE fix (applies as-is)

   * This will ensure that the seccomp rules apply to all threads.
 Without that the security benefit that seccomp provides can be avoided 
 by an attacker.

  [Test Case]

   * Run qemu on Bionic, and enable the seccomp feature (not yet default on 
 in Bionic, but in Cosmic). In qemu this is called "sandbox"

 $ qemu-system-x86_64 -sandbox on -nographic & pid=$!; sleep 2s;
   echo PID $pid; for task in /proc/$pid/task/*; do cat $task/status | grep 
Secc; done; kill -9 $pid

  That will report something like
  PID 23230
  Seccomp: 2
  Seccomp: 0

  And the two lines should match.

  [Regression Potential]

   * discussion of how regressions are most likely to manifest as a
  result of this change.

   * It is assumed that any SRU candidate patch is well-tested before
 upload and has a low overall risk of regression, but it's important
 to make the effort to think about what ''could'' happen in the
 event of a regression.

   * This both shows the SRU team that the risks have been considered,
 and provides guidance to testers in regression-testing the SRU.

  [Other Info]
   
   * This was discussed for other releases e.g. Xenial, but back then the 
 approach to seccomp was different and regression risk would be too 
 high.

  

  The Qemu changes are public, so nothing to hide here IMHO, but leaving
  that to the security team.

  Copy from the related Debian bug that I commented on:
  "
  The following vulnerability was published for qemu.

  CVE-2018-15746[0]:
  seccomp: blacklist is not applied to all threads

  If you fix the vulnerability please also make sure to include the
  CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

  For further information see:

  [0] https://security-tracker.debian.org/tracker/CVE-2018-15746
  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15746
  [1] https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg04892.html
  [2] https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg02289.html
  "

  In addition I think that:
  - it is available (built in since all still supported releases)
  - it is default enabled with qemu 2.11 (Bionic)
  - with libvirt >4.3 (Cosmic) more of the filters are set

  That in my bad security severity guessing capability makes it
  - Medium prio =Bionic

  OTOH, when checking the upstream reproducer with a qemu 2.11 I see nothing 
being used - so maybe all of it is a red herring (checked on Bionic):
  $ for pid in $(pidof qemu-system-x86_64); do echo PID $pid; for task in 
/proc/$pid/task/*; do cat $task/status | grep Secc; done; done
  PID 10817
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  PID 10657
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  PID 438
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0
  Seccomp:0

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

___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to :

[Group.of.nepali.translators] [Bug 1737866] Re: Too many open files when large number of routers on a host

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package openvswitch - 2.5.5-0ubuntu0.16.04.1

---
openvswitch (2.5.5-0ubuntu0.16.04.1) xenial; urgency=medium

  * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
  * d/watch: Update for upstream website changes.
  * New upstream point release (LP: #1788103).
  * d/p/CVE-2017-9214.patch: Dropped, included upstream.

 -- James Page   Wed, 22 Aug 2018 09:36:55 +0100

** Changed in: openvswitch (Ubuntu Xenial)
   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/1737866

Title:
  Too many open files when large number of routers on a host

Status in OpenStack neutron-openvswitch charm:
  Invalid
Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in Ubuntu Cloud Archive pike series:
  Fix Released
Status in openvswitch package in Ubuntu:
  Fix Released
Status in openvswitch source package in Xenial:
  Fix Released
Status in openvswitch source package in Artful:
  Won't Fix
Status in openvswitch source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  OpenStack environments running large numbers of routers and dhcp agents on a 
single host can hit the NOFILES limit in OVS, resulting in broken operation of 
virtual networking.

  [Test Case]
  Deploy openstack environment; create large number of virtual networks and 
routers.
  OVS will start to error with 'Too many open files'

  [Regression Potential]
  Minimal - we're just increasing the NOFILE limit via the systemd service 
definition.

  [Original Bug Report]
  When there are a large number of routers and dhcp agents on a host, we see a 
syslog error repeated:

  "hostname ovs-vswitchd: ovs|1762125|netlink_socket|ERR|fcntl: Too many
  open files"

  If I check the number of filehandles owned by the pid for "ovs-
  vswitchd unix:/var/run/openvswitch/db.sock" I see close to/at 65535
  files.

  If I then run the following, we double the limit and (in our case) saw
  the count rise to >8:

  prlimit -p $pid --nofile=131070

  We need to be able to:
  - monitor via nrpe, if the process is running short on filehandles
  - configure the limit so we have the option to not run out.

  Currently, if I restart the process, we'll lose this setting.

  Needless to say, openvswitch running out of filehandles causes all
  manner of problems for services which use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1737866/+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 1737866] Re: Too many open files when large number of routers on a host

2018-10-08 Thread James Page 
This bug was fixed in the package openvswitch - 2.5.5-0ubuntu0.16.04.1~cloud0
---

 openvswitch (2.5.5-0ubuntu0.16.04.1~cloud0) trusty-mitaka; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 openvswitch (2.5.5-0ubuntu0.16.04.1) xenial; urgency=medium
 .
   * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
   * d/watch: Update for upstream website changes.
   * New upstream point release (LP: #1788103).
   * d/p/CVE-2017-9214.patch: Dropped, included upstream.


** Changed in: cloud-archive/mitaka
   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/1737866

Title:
  Too many open files when large number of routers on a host

Status in OpenStack neutron-openvswitch charm:
  Invalid
Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in Ubuntu Cloud Archive pike series:
  Fix Released
Status in openvswitch package in Ubuntu:
  Fix Released
Status in openvswitch source package in Xenial:
  Fix Released
Status in openvswitch source package in Artful:
  Won't Fix
Status in openvswitch source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  OpenStack environments running large numbers of routers and dhcp agents on a 
single host can hit the NOFILES limit in OVS, resulting in broken operation of 
virtual networking.

  [Test Case]
  Deploy openstack environment; create large number of virtual networks and 
routers.
  OVS will start to error with 'Too many open files'

  [Regression Potential]
  Minimal - we're just increasing the NOFILE limit via the systemd service 
definition.

  [Original Bug Report]
  When there are a large number of routers and dhcp agents on a host, we see a 
syslog error repeated:

  "hostname ovs-vswitchd: ovs|1762125|netlink_socket|ERR|fcntl: Too many
  open files"

  If I check the number of filehandles owned by the pid for "ovs-
  vswitchd unix:/var/run/openvswitch/db.sock" I see close to/at 65535
  files.

  If I then run the following, we double the limit and (in our case) saw
  the count rise to >8:

  prlimit -p $pid --nofile=131070

  We need to be able to:
  - monitor via nrpe, if the process is running short on filehandles
  - configure the limit so we have the option to not run out.

  Currently, if I restart the process, we'll lose this setting.

  Needless to say, openvswitch running out of filehandles causes all
  manner of problems for services which use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1737866/+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 1788103] Re: [SRU] openvswitch 2.5.5

2018-10-08 Thread James Page 
This bug was fixed in the package openvswitch - 2.5.5-0ubuntu0.16.04.1~cloud0
---

 openvswitch (2.5.5-0ubuntu0.16.04.1~cloud0) trusty-mitaka; urgency=medium
 .
   * New upstream release for the Ubuntu Cloud Archive.
 .
 openvswitch (2.5.5-0ubuntu0.16.04.1) xenial; urgency=medium
 .
   * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
   * d/watch: Update for upstream website changes.
   * New upstream point release (LP: #1788103).
   * d/p/CVE-2017-9214.patch: Dropped, included upstream.


** Changed in: cloud-archive/mitaka
   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/1788103

Title:
  [SRU] openvswitch 2.5.5

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in openvswitch package in Ubuntu:
  Invalid
Status in openvswitch source package in Xenial:
  Fix Released

Bug description:
  
  [Impact]
  This release sports mostly bug-fixes and we would like to make sure all of 
our supported customers have access to these improvements.

  The update contains the following package updates:

 * openvswitch 2.5.5

  [Test Case]
  The following SRU process was followed:

  https://wiki.ubuntu.com/OpenStackUpdates

  In order to avoid regression of existing consumers, the OpenStack team will
  run their continuous integration test against the packages that are in
  -proposed. A successful run of all available tests will be required before the
  proposed packages can be let into -updates.

  The OpenStack team will be in charge of attaching the output summary of the
  executed tests. The OpenStack team members will not mark ‘verification-done’ 
until
  this has happened.

  [Regression Potential]
  In order to mitigate the regression potential, the results of the
  aforementioned tests are attached to this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1788103/+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 1338482] Re: Synaptic backend doesn't work in apturl

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package apturl - 0.5.2ubuntu14.2

---
apturl (0.5.2ubuntu14.2) bionic; urgency=medium

  * Also switch from gksu to pkexec, making Synaptic backend really,
*really* work (LP: #1338482)

 -- Vlad Orlov   Wed, 26 Sep 2018 17:08:54 +1000

** Changed in: apturl (Ubuntu Bionic)
   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/1338482

Title:
  Synaptic backend doesn't work in apturl

Status in apturl package in Ubuntu:
  Fix Released
Status in apturl source package in Trusty:
  Fix Released
Status in apturl source package in Xenial:
  Fix Released
Status in apturl source package in Bionic:
  Fix Released

Bug description:
  [Impact]

  The Synaptic backend in apturl is non-functional. Trying to use it makes
  apturl crash with Python error message.

  The fix for this issue is provided in the debdiffs attached to the
  report.

  It's a long-standing bug which is present in all current Ubuntu releases,
  starting from Trusty. Would be nice to get it finally fixed. A non-working
  backend isn't good at all, especially when the only other backend (aptdaemon)
  might be removed soon, as stated in bug 1673258.

  [Test Case]

  The easiest way to make apturl use the Synaptic backend (without removing
  aptdaemon from the system) is to set the environment variable when launching
  it from the terminal:

  $ UPDATE_MANAGER_FORCE_BACKEND_SYNAPTIC=1 apturl apt://gnome-
  calculator

  You can use any other package which isn't installed. I chose gnome-calculator
  as it wasn't installed in my Xubuntu and Ubuntu MATE systems.

  The result of this will be crash of apturl with Python error message.
  The package won't be installed.

  [Regression Potential]

  The patch only affects the Synaptic backend. It doesn't affect aptdaemon
  backend or any other parts of code. Since the Synaptic backend was broken
  before, it's not possible to break it further with some regression.

  [Original Description]

  System: Xubuntu 14.10
  apturl version: 0.5.2ubuntu4

  If you'll tell apturl to use the Synaptic backend (by either removing
  aptdaemon from the system or specifying
  UPDATE_MANAGER_FORCE_BACKEND_SYNAPTIC=1 before apturl in the
  terminal), it crashes with this error:

  $ UPDATE_MANAGER_FORCE_BACKEND_SYNAPTIC=1 apturl apt://gcalctool
  /usr/lib/python3/dist-packages/AptUrl/gtk/GtkUI.py:4: PyGIDeprecationWarning: 
Since version 3.11, calling threads_init is no longer needed. See: 
https://wiki.gnome.org/PyGObject/Threading
    GObject.threads_init()
  Traceback (most recent call last):
    File "/usr/bin/apturl-gtk", line 43, in 
  ui = GtkUI()
    File "/usr/lib/python3/dist-packages/AptUrl/gtk/GtkUI.py", line 38, in 
__init__
  self.backend = get_backend(self.dia)
    File "/usr/lib/python3/dist-packages/AptUrl/gtk/backend/__init__.py", line 
49, in get_backend
  return InstallBackendSynaptic(*args, **kwargs)
  TypeError: __init__() missing 1 required positional argument: 'action'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1338482/+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 1792905] Re: [2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package cloud-initramfs-tools - 0.40ubuntu1.1

---
cloud-initramfs-tools (0.40ubuntu1.1) bionic; urgency=medium

  [ Robert Jennings ]
  * copymods: Take ownership of lib/modules (LP: #1792905)
  * debian/control: Update Vcs-* to point to git.

 -- Scott Moser   Thu, 20 Sep 2018 09:29:41 -0400

** Changed in: cloud-initramfs-tools (Ubuntu Bionic)
   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/1792905

Title:
  [2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds

Status in cloud-images:
  Triaged
Status in MAAS:
  Invalid
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in open-iscsi package in Ubuntu:
  Confirmed
Status in cloud-initramfs-tools source package in Xenial:
  Fix Committed
Status in livecd-rootfs source package in Xenial:
  Invalid
Status in open-iscsi source package in Xenial:
  Confirmed
Status in cloud-initramfs-tools source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Fix Released
Status in open-iscsi source package in Bionic:
  Confirmed
Status in cloud-initramfs-tools source package in Cosmic:
  Fix Released
Status in livecd-rootfs source package in Cosmic:
  Fix Released
Status in open-iscsi source package in Cosmic:
  Confirmed

Bug description:
  [Impact]

   * Affects environments where the base image is read-only but kernel
  modules are copied from the initramfs to the real root via cloud-
  initramfs-copymods package.

   * This affects users of our stable release images available from http
  ://cloud-images.ubuntu.com.

   * The attached fixes ensure /lib/modules always exists by creating it
  explicitly instead of relying on it to come from a package.

  [Test Case]

   * Download http://cloud-images.ubuntu.com/bionic/current/bionic-
  server-cloudimg-amd64.squashfs

   * Unpack it via `sudo unsquashfs bionic-server-cloudimg-
  amd64.squashfs`

   * Inspect the unpacked root filesystem and find that '/lib/modules'
  is missing.

   * Install local build scripts as described at
  https://github.com/chrisglass/ubuntu-old-fashioned (note: you will
  need ubuntu-old-fashioned master for cosmic)

  * Re-build the images using the updated livecd-rootfs package.

  * Unpack the resulting livecd.ubuntu-cpc.squashfs artifact using
  unsquashfs again.

  * Inspect the unpacked root filesystem and find that '/lib/modules'
  exists.

  * It is pure luck that package purges which are done analogously in
  Cosmic image builds do not remove '/lib/modules', hence this fix is
  introduced there, as well.

  * Xenial is not affected.

  * Test builds were carried out for Cosmic and Bionic with the expected
  results.

  [Regression Potential]

   * This is a fix to a regression. The existence of the directory had
  previously been ensured, but the mkdir call got lost in recent re-
  factoring. See also:

  https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/bionic-
  proposed/revision/1678

  https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-
  rootfs/trunk/revision/1681

   * Packaging tools should not take offense at the existence of a
  directory, even if it was not part of a package. So potential for
  unforseeable regressions is very low.

  ===ORIGINAL BUG DESCRIPTION===

  Let me first start with saying MAAS is *not* using iSCSI anymore and
  is *NOT* in this case either.

  For some reason now using enlistment, commissioning, and deploying the
  ephemeral environment will block for 1 min 30 seconds waiting for the
  iSCSI daemon to succeed, which it never does.

  This increases the boot time drastically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1792905/+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 1788103] Re: [SRU] openvswitch 2.5.5

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package openvswitch - 2.5.5-0ubuntu0.16.04.1

---
openvswitch (2.5.5-0ubuntu0.16.04.1) xenial; urgency=medium

  * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
  * d/watch: Update for upstream website changes.
  * New upstream point release (LP: #1788103).
  * d/p/CVE-2017-9214.patch: Dropped, included upstream.

 -- James Page   Wed, 22 Aug 2018 09:36:55 +0100

** Changed in: openvswitch (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-9214

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

Title:
  [SRU] openvswitch 2.5.5

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in openvswitch package in Ubuntu:
  Invalid
Status in openvswitch source package in Xenial:
  Fix Released

Bug description:
  
  [Impact]
  This release sports mostly bug-fixes and we would like to make sure all of 
our supported customers have access to these improvements.

  The update contains the following package updates:

 * openvswitch 2.5.5

  [Test Case]
  The following SRU process was followed:

  https://wiki.ubuntu.com/OpenStackUpdates

  In order to avoid regression of existing consumers, the OpenStack team will
  run their continuous integration test against the packages that are in
  -proposed. A successful run of all available tests will be required before the
  proposed packages can be let into -updates.

  The OpenStack team will be in charge of attaching the output summary of the
  executed tests. The OpenStack team members will not mark ‘verification-done’ 
until
  this has happened.

  [Regression Potential]
  In order to mitigate the regression potential, the results of the
  aforementioned tests are attached to this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1788103/+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 1338482] Re: Synaptic backend doesn't work in apturl

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package apturl - 0.5.2ubuntu11.2

---
apturl (0.5.2ubuntu11.2) xenial; urgency=medium

  * Make Synaptic backend actually work (LP: #1338482).

 -- Vlad Orlov   Sat, 23 Sep 2017 13:55:22 +0300

** Changed in: apturl (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

** Changed in: apturl (Ubuntu Trusty)
   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/1338482

Title:
  Synaptic backend doesn't work in apturl

Status in apturl package in Ubuntu:
  Fix Released
Status in apturl source package in Trusty:
  Fix Released
Status in apturl source package in Xenial:
  Fix Released
Status in apturl source package in Bionic:
  Fix Released

Bug description:
  [Impact]

  The Synaptic backend in apturl is non-functional. Trying to use it makes
  apturl crash with Python error message.

  The fix for this issue is provided in the debdiffs attached to the
  report.

  It's a long-standing bug which is present in all current Ubuntu releases,
  starting from Trusty. Would be nice to get it finally fixed. A non-working
  backend isn't good at all, especially when the only other backend (aptdaemon)
  might be removed soon, as stated in bug 1673258.

  [Test Case]

  The easiest way to make apturl use the Synaptic backend (without removing
  aptdaemon from the system) is to set the environment variable when launching
  it from the terminal:

  $ UPDATE_MANAGER_FORCE_BACKEND_SYNAPTIC=1 apturl apt://gnome-
  calculator

  You can use any other package which isn't installed. I chose gnome-calculator
  as it wasn't installed in my Xubuntu and Ubuntu MATE systems.

  The result of this will be crash of apturl with Python error message.
  The package won't be installed.

  [Regression Potential]

  The patch only affects the Synaptic backend. It doesn't affect aptdaemon
  backend or any other parts of code. Since the Synaptic backend was broken
  before, it's not possible to break it further with some regression.

  [Original Description]

  System: Xubuntu 14.10
  apturl version: 0.5.2ubuntu4

  If you'll tell apturl to use the Synaptic backend (by either removing
  aptdaemon from the system or specifying
  UPDATE_MANAGER_FORCE_BACKEND_SYNAPTIC=1 before apturl in the
  terminal), it crashes with this error:

  $ UPDATE_MANAGER_FORCE_BACKEND_SYNAPTIC=1 apturl apt://gcalctool
  /usr/lib/python3/dist-packages/AptUrl/gtk/GtkUI.py:4: PyGIDeprecationWarning: 
Since version 3.11, calling threads_init is no longer needed. See: 
https://wiki.gnome.org/PyGObject/Threading
    GObject.threads_init()
  Traceback (most recent call last):
    File "/usr/bin/apturl-gtk", line 43, in 
  ui = GtkUI()
    File "/usr/lib/python3/dist-packages/AptUrl/gtk/GtkUI.py", line 38, in 
__init__
  self.backend = get_backend(self.dia)
    File "/usr/lib/python3/dist-packages/AptUrl/gtk/backend/__init__.py", line 
49, in get_backend
  return InstallBackendSynaptic(*args, **kwargs)
  TypeError: __init__() missing 1 required positional argument: 'action'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apturl/+bug/1338482/+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 1781364] Re: Kernel error "task zfs:pid blocked for more than 120 seconds"

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package zfs-linux - 0.6.5.6-0ubuntu25

---
zfs-linux (0.6.5.6-0ubuntu25) xenial; urgency=medium

  * Fix zpl_mount() deadlock (LP: #1781364)
- Upstream ZFS fix ac09630d8b0b ("Fix zpl_mount() deadlock")
  fixes deadlock on multiple parallelized mount/umounts

 -- Colin Ian King   Thu, 12 Jul 2018 09:18:24
+0100

** Changed in: zfs-linux (Ubuntu Xenial)
   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/1781364

Title:
  Kernel error "task zfs:pid blocked for more than 120 seconds"

Status in Linux:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in zfs-linux source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in zfs-linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in zfs-linux source package in Cosmic:
  Fix Released

Bug description:
  == SRU Justification, XENIAL, BIONIC ==

  Exercising ZFS with lxd with many mount/umounts can cause lockups and
  120 second timeout messages.

  == How to reproduce bug ==

  In a VM, 2 CPUs, 16GB of memory running Bionic:

  sudo apt update
  sudo apt install lxd lxd-client lxd-tools zfsutils-linux
  sudo lxd init

  (and with the default init options)

  then run:

  lxd-benchmark launch --count 96 --parallel 96

  This will reliably show the lockup every time without the fix.  With
  the fix (detailed below) one cannot reproduce the lockup.

  == Fix ==

  Upstream ZFS commit

  commit ac09630d8b0bf6c92084a30fdaefd03fd0adbdc1
  Author: Brian Behlendorf 
  Date: Wed Jul 11 15:49:10 2018 -0700

  Fix zpl_mount() deadlock

  == Regression Potential ==

  This just changes the locking in the mount path of ZFS and will only
  affect ZFS mount/unmounts.  The regression potential is small as this
  touches a very small code path that has been exhaustively exercises
  this code under multiple thread/CPU contention and shown not to break.

  --

  ZFS bug report: https://github.com/zfsonlinux/zfs/issues/7691

  "I am using LXD containers that are configured to use a ZFS storage backend.
  I create many containers using a benchmark tool, which probably stresses the 
use of ZFS.
  In two out of four attempts, I got

  [  725.970508] INFO: task lxd:4455 blocked for more than 120 seconds.
  [  725.976730]   Tainted: P   O 4.15.0-20-generic #21-Ubuntu
  [  725.983551] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [  725.991624] INFO: task txg_sync:4202 blocked for more than 120 seconds.
  [  725.998264]   Tainted: P   O 4.15.0-20-generic #21-Ubuntu
  [  726.005071] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [  726.013313] INFO: task lxd:99919 blocked for more than 120 seconds.
  [  726.019609]   Tainted: P   O 4.15.0-20-generic #21-Ubuntu
  [  726.026418] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [  726.034560] INFO: task zfs:100513 blocked for more than 120 seconds.
  [  726.040936]   Tainted: P   O 4.15.0-20-generic #21-Ubuntu
  [  726.047746] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.
  [  726.055791] INFO: task zfs:100584 blocked for more than 120 seconds.
  [  726.062170]   Tainted: P   O 4.15.0-20-generic #21-Ubuntu
  [  726.068979] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.

  Describe how to reproduce the problem

  Start an Ubuntu 18.04 LTS server.
  Install LXD if not already installed.

  sudo apt update
  sudo apt install lxd lxd-client lxd-tools zfsutils-linux

  Configure LXD with sudo lxd init. When prompted for the storage
  backend, select ZFS and specify an empty disk.

  $ sudo lxd init
  Would you like to use LXD clustering? (yes/no) [default=no]:
   Do you want to configure a new storage pool? (yes/no) [default=yes]:
   Name of the new storage pool [default=default]:
   Name of the storage backend to use (dir, zfs) [default=zfs]:
   Create a new ZFS pool? (yes/no) [default=yes]:
   Would you like to use an existing block device? (yes/no) [default=no]: yes
   Path to the existing block device: /dev/sdb
   Would you like to connect to a MAAS server? (yes/no) [default=no]:
   Would you like to create a new local network bridge? (yes/no) [default=yes]: 
no
   Would you like to configure LXD to use an existing bridge or host interface? 
(yes/no) [default=no]: no
   Would you like LXD to be available over the network? (yes/no) [default=no]:
   Would you like stale cached images to be updated automatically?

[Group.of.nepali.translators] [Bug 1792905] Re: [2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds

2018-10-08 Thread Launchpad Bug Tracker 
This bug was fixed in the package cloud-initramfs-tools - 0.27ubuntu1.6

---
cloud-initramfs-tools (0.27ubuntu1.6) xenial; urgency=medium

  [ Robert Jennings ]
  * copymods: Take ownership of lib/modules (LP: #1792905)
  * debian/control: Update Vcs-* to point to git.

 -- Scott Moser   Thu, 20 Sep 2018 09:39:52 -0400

** Changed in: cloud-initramfs-tools (Ubuntu Xenial)
   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/1792905

Title:
  [2.5] iSCSI systemd services fails and blocks for 1 min 30 seconds

Status in cloud-images:
  Triaged
Status in MAAS:
  Invalid
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in open-iscsi package in Ubuntu:
  Confirmed
Status in cloud-initramfs-tools source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Invalid
Status in open-iscsi source package in Xenial:
  Confirmed
Status in cloud-initramfs-tools source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Fix Released
Status in open-iscsi source package in Bionic:
  Confirmed
Status in cloud-initramfs-tools source package in Cosmic:
  Fix Released
Status in livecd-rootfs source package in Cosmic:
  Fix Released
Status in open-iscsi source package in Cosmic:
  Confirmed

Bug description:
  [Impact]

   * Affects environments where the base image is read-only but kernel
  modules are copied from the initramfs to the real root via cloud-
  initramfs-copymods package.

   * This affects users of our stable release images available from http
  ://cloud-images.ubuntu.com.

   * The attached fixes ensure /lib/modules always exists by creating it
  explicitly instead of relying on it to come from a package.

  [Test Case]

   * Download http://cloud-images.ubuntu.com/bionic/current/bionic-
  server-cloudimg-amd64.squashfs

   * Unpack it via `sudo unsquashfs bionic-server-cloudimg-
  amd64.squashfs`

   * Inspect the unpacked root filesystem and find that '/lib/modules'
  is missing.

   * Install local build scripts as described at
  https://github.com/chrisglass/ubuntu-old-fashioned (note: you will
  need ubuntu-old-fashioned master for cosmic)

  * Re-build the images using the updated livecd-rootfs package.

  * Unpack the resulting livecd.ubuntu-cpc.squashfs artifact using
  unsquashfs again.

  * Inspect the unpacked root filesystem and find that '/lib/modules'
  exists.

  * It is pure luck that package purges which are done analogously in
  Cosmic image builds do not remove '/lib/modules', hence this fix is
  introduced there, as well.

  * Xenial is not affected.

  * Test builds were carried out for Cosmic and Bionic with the expected
  results.

  [Regression Potential]

   * This is a fix to a regression. The existence of the directory had
  previously been ensured, but the mkdir call got lost in recent re-
  factoring. See also:

  https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/bionic-
  proposed/revision/1678

  https://bazaar.launchpad.net/~ubuntu-core-dev/livecd-
  rootfs/trunk/revision/1681

   * Packaging tools should not take offense at the existence of a
  directory, even if it was not part of a package. So potential for
  unforseeable regressions is very low.

  ===ORIGINAL BUG DESCRIPTION===

  Let me first start with saying MAAS is *not* using iSCSI anymore and
  is *NOT* in this case either.

  For some reason now using enlistment, commissioning, and deploying the
  ephemeral environment will block for 1 min 30 seconds waiting for the
  iSCSI daemon to succeed, which it never does.

  This increases the boot time drastically.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1792905/+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 1737866] Re: Too many open files when large number of routers on a host

2018-10-08 Thread James Page 
This bug was fixed in the package openvswitch - 2.8.4-0ubuntu0.17.10.1
---

 openvswitch (2.8.4-0ubuntu0.17.10.1) xenial; urgency=medium
 .
   * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
   * New upstream point release (LP: #1787519):
 - d/p/s390x-stp-timeout.patch: Dropped, equivalent
   change upstream.


** Changed in: cloud-archive/pike
   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/1737866

Title:
  Too many open files when large number of routers on a host

Status in OpenStack neutron-openvswitch charm:
  Invalid
Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in Ubuntu Cloud Archive pike series:
  Fix Released
Status in openvswitch package in Ubuntu:
  Fix Released
Status in openvswitch source package in Xenial:
  Fix Committed
Status in openvswitch source package in Artful:
  Won't Fix
Status in openvswitch source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  OpenStack environments running large numbers of routers and dhcp agents on a 
single host can hit the NOFILES limit in OVS, resulting in broken operation of 
virtual networking.

  [Test Case]
  Deploy openstack environment; create large number of virtual networks and 
routers.
  OVS will start to error with 'Too many open files'

  [Regression Potential]
  Minimal - we're just increasing the NOFILE limit via the systemd service 
definition.

  [Original Bug Report]
  When there are a large number of routers and dhcp agents on a host, we see a 
syslog error repeated:

  "hostname ovs-vswitchd: ovs|1762125|netlink_socket|ERR|fcntl: Too many
  open files"

  If I check the number of filehandles owned by the pid for "ovs-
  vswitchd unix:/var/run/openvswitch/db.sock" I see close to/at 65535
  files.

  If I then run the following, we double the limit and (in our case) saw
  the count rise to >8:

  prlimit -p $pid --nofile=131070

  We need to be able to:
  - monitor via nrpe, if the process is running short on filehandles
  - configure the limit so we have the option to not run out.

  Currently, if I restart the process, we'll lose this setting.

  Needless to say, openvswitch running out of filehandles causes all
  manner of problems for services which use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1737866/+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 1737866] Re: Too many open files when large number of routers on a host

2018-10-08 Thread James Page 
This bug was fixed in the package openvswitch - 2.6.3-0ubuntu0.17.04.1~cloud0
---

 openvswitch (2.6.3-0ubuntu0.17.04.1~cloud0) xenial; urgency=medium
 .
   * Bump nofiles to 1048576 for ovs daemons (LP: #1737866).
   * d/watch: Fix watchfile for upstream website changes.
   * New upstream point release (LP: #1787599).
 - d/p/CVE-2017-9214.patch,CVE-2017-9264.patch,CVE-2017-9265.patch:
   Dropped, included in upstream release.


** Changed in: cloud-archive/ocata
   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/1737866

Title:
  Too many open files when large number of routers on a host

Status in OpenStack neutron-openvswitch charm:
  Invalid
Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in Ubuntu Cloud Archive pike series:
  Fix Released
Status in openvswitch package in Ubuntu:
  Fix Released
Status in openvswitch source package in Xenial:
  Fix Committed
Status in openvswitch source package in Artful:
  Won't Fix
Status in openvswitch source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  OpenStack environments running large numbers of routers and dhcp agents on a 
single host can hit the NOFILES limit in OVS, resulting in broken operation of 
virtual networking.

  [Test Case]
  Deploy openstack environment; create large number of virtual networks and 
routers.
  OVS will start to error with 'Too many open files'

  [Regression Potential]
  Minimal - we're just increasing the NOFILE limit via the systemd service 
definition.

  [Original Bug Report]
  When there are a large number of routers and dhcp agents on a host, we see a 
syslog error repeated:

  "hostname ovs-vswitchd: ovs|1762125|netlink_socket|ERR|fcntl: Too many
  open files"

  If I check the number of filehandles owned by the pid for "ovs-
  vswitchd unix:/var/run/openvswitch/db.sock" I see close to/at 65535
  files.

  If I then run the following, we double the limit and (in our case) saw
  the count rise to >8:

  prlimit -p $pid --nofile=131070

  We need to be able to:
  - monitor via nrpe, if the process is running short on filehandles
  - configure the limit so we have the option to not run out.

  Currently, if I restart the process, we'll lose this setting.

  Needless to say, openvswitch running out of filehandles causes all
  manner of problems for services which use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1737866/+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