[Group.of.nepali.translators] [Bug 1592731] Re: bzr fails to build in xenial

[Steve Langasek]

** Changed in: bzr (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/1592731

Title:
  bzr fails to build in xenial

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

Bug description:
  bzr fails to build in xenial with the paramiko version in xenial;
  already fixed in yakkety.

  ==
  ERROR: 
bzrlib.tests.test_sftp_transport.SSHVendorConnection.test_connection_paramiko
  --
  Traceback (most recent call last):
  testtools.testresult.real._StringException: log: {{{
  DEBUG  [chan bzr SocketAsChannelAdapter] Started sftp server on channel 

 DEBUG  [chan bzr SocketAsChannelAdapter] Request: open
 DEBUG  [chan bzr SocketAsChannelAdapter] Request: close
 DEBUG  [chan bzr SocketAsChannelAdapter] EOF -- end of session
  }}}

  Traceback (most recent call last):
File 
"/«PKGBUILDDIR»/build/lib.linux-ppc64le-2.7/bzrlib/tests/test_sftp_transport.py",
 line 253, in test_connection_paramiko
  self.assertEqual('foobar\n', t.get('a_file').read())
File "/«PKGBUILDDIR»/build/lib.linux-ppc64le-2.7/bzrlib/transport/sftp.py", 
line 414, in get
  f.prefetch()
  TypeError: prefetch() takes exactly 2 arguments (1 given)

  --
  Ran 28545 tests in 453.901s

  FAILED (errors=116, known_failure_count=59)
  2648 tests skipped
  debian/rules:21: recipe for target 'override_dh_auto_test' failed
  make[1]: Leaving directory '/«PKGBUILDDIR»'
  debian/rules:13: recipe for target 'build-arch' failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/1592731/+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 1682102] Re: libseccomp should support GA and HWE kernels

[Launchpad Bug Tracker]

This bug was fixed in the package libseccomp - 2.3.1-2.1ubuntu2~16.04.1

---
libseccomp (2.3.1-2.1ubuntu2~16.04.1) xenial; urgency=medium

  * Backport libseccomp 2.3.1 to xenial LP: #1682102
- Improved s390x support
- Improved support for v4.5+ kernels

 -- Dimitri John Ledkov   Fri, 06 Oct 2017 14:47:39
+0100

** Changed in: libseccomp (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/1682102

Title:
  libseccomp should support GA and HWE kernels

Status in libseccomp package in Ubuntu:
  Invalid
Status in libseccomp source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  out of date libseccomp w.r.t. custom and hwe kernels provides sub-par 
userspace protection, which is otherwise available on the running kernel and 
hardware combination.
  This results in subpar security of systems running new architectures (s390x & 
ppc64el) and newer hwe/custom kernels.

  * Version 2.3.1 - April 20, 2016
  - Fixed a problem with 32-bit x86 socket syscalls on some systems
  - Fixed problems with ipc syscalls on 32-bit x86
  - Fixed problems with socket and ipc syscalls on s390 and s390x

  * Version 2.3.0 - February 29, 2016
  - Added support for the s390 and s390x architectures
  - Added support for the ppc, ppc64, and ppc64le architectures
  - Update the internal syscall tables to match the Linux 4.5-rcX releases
  - Filter generation for both multiplexed and direct socket syscalls on x86
  - Support for the musl libc implementation
  - Additions to the API to enable runtime version checking of the library
  - Enable the use of seccomp() instead of prctl() on supported systems
  - Added additional tests to the regression test suite

  There is no ABI/API break

  There are no packaging changes, apart from dropping patches included
  in this upstream release and updating new symbols.

  Doing wholesome update is safer and carries less risk, than
  individually cherrypicking effectively all of the above.

  This is a backport to an LTS release under the banner of safe
  introduction of new features and new hardware support.

  It is expected that container technologies will take advantage of the
  newly available libseccomp.

  This may need to be uploaded as a security update.

  Currently, s390x support in xenial libssecomp is incomplete. And there
  are v4.5+ syscall tables missing as used by hwe kernels and some
  custom kernels.

  [Testcase]
  Validate that all main contianer technologies are operational and do not 
regress, e.g.:
   - lxc
   - lxd
   - docker
   - snapd

  [Regression Potential]
  Userspace components may detect at runtime newly available libseccomp, and 
thus restrict user-space processes more than previously done. This may lead to 
a change of restrictions applied on the user sapce processes, and result in 
previously unexpected denials / errors returned.

  
  [Proposed Update available in bileto PPA]
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2981

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1682102/+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 1715254] Re: nova-novncproxy process gets wedged, requiring kill -HUP

[Corey Bryant]

This bug was fixed in the package websockify - 0.6.0+dfsg1-1~cloud2
---

 websockify (0.6.0+dfsg1-1~cloud2) trusty-kilo; urgency=medium
 .
   * Fix hanging nova-novncproxy and can't be restarted (LP: #1715254)
 - [PATCH] Make websockify respect SIGTERM
 - [PATCH] Remove additional signal calls in websockify that
   causes novnc to hang.


** Changed in: cloud-archive/kilo
   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/1715254

Title:
  nova-novncproxy process gets wedged, requiring kill -HUP

Status in OpenStack nova-cloud-controller charm:
  Invalid
Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive kilo series:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Released
Status in websockify package in Ubuntu:
  Invalid
Status in websockify source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  affected
  - UCA Mitaka, Kilo
  - Xenial

  not affected
  - UCA Icehouse
  - Trusty
  ( log symptom is different, there is no reaing(which is errata) zombie... etc)

  When number of connections are many or frequently reconnecting to
  console, nova-novncproxy daemon is stuck because websockify is hang.

  [Test case]

  1. Deploy openstack
  2. Creating instances
  3. open console in browser with auto refresh extension ( set 5 seconds )
  4. after several hours connection rejected

  [Regression Potential]

  Components that using websockify, escpecially nova-novncproxy, will be
  affected by this patch. However, After upgrading this and refreshing
  test above mentioned for 2 days without restarting any services, no
  hang happens. I tested this test in my local simple environment, so
  need to be considered possibility in different circumstances.

  [Others]

  related commits

  - https://github.com/novnc/websockify/pull/226
  - https://github.com/novnc/websockify/pull/219

  [Original Description]

  Users reported they were unable to connect to instance consoles via
  either Horizon or direct URL. Upon investigation we found errors
  suggesting the address and port were in use:

  2017-08-23 14:51:56.248 1355081 INFO nova.console.websocketproxy [-] 
WebSocket server settings:
  2017-08-23 14:51:56.248 1355081 INFO nova.console.websocketproxy [-]   - 
Listen on 0.0.0.0:6080
  2017-08-23 14:51:56.248 1355081 INFO nova.console.websocketproxy [-]   - 
Flash security policy server
  2017-08-23 14:51:56.248 1355081 INFO nova.console.websocketproxy [-]   - Web 
server (no directory listings). Web root: /usr/share/novnc
  2017-08-23 14:51:56.248 1355081 INFO nova.console.websocketproxy [-]   - No 
SSL/TLS support (no cert file)
  2017-08-23 14:51:56.249 1355081 CRITICAL nova [-] error: [Errno 98] Address 
already in use
  2017-08-23 14:51:56.249 1355081 ERROR nova Traceback (most recent call last):
  2017-08-23 14:51:56.249 1355081 ERROR nova   File "/usr/bin/nova-novncproxy", 
line 10, in 
  2017-08-23 14:51:56.249 1355081 ERROR nova sys.exit(main())
  2017-08-23 14:51:56.249 1355081 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/cmd/novncproxy.py", line 41, in main
  2017-08-23 14:51:56.249 1355081 ERROR nova port=CONF.vnc.novncproxy_port)
  2017-08-23 14:51:56.249 1355081 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/nova/cmd/baseproxy.py", line 73, in proxy
  2017-08-23 14:51:56.249 1355081 ERROR nova 
RequestHandlerClass=websocketproxy.NovaProxyRequestHandler
  2017-08-23 14:51:56.249 1355081 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/websockify/websocket.py", line 909, in 
start_server
  2017-08-23 14:51:56.249 1355081 ERROR nova 
tcp_keepintvl=self.tcp_keepintvl)
  2017-08-23 14:51:56.249 1355081 ERROR nova   File 
"/usr/lib/python2.7/dist-packages/websockify/websocket.py", line 698, in socket
  2017-08-23 14:51:56.249 1355081 ERROR nova sock.bind(addrs[0][4])
  2017-08-23 14:51:56.249 1355081 ERROR nova   File 
"/usr/lib/python2.7/socket.py", line 224, in meth
  2017-08-23 14:51:56.249 1355081 ERROR nova return 
getattr(self._sock,name)(*args)
  2017-08-23 14:51:56.249 1355081 ERROR nova error: [Errno 98] Address already 
in use
  2017-08-23 14:51:56.249 1355081 ERROR nova

  This lead us to the discovery of a stuck nova-novncproxy process after
  stopping the service. Once we sent a kill -HUP to that process, we
  were able to start the nova-novncproxy and restore service to the
  users.

  This was not the first time we have had to restart nova-novncproxy
  services after users reported that were unable to connect with VNC.
  This time, as well as at least 2 other times, we have seen the
  following errors in the nova-novncproxy.log during the time frame of
  the issue:

  gaierror: [Errno -8] Servname not supported for ai_socktype

  which seems to correspond to a log entries 

[Group.of.nepali.translators] [Bug 1555305] Re: resquashfs test fails if snap has symlinks

[Launchpad Bug Tracker]

This bug was fixed in the package squashfs-tools -
1:4.3-3ubuntu2.16.04.1

---
squashfs-tools (1:4.3-3ubuntu2.16.04.1) xenial; urgency=medium

  * debian/patches/0007-unsquashfs-preserve-symlink-times.patch: Preserve
atime and mtime of symlink inodes in unsquashfs rather than using the
current time (LP: #1555305)

 -- Tyler Hicks   Mon, 11 Dec 2017 21:02:07 +

** Changed in: squashfs-tools (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/1555305

Title:
  resquashfs test fails if snap has symlinks

Status in click-reviewers-tools package in Ubuntu:
  Invalid
Status in squashfs-tools package in Ubuntu:
  Fix Released
Status in squashfs-tools source package in Trusty:
  Fix Released
Status in squashfs-tools source package in Xenial:
  Fix Released
Status in squashfs-tools source package in Zesty:
  Fix Released
Status in squashfs-tools source package in Artful:
  Fix Released
Status in squashfs-tools source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * The unsquashfs utility does not preserve atime and mtime timestamps
     of symlink inodes when unpacking squashfs images.

   * This makes it impossible to use a combination of unsquashfs and
     mksquashfs to sanity check snaps uploaded to the snap store since
     the resulting snap will not match the original snap due to symlink
     times being set to the current time when unsquashfs was executed.

  [Test Case]

   * Extract the test image:
 $ unsquashfs -d lp1555305 lp1555305.squashfs

   * Check the timestamp of the "link" file
 $ ls -al lp1555305/link

   * Incorrect output (timestamp will be current time):
 lrwxrwxrwx  1 tyhicks tyhicks4 Dec 11 22:05 link -> file

   * Expected output:
 lrwxrwxrwx 1 tyhicks tyhicks 4 Aug 25  1991 /tmp/lp1555305/link -> file

  [Regression Potential]

   * The regression potential is small as long as there is no software
     out there that depends on the behavior of setting symlink timestamps
     to the current time. I highly doubt that there is anything out there
     that relies on that behavior but there's always a chance.

  [Original Descipription]

  Create the files:
  $ mkdir test
  $ cd test
  $ touch foo
  $ ln -s foo bar
  $ mkdir meta
  $ cat >meta/snap.yaml 

[Group.of.nepali.translators] [Bug 1555305] Re: resquashfs test fails if snap has symlinks

[Launchpad Bug Tracker]

This bug was fixed in the package squashfs-tools -
1:4.3-3ubuntu2.17.04.1

---
squashfs-tools (1:4.3-3ubuntu2.17.04.1) zesty; urgency=medium

  * debian/patches/0007-unsquashfs-preserve-symlink-times.patch: Preserve
atime and mtime of symlink inodes in unsquashfs rather than using the
current time (LP: #1555305)

 -- Tyler Hicks   Mon, 11 Dec 2017 21:02:54 +

** Changed in: squashfs-tools (Ubuntu Zesty)
   Status: Fix Committed => Fix Released

** Changed in: squashfs-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/1555305

Title:
  resquashfs test fails if snap has symlinks

Status in click-reviewers-tools package in Ubuntu:
  Invalid
Status in squashfs-tools package in Ubuntu:
  Fix Released
Status in squashfs-tools source package in Trusty:
  Fix Released
Status in squashfs-tools source package in Xenial:
  Fix Released
Status in squashfs-tools source package in Zesty:
  Fix Released
Status in squashfs-tools source package in Artful:
  Fix Released
Status in squashfs-tools source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * The unsquashfs utility does not preserve atime and mtime timestamps
     of symlink inodes when unpacking squashfs images.

   * This makes it impossible to use a combination of unsquashfs and
     mksquashfs to sanity check snaps uploaded to the snap store since
     the resulting snap will not match the original snap due to symlink
     times being set to the current time when unsquashfs was executed.

  [Test Case]

   * Extract the test image:
 $ unsquashfs -d lp1555305 lp1555305.squashfs

   * Check the timestamp of the "link" file
 $ ls -al lp1555305/link

   * Incorrect output (timestamp will be current time):
 lrwxrwxrwx  1 tyhicks tyhicks4 Dec 11 22:05 link -> file

   * Expected output:
 lrwxrwxrwx 1 tyhicks tyhicks 4 Aug 25  1991 /tmp/lp1555305/link -> file

  [Regression Potential]

   * The regression potential is small as long as there is no software
     out there that depends on the behavior of setting symlink timestamps
     to the current time. I highly doubt that there is anything out there
     that relies on that behavior but there's always a chance.

  [Original Descipription]

  Create the files:
  $ mkdir test
  $ cd test
  $ touch foo
  $ ln -s foo bar
  $ mkdir meta
  $ cat >meta/snap.yaml 

[Group.of.nepali.translators] [Bug 1555305] Re: resquashfs test fails if snap has symlinks

[Launchpad Bug Tracker]

This bug was fixed in the package squashfs-tools - 1:4.3-4ubuntu1.1

---
squashfs-tools (1:4.3-4ubuntu1.1) artful; urgency=medium

  * debian/patches/0008-unsquashfs-preserve-symlink-times.patch: Preserve
atime and mtime of symlink inodes in unsquashfs rather than using the
current time (LP: #1555305)

 -- Tyler Hicks   Mon, 11 Dec 2017 20:51:14 +

** Changed in: squashfs-tools (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/1555305

Title:
  resquashfs test fails if snap has symlinks

Status in click-reviewers-tools package in Ubuntu:
  Invalid
Status in squashfs-tools package in Ubuntu:
  Fix Released
Status in squashfs-tools source package in Trusty:
  Fix Released
Status in squashfs-tools source package in Xenial:
  Fix Released
Status in squashfs-tools source package in Zesty:
  Fix Released
Status in squashfs-tools source package in Artful:
  Fix Released
Status in squashfs-tools source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * The unsquashfs utility does not preserve atime and mtime timestamps
     of symlink inodes when unpacking squashfs images.

   * This makes it impossible to use a combination of unsquashfs and
     mksquashfs to sanity check snaps uploaded to the snap store since
     the resulting snap will not match the original snap due to symlink
     times being set to the current time when unsquashfs was executed.

  [Test Case]

   * Extract the test image:
 $ unsquashfs -d lp1555305 lp1555305.squashfs

   * Check the timestamp of the "link" file
 $ ls -al lp1555305/link

   * Incorrect output (timestamp will be current time):
 lrwxrwxrwx  1 tyhicks tyhicks4 Dec 11 22:05 link -> file

   * Expected output:
 lrwxrwxrwx 1 tyhicks tyhicks 4 Aug 25  1991 /tmp/lp1555305/link -> file

  [Regression Potential]

   * The regression potential is small as long as there is no software
     out there that depends on the behavior of setting symlink timestamps
     to the current time. I highly doubt that there is anything out there
     that relies on that behavior but there's always a chance.

  [Original Descipription]

  Create the files:
  $ mkdir test
  $ cd test
  $ touch foo
  $ ln -s foo bar
  $ mkdir meta
  $ cat >meta/snap.yaml 

[Group.of.nepali.translators] [Bug 1681073] Re: Create Consistency Group form has an exception

[Corey Bryant]

This bug was fixed in the package horizon - 3:10.0.5-0ubuntu1~cloud2
---

 horizon (3:10.0.5-0ubuntu1~cloud2) xenial-newton; urgency=medium
 .
   * Fix create consistency group form exception (LP: #1681073)
 - d/p/fix_create_consistency_group_form_exception.patch


** Changed in: cloud-archive/newton
   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/1681073

Title:
  Create Consistency Group form has an exception

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive newton series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in horizon package in Ubuntu:
  Fix Released
Status in horizon source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  Affected
  - UCA Mitaka, Ocata
  - Xenial, Zesty ( Artful is incidentlly added, please ignore it) 

  After enabling consistency groups by changing api-paste.ini,

  When trying to create consistency group, there are error like below.

  Exception info:
  Internal Server Error: /project/cgroups/create/
  Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", 
line 132, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 52, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 84, in dec
  return view_func(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 71, in view
  return self.dispatch(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 89, in dispatch
  return handler(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/workflows/views.py", line 199, in post
  exceptions.handle(request)
    File "/opt/stack/horizon/horizon/exceptions.py", line 352, in handle
  six.reraise(exc_type, exc_value, exc_traceback)
    File "/opt/stack/horizon/horizon/workflows/views.py", line 194, in post
  success = workflow.finalize()
    File "/opt/stack/horizon/horizon/workflows/base.py", line 824, in finalize
  if not self.handle(self.request, self.context):
    File 
"/opt/stack/horizon/openstack_dashboard/dashboards/project/cgroups/workflows.py",
 line 323, in handle
  vol_type.extra_specs['volume_backend_name']
  KeyError: 'volume_backend_name'

  [Test case]

  juju deploy bundle

  (this is same as original description)
  1. Go to admin/volume types panel
  2. Create volume type with any name
  3. Go to project/Consistency Groups panel
  4. Create Consistency Group and add the volume type we just created
  5. Submit Create Consistency Group form

  [Regression Potential]
  This changes horizon UI, and need to restart apache2 server. There could be 
very short outage for openstack dashboard. but this seems not critical to 
openstack service. and if there is code error, django server can't be started 
and outage time could be longer than above.

  [Others]

  upstream commit
  
https://git.openstack.org/cgit/openstack/horizon/commit/?id=89bb9268204a2316fc526d660f38d5517980f209

  [Original Description]

  Env: devstack master branch

  Steps to reproduce:
  1. Go to admin/volume types panel
  2. Create volume type with any name
  3. Go to project/Consistency Groups panel
  4. Create Consistency Group and add the volume type we just created
  5. Submit Create Consistency Group form

  it will throws an exception.

  Exception info:
  Internal Server Error: /project/cgroups/create/
  Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", 
line 132, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 52, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 84, in dec
  return view_func(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 71, in view
  

[Group.of.nepali.translators] [Bug 1681073] Re: Create Consistency Group form has an exception

[Corey Bryant]

This bug was fixed in the package horizon - 3:11.0.4-0ubuntu1~cloud1
---

 horizon (3:11.0.4-0ubuntu1~cloud1) xenial-ocata; urgency=medium
 .
   * Fix create consistency group form exception (LP: #1681073)
 - d/p/fix_create_consistency_group_form_exception.patch


** 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/1681073

Title:
  Create Consistency Group form has an exception

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Fix Committed
Status in Ubuntu Cloud Archive newton series:
  Fix Released
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in horizon package in Ubuntu:
  Fix Released
Status in horizon source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  Affected
  - UCA Mitaka, Ocata
  - Xenial, Zesty ( Artful is incidentlly added, please ignore it) 

  After enabling consistency groups by changing api-paste.ini,

  When trying to create consistency group, there are error like below.

  Exception info:
  Internal Server Error: /project/cgroups/create/
  Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", 
line 132, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 52, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 84, in dec
  return view_func(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 71, in view
  return self.dispatch(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 89, in dispatch
  return handler(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/workflows/views.py", line 199, in post
  exceptions.handle(request)
    File "/opt/stack/horizon/horizon/exceptions.py", line 352, in handle
  six.reraise(exc_type, exc_value, exc_traceback)
    File "/opt/stack/horizon/horizon/workflows/views.py", line 194, in post
  success = workflow.finalize()
    File "/opt/stack/horizon/horizon/workflows/base.py", line 824, in finalize
  if not self.handle(self.request, self.context):
    File 
"/opt/stack/horizon/openstack_dashboard/dashboards/project/cgroups/workflows.py",
 line 323, in handle
  vol_type.extra_specs['volume_backend_name']
  KeyError: 'volume_backend_name'

  [Test case]

  juju deploy bundle

  (this is same as original description)
  1. Go to admin/volume types panel
  2. Create volume type with any name
  3. Go to project/Consistency Groups panel
  4. Create Consistency Group and add the volume type we just created
  5. Submit Create Consistency Group form

  [Regression Potential]
  This changes horizon UI, and need to restart apache2 server. There could be 
very short outage for openstack dashboard. but this seems not critical to 
openstack service. and if there is code error, django server can't be started 
and outage time could be longer than above.

  [Others]

  upstream commit
  
https://git.openstack.org/cgit/openstack/horizon/commit/?id=89bb9268204a2316fc526d660f38d5517980f209

  [Original Description]

  Env: devstack master branch

  Steps to reproduce:
  1. Go to admin/volume types panel
  2. Create volume type with any name
  3. Go to project/Consistency Groups panel
  4. Create Consistency Group and add the volume type we just created
  5. Submit Create Consistency Group form

  it will throws an exception.

  Exception info:
  Internal Server Error: /project/cgroups/create/
  Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", 
line 132, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 52, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 84, in dec
  return view_func(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 71, in view
  return 

[Group.of.nepali.translators] [Bug 1738412] Re: Init script fails test on reload/restart because of faulty regex

[Robie Basak]

Tommy, thank you for bringing our attention to this.

It looks like this issue *is* fixed in the current stable Ubuntu
release. Perhaps you were looking at the changelog against a newer
release of Ubuntu than the one you are using?

> This is a very serious issue...

Why is this "a very serious issue"? It seems to me that it only affects
invalid configurations so should only affect development and testing of
deployments rather than in production? The workaround (if it can be
called that) is to fix the invalid configuration.

The fix does look reasonable to SRU though. I wonder if
https://anonscm.debian.org/cgit/pkg-squid/pkg-
squid.git/commit/?id=6ac65f75a971a4a is also relevant? That may be a
separate bug though, or we may need an additional test case for it.

** Also affects: squid3 (Ubuntu Zesty)
   Importance: Undecided
   Status: New

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

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

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

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

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

** Changed in: squid3 (Ubuntu Zesty)
   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/1738412

Title:
  Init script fails test on reload/restart because of faulty regex

Status in squid3 package in Ubuntu:
  Fix Released
Status in squid3 source package in Xenial:
  Triaged
Status in squid3 source package in Zesty:
  Triaged

Bug description:
  This is a very serious issue that got fixed upstream in:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800341

  It is also logged in the Ubuntu changelog as fixed in:

  squid3 (3.5.12-1) unstable; urgency=medium
[ Mathieu Parent ]
* Fix FATAL parsing before start/reload/restart (Closes: #800341)

  But is in fact not fixed.
  When I look in the source package I find two init scripts:
  squid3.rc and squid.rc. squid3.rc has the patch while squid.rc does not.

  The one being included in the package and deployed is the one that
  does not have the fix.

  I'm including a patch to fix this issue.
  Please push this out ASAP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1738412/+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 1734278] Re: Grub2 cannot boot up when 8254 time function disable

[Yuan-Chen Cheng]

** Changed in: oem-priority
   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/1734278

Title:
  Grub2 cannot boot up when 8254 time function disable

Status in HWE Next:
  Triaged
Status in OEM Priority Project:
  Fix Released
Status in debian-installer package in Ubuntu:
  Fix Released
Status in grub2 package in Ubuntu:
  Fix Released
Status in debian-installer source package in Xenial:
  Fix Released
Status in grub2 source package in Xenial:
  Fix Released
Status in debian-installer source package in Bionic:
  Fix Released
Status in grub2 source package in Bionic:
  Fix Released
Status in grub2 package in Debian:
  New
Status in grub2 package in Fedora:
  Confirmed

Bug description:
  [Impact]
  Some Intel SoC-based systems.

  [Test cases]
  1) Boot an affected system.

  [Regression potential]
  Some systems may rely on the current state of the timer selection in order to 
be able to boot successfully, or to catch key presses before the end of a 
timeout in the menu.
  These systems may then fail to boot correctly, stuck in a timeout of crashing 
in grub. The new default, pmtimer, should be available on all ACPI-capable 
systems without being power-gated such as for the PIT, so the impact of this 
possible regression is minimal.

  ---

  Fail to boot into Ubuntu GRUB on the platforms which legacy(8254) timer 
function is disabled.
  "8254 clock gating" is provided to disable 8254 timer to get rid of legacy 
and save power. The platforms with the firmware which disable the 8254 timer 
will fail to boot up and block on grub2 which uses the 8254 timer to calibrate 
the TSC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1734278/+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 1739033] Re: Corosync: Assertion 'sender_node != NULL' failed when bind iface is ready after corosync boots

[Launchpad Bug Tracker]

This bug was fixed in the package corosync - 2.3.3-1ubuntu4

---
corosync (2.3.3-1ubuntu4) trusty; urgency=medium

  * d/p/Parser-Make-config-file-parser-more-hierarchy.patch: Fixes how
corosync parses a config file with malformed entries (LP: #1739033).

 -- Victor Tapia   Wed, 20 Dec 2017 12:39:54
+0100

** Changed in: corosync (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/1739033

Title:
  Corosync: Assertion 'sender_node != NULL' failed when bind iface is
  ready after corosync boots

Status in corosync package in Ubuntu:
  Fix Released
Status in corosync source package in Trusty:
  Fix Released
Status in corosync source package in Xenial:
  Fix Released
Status in corosync source package in Zesty:
  Fix Released
Status in corosync source package in Artful:
  Fix Released

Bug description:
  [Impact]

  Corosync sigaborts if it starts before the interface it has to bind to
  is ready.

  On boot, if no interface in the bindnetaddr range is up/configured,
  corosync binds to lo (127.0.0.1). Once an applicable interface is up,
  corosync crashes with the following error message:

  corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: 
Assertion `sender_node != NULL' failed.
  Aborted (core dumped)

  The last log entries show that the interface is trying to join the
  cluster:

  Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug   [TOTEM ] 
totemsrp.c:2089 entering OPERATIONAL state.
  Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice  [TOTEM ] 
totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members 
joined: 704573706

  During the quorum calculation, the generated nodeid (704573706) for
  the node is being used instead of the nodeid specified in the
  configuration file (1), and the assert fails because the nodeid is not
  present in the member list. Corosync should use the correct nodeid and
  continue running after the interface is up, as shown in a fixed
  corosync boot:

  Dec 19 11:50:56 [4824] xenial-corosync corosync notice  [TOTEM ]
  totemsrp.c:2095 A new membership (169.254.241.10:80) was formed.
  Members joined: 1

  [Environment]

  Xenial 16.04.3

  Packages:

  ii  corosync 2.3.5-3ubuntu1amd64cluster engine 
daemon and utilities
  ii  libcorosync-common4:amd642.3.5-3ubuntu1amd64cluster engine 
common library

  [Test Case]

  Config:

  totem {
  version: 2
  member {
  memberaddr: 169.254.241.10
  }
  member {
  memberaddr: 169.254.241.20
  }
  transport: udpu

  crypto_cipher: none
  crypto_hash: none
  nodeid: 1
  interface {
  ringnumber: 0
  bindnetaddr: 169.254.241.0
  mcastport: 5405
  ttl: 1
  }
  }

  quorum {
  provider: corosync_votequorum
  expected_votes: 2
  }

  nodelist {
  node {
  ring0_addr: 169.254.241.10
  nodeid: 1
  }
  node {
  ring0_addr: 169.254.241.20
  nodeid: 2
  }
  }

  1. ifdown interface (169.254.241.10)
  2. start corosync (/usr/sbin/corosync -f)
  3. ifup interface

  [Regression Potential]

  This patch affects corosync boot; the regression potential is for
  other problems during corosync startup and/or configuration parsing.

  [Other info]

  # Upstream corosync commit :
  
https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2

  # git describe aab55a004bb12ebe78db341dc56759dfe710c1b2
  v2.3.5-45-gaab55a0

  # rmadison corosync
  corosync | 2.3.3-1ubuntu1   | trusty  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el
  corosync | 2.3.3-1ubuntu3   | trusty-updates  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el
  corosync | 2.3.5-3ubuntu1   | xenial  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el, s390x
  corosync | 2.4.2-3build1| zesty   | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
  corosync | 2.4.2-3build1| artful  | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
  corosync | 2.4.2-3build1| bionic  | source, amd64, arm64, armhf, 
i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1739033/+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 1681073] Re: Create Consistency Group form has an exception

[Launchpad Bug Tracker]

This bug was fixed in the package horizon - 2:9.1.2-0ubuntu3

---
horizon (2:9.1.2-0ubuntu3) xenial; urgency=medium

  [ Corey Bryant ]
  * The horizon 2:9.1.2-0ubuntu1 point release was released with quilt
patches pushed and now debian/patches won't apply. Revert the commits
to upstream code of the following patches:
- d/p/embedded-xstatic.patch
- d/p/fix-dashboard-django-wsgi.patch
- d/p/fix-dashboard-manage.patch
- d/p/fix-horizon-test-settings.patch
- d/p/ubuntu_settings.patch
- d/p/add-juju-environment-download.patch (all but
  juju.environments.template were pushed)

  [ Seyeong Kim ]
  * Fix create consistency group form exception (LP: #1681073)
- d/p/fix_create_consistency_group_form_exception.patch

 -- Corey Bryant   Thu, 14 Dec 2017 10:48:25
-0500

** Changed in: horizon (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/1681073

Title:
  Create Consistency Group form has an exception

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in Ubuntu Cloud Archive newton series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Committed
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in horizon package in Ubuntu:
  Fix Released
Status in horizon source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  Affected
  - UCA Mitaka, Ocata
  - Xenial, Zesty ( Artful is incidentlly added, please ignore it) 

  After enabling consistency groups by changing api-paste.ini,

  When trying to create consistency group, there are error like below.

  Exception info:
  Internal Server Error: /project/cgroups/create/
  Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", 
line 132, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 52, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 36, in dec
  return view_func(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/decorators.py", line 84, in dec
  return view_func(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 71, in view
  return self.dispatch(request, *args, **kwargs)
    File "/usr/local/lib/python2.7/dist-packages/django/views/generic/base.py", 
line 89, in dispatch
  return handler(request, *args, **kwargs)
    File "/opt/stack/horizon/horizon/workflows/views.py", line 199, in post
  exceptions.handle(request)
    File "/opt/stack/horizon/horizon/exceptions.py", line 352, in handle
  six.reraise(exc_type, exc_value, exc_traceback)
    File "/opt/stack/horizon/horizon/workflows/views.py", line 194, in post
  success = workflow.finalize()
    File "/opt/stack/horizon/horizon/workflows/base.py", line 824, in finalize
  if not self.handle(self.request, self.context):
    File 
"/opt/stack/horizon/openstack_dashboard/dashboards/project/cgroups/workflows.py",
 line 323, in handle
  vol_type.extra_specs['volume_backend_name']
  KeyError: 'volume_backend_name'

  [Test case]

  juju deploy bundle

  (this is same as original description)
  1. Go to admin/volume types panel
  2. Create volume type with any name
  3. Go to project/Consistency Groups panel
  4. Create Consistency Group and add the volume type we just created
  5. Submit Create Consistency Group form

  [Regression Potential]
  This changes horizon UI, and need to restart apache2 server. There could be 
very short outage for openstack dashboard. but this seems not critical to 
openstack service. and if there is code error, django server can't be started 
and outage time could be longer than above.

  [Others]

  upstream commit
  
https://git.openstack.org/cgit/openstack/horizon/commit/?id=89bb9268204a2316fc526d660f38d5517980f209

  [Original Description]

  Env: devstack master branch

  Steps to reproduce:
  1. Go to admin/volume types panel
  2. Create volume type with any name
  3. Go to project/Consistency Groups panel
  4. Create Consistency Group and add the volume type we just created
  5. Submit Create Consistency Group form

  it will throws an exception.

  Exception info:
  Internal Server Error: /project/cgroups/create/
  Traceback (most recent call last):
    File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", 
line 132, in get_response
  response = wrapped_callback(request, *callback_args, **callback_kwargs)
    File 

[Group.of.nepali.translators] [Bug 1734278] Re: Grub2 cannot boot up when 8254 time function disable

[Launchpad Bug Tracker]

This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.15

---
grub2 (2.02~beta2-36ubuntu3.15) xenial; urgency=medium

  [ Ike Panhc ]
  * Fix grub crash when exit on arm64-platform. (LP: #1731241)

  [ Mathieu Trudel-Lapierre ]
  * Cherry-pick upstream patch to change the default TSC calibration method
to pmtimer on EFI systems (LP: #1734278)

 -- Mathieu Trudel-Lapierre   Mon, 11 Dec 2017
10:25:22 -0500

** Changed in: grub2 (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/1734278

Title:
  Grub2 cannot boot up when 8254 time function disable

Status in HWE Next:
  Triaged
Status in OEM Priority Project:
  Fix Committed
Status in debian-installer package in Ubuntu:
  Fix Released
Status in grub2 package in Ubuntu:
  Fix Released
Status in debian-installer source package in Xenial:
  Fix Released
Status in grub2 source package in Xenial:
  Fix Released
Status in debian-installer source package in Bionic:
  Fix Released
Status in grub2 source package in Bionic:
  Fix Released
Status in grub2 package in Debian:
  New
Status in grub2 package in Fedora:
  Confirmed

Bug description:
  [Impact]
  Some Intel SoC-based systems.

  [Test cases]
  1) Boot an affected system.

  [Regression potential]
  Some systems may rely on the current state of the timer selection in order to 
be able to boot successfully, or to catch key presses before the end of a 
timeout in the menu.
  These systems may then fail to boot correctly, stuck in a timeout of crashing 
in grub. The new default, pmtimer, should be available on all ACPI-capable 
systems without being power-gated such as for the PIT, so the impact of this 
possible regression is minimal.

  ---

  Fail to boot into Ubuntu GRUB on the platforms which legacy(8254) timer 
function is disabled.
  "8254 clock gating" is provided to disable 8254 timer to get rid of legacy 
and save power. The platforms with the firmware which disable the 8254 timer 
will fail to boot up and block on grub2 which uses the 8254 timer to calibrate 
the TSC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1734278/+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 1731241] Re: grub exit on arm64-efi crashes

[Launchpad Bug Tracker]

This bug was fixed in the package grub2 - 2.02~beta2-36ubuntu3.15

---
grub2 (2.02~beta2-36ubuntu3.15) xenial; urgency=medium

  [ Ike Panhc ]
  * Fix grub crash when exit on arm64-platform. (LP: #1731241)

  [ Mathieu Trudel-Lapierre ]
  * Cherry-pick upstream patch to change the default TSC calibration method
to pmtimer on EFI systems (LP: #1734278)

 -- Mathieu Trudel-Lapierre   Mon, 11 Dec 2017
10:25:22 -0500

** Changed in: grub2 (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/1731241

Title:
  grub exit on arm64-efi crashes

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

Bug description:
  [Impact]

   * grub exit on arm64-efi causes EFI exception, requiring reboot to
  recover.

  [Test Case]

   * Using grub cmdline and exit shall return to UEFI

  [Regression Potential]

   * Low regression risk due to
     - Only codes on exit with efi platform modified
     - patch cherry-picked from upstream and already in grub2 since zesty

  [Other Info]

   * Patch on upstream

  commit c945ca75c3b2b900040b905323b1226cb60a1166
  Author: Mark Salter 
  Date: Fri Aug 15 12:22:43 2014 -0400

  Fix exit to EFI firmware

  The current code for EFI grub_exit() calls grub_efi_fini() before
  returning to firmware. In the case of ARM, this leaves a timer
  event running which could lead to a firmware crash. This patch
  changes this so that grub_machine_fini() is called with a NORETURN
  flag. This allows machine-specific shutdown to happen as well
  as the shutdown done by grub_efi_fini().

  Signed-off-by: Mark Salter 

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1731241/+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 1734278] Re: Grub2 cannot boot up when 8254 time function disable

[Launchpad Bug Tracker]

This bug was fixed in the package debian-installer -
20101020ubuntu451.18

---
debian-installer (20101020ubuntu451.18) xenial; urgency=medium

  * Rebuild against grub2 2.02~beta2-36ubuntu3.15 patched for EFI timers
fixes. (LP: #1734278)

debian-installer (20101020ubuntu451.17) xenial; urgency=medium

  * Bump FLOPPY_SIZE on amd64, i386, and powerpc for linux-firmware
growth.

debian-installer (20101020ubuntu451.16) xenial; urgency=medium

  [ Steve Langasek ]
  * Adjust the Vcs-Bzr target for SRUs.

  [ Adam Conrad ]
  * Move master kernels to 4.4.0-101.
  * Move hwe kernels to 4.10.0-40.

 -- Mathieu Trudel-Lapierre   Tue, 19 Dec 2017
12:50:48 -0500

** Changed in: debian-installer (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/1734278

Title:
  Grub2 cannot boot up when 8254 time function disable

Status in HWE Next:
  Triaged
Status in OEM Priority Project:
  Fix Committed
Status in debian-installer package in Ubuntu:
  Fix Released
Status in grub2 package in Ubuntu:
  Fix Released
Status in debian-installer source package in Xenial:
  Fix Released
Status in grub2 source package in Xenial:
  Fix Released
Status in debian-installer source package in Bionic:
  Fix Released
Status in grub2 source package in Bionic:
  Fix Released
Status in grub2 package in Debian:
  New
Status in grub2 package in Fedora:
  Confirmed

Bug description:
  [Impact]
  Some Intel SoC-based systems.

  [Test cases]
  1) Boot an affected system.

  [Regression potential]
  Some systems may rely on the current state of the timer selection in order to 
be able to boot successfully, or to catch key presses before the end of a 
timeout in the menu.
  These systems may then fail to boot correctly, stuck in a timeout of crashing 
in grub. The new default, pmtimer, should be available on all ACPI-capable 
systems without being power-gated such as for the PIT, so the impact of this 
possible regression is minimal.

  ---

  Fail to boot into Ubuntu GRUB on the platforms which legacy(8254) timer 
function is disabled.
  "8254 clock gating" is provided to disable 8254 timer to get rid of legacy 
and save power. The platforms with the firmware which disable the 8254 timer 
will fail to boot up and block on grub2 which uses the 8254 timer to calibrate 
the TSC.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/1734278/+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 1711760] Re: [2.3] resolv.conf is not set (during commissioning or testing)

[Launchpad Bug Tracker]

This bug was fixed in the package resolvconf - 1.79ubuntu4.1

---
resolvconf (1.79ubuntu4.1) zesty-proposed; urgency=medium

  * support reading dns information written by initramfs. (LP: #1711760)

 -- Scott Moser   Fri, 08 Dec 2017 14:47:54 -0500

** Changed in: resolvconf (Ubuntu Zesty)
   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/1711760

Title:
  [2.3] resolv.conf is not set (during commissioning or testing)

Status in MAAS:
  Fix Released
Status in resolvconf package in Ubuntu:
  Won't Fix
Status in resolvconf source package in Trusty:
  Fix Released
Status in resolvconf source package in Xenial:
  Fix Released
Status in resolvconf source package in Zesty:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Without this fix applied, dns settings provided to the dhcp response
  in the initramfs are not reflected in the "real root".

  Thus dns resolution does not work. Of most interest was the MAAS use
  case of the 'root=http://<>/squashfs' use case.

  MAAS 2.3 uses this for the installation environment and also the rescue
  environment.  In most cases the 14.04 specific fix will only apply
  to installation as 16.04 is most likely to be used in rescue mode.

  [Test Case]
  There are two tests for this.

  a.) local/non-MAAS test
  Download the test case attached.
  Run it and follow the instructions.
  Login to the guest (ubuntu:password), and inspect /etc/resolv.conf
  without the fix there would be no data in /etc/resolv.conf.  With the
  fix you should see 'nameserver 10.0.2.2' and 'search mydomain.com bar.com'

  b.) MAAS test.
  For the full maas test, you need to build a image stream for maas
  with the fix included in the squashfs image and then import that
  stream to maas and use the rescue environment and verify dns.
  This process is beyond the scope of the SRU template, but is
  described partially in
    
http://bazaar.launchpad.net/~maas-images-maintainers/maas-images/maas-ephemerals/view/head:/README

  [Regression Potential]
  Regression potential should be very low.  There are gates in the code
  to make sure that this code is inactive other than when it is explicitly
  enabled.

  net-interface-handler will exit without doing anything unless:
  a.) there exist files /run/net-$INTERFACE.conf or /run/net6-$INTERFACE.conf
  and these files have non-empty values for a variable mentioned above.
  (These files are written by the initramfs code when 'ip=' is seen).

  b.) this is not a container.
    trusty uses 'running-in-container' to determine this.
    xenial uses 'systemd-detect-virt'

  c.) there is no OPENISCSI_MARKER file (/run/initramfs/open-iscsi.interface)
  if open-iscsi has written this file due to open-iscsi root, then it
  will handle this functionality. resolvconf will get out of the way.

  d.) /proc/cmdline contains cloud-config-url=* or 'rc-initrd-dns'
  This lowers the scope of changes in runtime to cases with where either the
  new flag is seen or cloud-config-url is passed. The MAAS use case will
  contain this flag.

  [Other Info]

  === End SRU Template ===

  Using MAAS 2.3, during commissioning (and likely in the rest of the
  ephemeral environment) we have noticed that resolv.conf is not set
  with the DNS server.

  That said, during the commissioning process, MAAS does not send any
  metadata to cloud-init to configure the network, rather, we expect the
  image to boot from the network via DHCP. So, cloud-init writes:

  ubuntu@manual:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

  # control-manual ens3
  iface ens3 inet dhcp
  broadcast 192.168.122.255
  dns-nameservers 192.168.122.2
  gateway 192.168.122.1
  netmask 255.255.255.0

  Which correctly includes the DNS server. However:

  ubuntu@manual:~$ ping google.com
  ping: unknown host google.com

  If restart the interfacE:

  ubuntu@manual:~$ sudo ifdown ens3 && sudo ifup ens3
  ifdown: interface ens3 not configured
  Internet Systems Consortium DHCP Client 4.3.3
  Copyright 2004-2015 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ens3/52:54:00:ea:57:31
  Sending on   LPF/ens3/52:54:00:ea:57:31
  Sending on   Socket/fallback
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x14eb0354)
  DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 4 (xid=0x14eb0354)
  DHCPREQUEST 

[Group.of.nepali.translators] [Bug 1734207] Re: Multiple PSKs with dyndns left/rightids doesn't work

[Launchpad Bug Tracker]

This bug was fixed in the package strongswan - 5.5.1-4ubuntu2.2

---
strongswan (5.5.1-4ubuntu2.2) artful; urgency=medium

  * d/p/ikev1-First-do-PSK-lookups-lp1734207.patch ensure evaluation
with resolvable hostnames selects the right PSK (LP: #1734207).

 -- Christian Ehrhardt   Mon, 18 Dec
2017 11:05:57 +0100

** Changed in: strongswan (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/1734207

Title:
  Multiple PSKs with dyndns left/rightids doesn't work

Status in strongswan package in Ubuntu:
  Fix Released
Status in strongswan source package in Xenial:
  Fix Committed
Status in strongswan source package in Zesty:
  Fix Released
Status in strongswan source package in Artful:
  Fix Released

Bug description:
  [Impact]

   * charon unnecessarily selects a wrong PSK in some cases:
 * A site-to-site connection using resolvable hostnames (e.g., DynDNS) as 
identities in /etc/ipsec.secrets and a Roadwarrior connection (using %any as 
remote peer identity)
 * Multiple site-to-site connections using resolvable hostnames as 
identities

   * Fix is a backport from upstream in since 5.5.2

  [Test Case]

   * There are detailed steps on how to configure for this case on 
 https://wiki.strongswan.org/issues/2223

  [Regression Potential]

   * It is known (see discussion in upstream bug) that this can slightly 
 increase the connection setup as it adds a dns query. But un-breaking 
 the covered use cases was considered worth to do so upstream, and so 
 should we.

   * By changing the IKEv1 PSK codepath is the only changed path, so this is 
 the area where unexpected regressions could occur. None of the testing 
 found some so far and since upstream didn't change it for a while it 
 seems safe to me.

  [Other Info]
   
* n/a

  ---

  See: https://wiki.strongswan.org/issues/2223

  There is a chance to get an backport into xenial?

  It's fixed in the upstream version 5.5.2

  # apt-cache policy strongswan
  strongswan:
    Installed: 5.3.5-1ubuntu3.4
    Candidate: 5.3.5-1ubuntu3.4

  # lsb_release -rd
  Description:Ubuntu 16.04.3 LTS
  Release:16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1734207/+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 1734207] Re: Multiple PSKs with dyndns left/rightids doesn't work

[Launchpad Bug Tracker]

This bug was fixed in the package strongswan - 5.5.1-1ubuntu3.3

---
strongswan (5.5.1-1ubuntu3.3) zesty; urgency=medium

  * d/p/ikev1-First-do-PSK-lookups-lp1734207.patch ensure evaluation
with resolvable hostnames selects the right PSK (LP: #1734207).

 -- Christian Ehrhardt   Mon, 18 Dec
2017 11:13:53 +0100

** Changed in: strongswan (Ubuntu Zesty)
   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/1734207

Title:
  Multiple PSKs with dyndns left/rightids doesn't work

Status in strongswan package in Ubuntu:
  Fix Released
Status in strongswan source package in Xenial:
  Fix Committed
Status in strongswan source package in Zesty:
  Fix Released
Status in strongswan source package in Artful:
  Fix Released

Bug description:
  [Impact]

   * charon unnecessarily selects a wrong PSK in some cases:
 * A site-to-site connection using resolvable hostnames (e.g., DynDNS) as 
identities in /etc/ipsec.secrets and a Roadwarrior connection (using %any as 
remote peer identity)
 * Multiple site-to-site connections using resolvable hostnames as 
identities

   * Fix is a backport from upstream in since 5.5.2

  [Test Case]

   * There are detailed steps on how to configure for this case on 
 https://wiki.strongswan.org/issues/2223

  [Regression Potential]

   * It is known (see discussion in upstream bug) that this can slightly 
 increase the connection setup as it adds a dns query. But un-breaking 
 the covered use cases was considered worth to do so upstream, and so 
 should we.

   * By changing the IKEv1 PSK codepath is the only changed path, so this is 
 the area where unexpected regressions could occur. None of the testing 
 found some so far and since upstream didn't change it for a while it 
 seems safe to me.

  [Other Info]
   
* n/a

  ---

  See: https://wiki.strongswan.org/issues/2223

  There is a chance to get an backport into xenial?

  It's fixed in the upstream version 5.5.2

  # apt-cache policy strongswan
  strongswan:
    Installed: 5.3.5-1ubuntu3.4
    Candidate: 5.3.5-1ubuntu3.4

  # lsb_release -rd
  Description:Ubuntu 16.04.3 LTS
  Release:16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1734207/+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 1739033] Re: Corosync: Assertion 'sender_node != NULL' failed when bind iface is ready after corosync boots

[Launchpad Bug Tracker]

This bug was fixed in the package corosync - 2.3.5-3ubuntu2

---
corosync (2.3.5-3ubuntu2) xenial; urgency=medium

  * d/p/Parser-Make-config-file-parser-more-hierarchy.patch: Fixes how
corosync parses a config file with malformed entries (LP: #1739033).

 -- Victor Tapia   Wed, 20 Dec 2017 12:37:52
+0100

** Changed in: corosync (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/1739033

Title:
  Corosync: Assertion 'sender_node != NULL' failed when bind iface is
  ready after corosync boots

Status in corosync package in Ubuntu:
  Fix Released
Status in corosync source package in Trusty:
  Fix Committed
Status in corosync source package in Xenial:
  Fix Released
Status in corosync source package in Zesty:
  Fix Released
Status in corosync source package in Artful:
  Fix Released

Bug description:
  [Impact]

  Corosync sigaborts if it starts before the interface it has to bind to
  is ready.

  On boot, if no interface in the bindnetaddr range is up/configured,
  corosync binds to lo (127.0.0.1). Once an applicable interface is up,
  corosync crashes with the following error message:

  corosync: votequorum.c:2019: message_handler_req_exec_votequorum_nodeinfo: 
Assertion `sender_node != NULL' failed.
  Aborted (core dumped)

  The last log entries show that the interface is trying to join the
  cluster:

  Dec 19 11:36:05 [22167] xenial-pacemaker corosync debug   [TOTEM ] 
totemsrp.c:2089 entering OPERATIONAL state.
  Dec 19 11:36:05 [22167] xenial-pacemaker corosync notice  [TOTEM ] 
totemsrp.c:2095 A new membership (169.254.241.10:444) was formed. Members 
joined: 704573706

  During the quorum calculation, the generated nodeid (704573706) for
  the node is being used instead of the nodeid specified in the
  configuration file (1), and the assert fails because the nodeid is not
  present in the member list. Corosync should use the correct nodeid and
  continue running after the interface is up, as shown in a fixed
  corosync boot:

  Dec 19 11:50:56 [4824] xenial-corosync corosync notice  [TOTEM ]
  totemsrp.c:2095 A new membership (169.254.241.10:80) was formed.
  Members joined: 1

  [Environment]

  Xenial 16.04.3

  Packages:

  ii  corosync 2.3.5-3ubuntu1amd64cluster engine 
daemon and utilities
  ii  libcorosync-common4:amd642.3.5-3ubuntu1amd64cluster engine 
common library

  [Test Case]

  Config:

  totem {
  version: 2
  member {
  memberaddr: 169.254.241.10
  }
  member {
  memberaddr: 169.254.241.20
  }
  transport: udpu

  crypto_cipher: none
  crypto_hash: none
  nodeid: 1
  interface {
  ringnumber: 0
  bindnetaddr: 169.254.241.0
  mcastport: 5405
  ttl: 1
  }
  }

  quorum {
  provider: corosync_votequorum
  expected_votes: 2
  }

  nodelist {
  node {
  ring0_addr: 169.254.241.10
  nodeid: 1
  }
  node {
  ring0_addr: 169.254.241.20
  nodeid: 2
  }
  }

  1. ifdown interface (169.254.241.10)
  2. start corosync (/usr/sbin/corosync -f)
  3. ifup interface

  [Regression Potential]

  This patch affects corosync boot; the regression potential is for
  other problems during corosync startup and/or configuration parsing.

  [Other info]

  # Upstream corosync commit :
  
https://github.com/corosync/corosync/commit/aab55a004bb12ebe78db341dc56759dfe710c1b2

  # git describe aab55a004bb12ebe78db341dc56759dfe710c1b2
  v2.3.5-45-gaab55a0

  # rmadison corosync
  corosync | 2.3.3-1ubuntu1   | trusty  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el
  corosync | 2.3.3-1ubuntu3   | trusty-updates  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el
  corosync | 2.3.5-3ubuntu1   | xenial  | source, amd64, arm64, armhf, 
i386, powerpc, ppc64el, s390x
  corosync | 2.4.2-3build1| zesty   | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
  corosync | 2.4.2-3build1| artful  | source, amd64, arm64, armhf, 
i386, ppc64el, s390x
  corosync | 2.4.2-3build1| bionic  | source, amd64, arm64, armhf, 
i386, ppc64el, s390x

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/corosync/+bug/1739033/+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)

[Launchpad Bug Tracker]

This bug was fixed in the package slof - 20170724+dfsg-1ubuntu0.1

---
slof (20170724+dfsg-1ubuntu0.1) artful; urgency=medium

  * Fix boot with more than 16 disks (LP: #1734856)
- d/p/0001-boot-do-not-concatenate-bootdev.patch
- d/p/0002-boot-use-a-temporary-bootdev-buf.patch

 -- Christian Ehrhardt   Mon, 18 Dec
2017 14:18:30 +0100

** Changed in: slof (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/1734856

Title:
  Can't boot VM with more than 16 disks (slof buffer issue)

Status in SLOF - Slimline Open Firmware:
  New
Status in The Ubuntu-power-systems project:
  Incomplete
Status in slof package in Ubuntu:
  Fix Released
Status in slof source package in Xenial:
  Fix Committed
Status in slof source package in Zesty:
  Fix Committed
Status in slof source package in Artful:
  Fix Released
Status in slof source package in Bionic:
  Fix Released

Bug description:
  [Impact]

   * Booting a KVM guest with many disks considered as potential boot device 
 fails on ppc64le

   * In detail this was an overflow, so now the processing of devices is 
 changed to use dynamic allocation which works with higher numbers of 
 devices.

  [Test Case]

   * Comment #12 has the full final testcase, not writing all that up 
 here again.

  [Regression Potential]

   * It is a change of disk processing in the slof loader for ppc64el
 - that means on one hand only ppc64el will be affected by an issue
 - OTOH there might be a disk combination not part of my or upstreams or 
   IBMs testing that might now fail with the new code (unlikely)
 - Given that the change is upstream and was provided by IBM which I 
   consider the authority on that code I think it is safe to be 
   considered.

  [Other Info]
   
   * n/a

  
  


  == 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 1709536] Re: snapd 2.26.14 on ubuntu-core won't start in containers anymore

[Michael Vogt]

** Changed in: snapd
   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/1709536

Title:
  snapd 2.26.14 on ubuntu-core won't start in containers anymore

Status in Snap Layer:
  New
Status in snapd:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released

Bug description:
  [Impact]

  Systemd treats a failure to apply the requested Nice value as critical
  to unit startup.

  Unprivileged LXD containers do not allow the use of negative nice
  values. snapd will fail to start inside containers now that snapd uses
  a negative Nice value.

  Aug 09 05:54:37 core systemd[1]: snapd.service: Main process exited, 
code=exited, status=201/NICE
  Aug 09 05:54:37 core systemd[1]: snapd.service: Unit entered failed state.
  Aug 09 05:54:37 core systemd[1]: snapd.service: Failed with result 
'exit-code'.

  The fix is for systemd to ignore permission errors when attempting to
  setup such custom nice values in containers.

  I have confirmed that setting up a unit override by hand which sets
  Nice = 0 does resolve the problem.

  [Test Case]

  Boot a Xenial image in lxd:

  $ lxc launch xenial x1
  $ lxc exec x1 -- systemctl --state=failed

  Observe failures for snapd :

  ● snapd.service loaded failed failed Snappy daemon
  ● snapd.socket loaded failed failed Socket activation for snapp

  Install updated systemd from -proposed and get status: (lxc exec
   reboot; lxc exec  systemctl status)

  State: running
  Jobs: 0 queued
  Failed: 0 units

  [Regression Potential]

  Services will now run with a Nice value other than what was specified
  in the unit if it cannot be changed for some reason.

To manage notifications about this bug go to:
https://bugs.launchpad.net/layer-snap/+bug/1709536/+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