[Group.of.nepali.translators] [Bug 1741978] Re: Add support for ARM events

[Launchpad Bug Tracker]

This bug was fixed in the package rasdaemon - 0.5.8-1ubuntu2.1

---
rasdaemon (0.5.8-1ubuntu2.1) artful; urgency=medium

  * debian/rules: Enable ARM events --enable-arm (LP: #1769182)

rasdaemon (0.5.8-1ubuntu2) artful; urgency=medium

  * Cherrypick upstream patches to support ARM kernel trace events.
LP: #1741978

 -- Manoj Iyer   Wed, 09 May 2018 14:45:57
-0500

** Changed in: rasdaemon (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/1741978

Title:
  Add support for ARM events

Status in rasdaemon package in Ubuntu:
  Fix Released
Status in rasdaemon source package in Xenial:
  Fix Released
Status in rasdaemon source package in Zesty:
  Won't Fix
Status in rasdaemon source package in Artful:
  Fix Released
Status in rasdaemon source package in Bionic:
  Fix Released
Status in rasdaemon package in Debian:
  Fix Released

Bug description:
  [IMPACT]
  The UEFI 2.6 spec added support for ARM processor errors and errors
  that have unrecognized CPER section types. rasdaemon needs to support ARM 
kernel trace events.

  [FIX]
  The following patches add support for ARM events to rasdaemon:

  rasdaemon: add support for non standard CPER section events
  rasdaemon: add support for ARM events

  ARM support was added to rasdaemon in version 0.6.0 release.

  [TESTING]
  The patches were applied to rasdaemon 0.5.8 and 0.5.6 versions and tested on 
Artful and Xenial. Test results are attached to comments below.

  [REGRESSION POTENTIAL]
  None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rasdaemon/+bug/1741978/+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 1570997] Re: fail if HOME environment variable is not set

[Launchpad Bug Tracker]

This bug was fixed in the package ssh-import-id - 5.7-0ubuntu1.1

---
ssh-import-id (5.7-0ubuntu1.1) bionic; urgency=medium

  * Convert source foramt to "3.0 (quilt)", implicitly removing
ssh_import_id.egg-info presumably included in last upload by
mistake.
  * Backport some fixes from cosmic:
- d/patches/0001-lp-1770302-output-flushing.patch: Ensure error
  messages in fetch_keys_gh get flushed by replacing calls to print
  with calls to die and calls to os._exit() with calls to sys.exit.
  (LP: #1770302)
- d/patches/0002-lp-1770503-launchpad-error-checking.patch: Check
  status code of response when fetching ssh keys from Launchpad.
  (LP: #1770305)
- d/patches/0003-lp-1570997-find-keys-no-HOME.patch: Get path to
  user's authorized_keys even if HOME is not set.  (LP: #1570997)

 -- Michael Hudson-Doyle   Thu, 17 May 2018
11:40:43 +1200

** Changed in: ssh-import-id (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/1570997

Title:
  fail if HOME environment variable is not set

Status in ssh-import-id:
  Fix Released
Status in ssh-import-id package in Ubuntu:
  Fix Released
Status in ssh-import-id source package in Xenial:
  Triaged
Status in ssh-import-id source package in Bionic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Running ssh-import-id without environment variable HOME set
  will fail and print an error message like:

   TypeError: join() argument must be str or bytes, not 'NoneType'

  [Test Case]
  $ name="my-x"
  $ ud=$(printf '%s\n%s\n' '#!/bin/sh' 'ssh-import-id smoser')
  $ lxc launch ubuntu-daily:xenial "$name" "--config=user.user-data=$ud"

  To see failure, you can then just:
  $ lxc exec "$name" -- cat /run/cloud-init/result.json
  {
   "v1": {
    "datasource": "DataSourceHetzner",
    "errors": [
     "('scripts-user', RuntimeError('Runparts: 1 failures in 1 attempted 
commands',))"
    ]
   }
  }

  $ lxc exec "$name" -- grep "ssh-import-id lp:smoser" 
/root/.ssh/authorized_keys &&
  echo GOOD || echo FAIL

  [Regression Potential]
  Regression is unlikely.  The code only does anything if HOME is not present.
  This has been in Artful and Bionic since 2016-09-16.

  [Other Info]
  Upstream merge proposal:
   
https://code.launchpad.net/~smoser/ssh-import-id/trunk.lp1570997/+merge/326692

  === End SRU Template ===

  I've modified /usr/bin/ssh-import-id to show a stack trace rather than 
unhelpful message:
   TypeError: join() argument must be str or bytes, not 'NoneType'

  Then, running:
  $ env -u HOME ssh-import-id smoser
  Traceback (most recent call last):
    File "/usr/bin/ssh-import-id", line 62, in 
  main()
    File "/usr/bin/ssh-import-id", line 45, in main
  k = import_keys(proto, username, parser.options.useragent)
    File "/usr/lib/python3/dist-packages/ssh_import_id/__init__.py", line 204, 
in import_keys
  local_keys = key_list(read_keyfile())
    File "/usr/lib/python3/dist-packages/ssh_import_id/__init__.py", line 135, 
in read_keyfile
  output_file = parser.options.output or os.path.join(os.getenv("HOME"), 
".ssh", "authorized_keys")
    File "/usr/lib/python3.5/posixpath.py", line 89, in join
  genericpath._check_arg_types('join', a, *p)
    File "/usr/lib/python3.5/genericpath.py", line 143, in _check_arg_types
  (funcname, s.__class__.__name__)) from None
  TypeError: join() argument must be str or bytes, not 'NoneType'

  I came to find this by trying to  launch an instance with:

  $ ec2metadata --user-data
  #!/bin/sh
  exec >/my.log 2>&1
  cat /proc/uptime
  date -R
  ssh-import-id smoser

  The basic issue is that the environment that cloud-init runs in does
  not have HOME set.

  I suggest using os.path.expanduser
  def authorized_key_file():
  return os.path.join(os.path.expanduser("~"), ".ssh", 
"authorized_keys")

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ssh-import-id 5.5-0ubuntu1 [modified: usr/bin/ssh-import-id]
  ProcVersionSignature: User Name 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  Date: Fri Apr 15 17:36:09 2016
  Ec2AMI: ami-929f8cf8
  Ec2AMIManifest: 
ubuntu-us-east-1/images-testing/hvm-instance/ubuntu-xenial-daily-amd64-server-20160412.manifest.xml
  Ec2AvailabilityZone: us-east-1c
  Ec2InstanceType: m3.medium
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ssh-import-id
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:

[Group.of.nepali.translators] [Bug 1741978] Re: Add support for ARM events

[Launchpad Bug Tracker]

This bug was fixed in the package rasdaemon - 0.5.6-2ubuntu1.1

---
rasdaemon (0.5.6-2ubuntu1.1) xenial; urgency=medium

  * debian/rules: Enable ARM events --enable-arm (LP: #1769182)

rasdaemon (0.5.6-2ubuntu1) xenial; urgency=medium

  * Cherrypick upstream patches to support ARM kernel trace events.
LP: #1741978

 -- Manoj Iyer   Wed, 09 May 2018 14:54:44
-0500

** Changed in: rasdaemon (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/1741978

Title:
  Add support for ARM events

Status in rasdaemon package in Ubuntu:
  Fix Released
Status in rasdaemon source package in Xenial:
  Fix Released
Status in rasdaemon source package in Zesty:
  Won't Fix
Status in rasdaemon source package in Artful:
  Fix Released
Status in rasdaemon source package in Bionic:
  Fix Released
Status in rasdaemon package in Debian:
  Fix Released

Bug description:
  [IMPACT]
  The UEFI 2.6 spec added support for ARM processor errors and errors
  that have unrecognized CPER section types. rasdaemon needs to support ARM 
kernel trace events.

  [FIX]
  The following patches add support for ARM events to rasdaemon:

  rasdaemon: add support for non standard CPER section events
  rasdaemon: add support for ARM events

  ARM support was added to rasdaemon in version 0.6.0 release.

  [TESTING]
  The patches were applied to rasdaemon 0.5.8 and 0.5.6 versions and tested on 
Artful and Xenial. Test results are attached to comments below.

  [REGRESSION POTENTIAL]
  None.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rasdaemon/+bug/1741978/+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 1767133] Re: linux-image-4.15.0-20-generic install after upgrade from xenial breaks

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.15.0-22.24

---
linux (4.15.0-22.24) bionic; urgency=medium

  * CVE-2018-3639 (powerpc)
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- stf-barrier: set eieio instruction bit 6 for future optimisations

  * CVE-2018-3639 (x86)
- x86/nospec: Simplify alternative_msr_write()
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static

  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

linux (4.15.0-21.22) bionic; urgency=medium

  * linux: 4.15.0-21.22 -proposed tracker (LP: #1767397)

  * initramfs-tools exception during pm.DoInstall with  do-release-upgrade from
16.04 to 18.04  (LP: #1766727)
- Add linux-image-* Breaks on s390-tools (<< 2.3.0-0ubuntu3)

  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Depends on linux-base that provides the necessary tools

  * linux-image packages need to Breaks flash-kernel << 3.90ubuntu2
(LP: #1766629)
- linux-image-* breaks on flash-kernel (<< 3.90ubuntu2)

 -- Stefan Bader   Tue, 15 May 2018 07:41:28
+0200

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

Title:
  linux-image-4.15.0-20-generic install after upgrade from xenial breaks

Status in linux package in Ubuntu:
  Fix Released
Status in linux-hwe-edge package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Invalid
Status in linux-hwe-edge source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux-hwe-edge source package in Bionic:
  Invalid

Bug description:
  [Impact]
  Some upgrades from xenial to bionic break.

  [Test Case]
  Change sources.list from xenial to bionic, then apt install 
linux-image-4.15.0-20-generic.

  [Regression Potential]
  The kernel may be uninstallable if there is no linux-base with the 
appropriate version in the archive.

  

  When installing the linux-image-4.15.0-20-generic kernel from bionic
  on xenial breaks because of the unversioned Depends on linux-base.

  /var/lib/dpkg/info/linux-image-4.15.0-20-generic.postinst: 50: 
/var/lib/dpkg/info/linux-image-4.15.0-20-generic.postinst: 
linux-update-symlinks: not found
  dpkg: error processing package linux-image-4.15.0-20-generic (--configure):
   subprocess installed post-installation script returned error exit status 127
  Errors were encountered while processing:
   linux-image-4.15.0-20-generic
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  If the trigger is called, when some meta packages are installed, it
  won't happen. If all packages are upgraded, it's possible linux-base
  is going to be upgraded first, so the problem won't happen either.

  So, not all upgrades will be affected.

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

___

[Group.of.nepali.translators] [Bug 1766727] Re: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.15.0-22.24

---
linux (4.15.0-22.24) bionic; urgency=medium

  * CVE-2018-3639 (powerpc)
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- stf-barrier: set eieio instruction bit 6 for future optimisations

  * CVE-2018-3639 (x86)
- x86/nospec: Simplify alternative_msr_write()
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static

  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

linux (4.15.0-21.22) bionic; urgency=medium

  * linux: 4.15.0-21.22 -proposed tracker (LP: #1767397)

  * initramfs-tools exception during pm.DoInstall with  do-release-upgrade from
16.04 to 18.04  (LP: #1766727)
- Add linux-image-* Breaks on s390-tools (<< 2.3.0-0ubuntu3)

  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Depends on linux-base that provides the necessary tools

  * linux-image packages need to Breaks flash-kernel << 3.90ubuntu2
(LP: #1766629)
- linux-image-* breaks on flash-kernel (<< 3.90ubuntu2)

 -- Stefan Bader   Tue, 15 May 2018 07:41:28
+0200

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

Title:
  initramfs-tools exception during pm.DoInstall with  do-release-upgrade
  from 16.04 to 18.04

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in linux-hwe-edge package in Ubuntu:
  Fix Released
Status in s390-tools package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-hwe-edge source package in Xenial:
  Fix Released
Status in s390-tools source package in Xenial:
  Fix Released
Status in ubuntu-release-upgrader source package in Xenial:
  Invalid
Status in initramfs-tools source package in Bionic:
  Invalid
Status in linux source package in Bionic:
  Fix Released
Status in linux-hwe-edge source package in Bionic:
  Invalid
Status in s390-tools source package in Bionic:
  Fix Released
Status in ubuntu-release-upgrader source package in Bionic:
  Invalid

Bug description:
  [Impact]
  Upgrades of linux-image-generic-hwe-16.04-edge will fail to configure because 
the post-update script for zipl will fail.

  [Test Case]
  Upgrade linux-image-generic-hwe-16.04-edge from xenial to xenial-proposed on 
s390x.

  [Regression]
  zipl update on s390x might fail, causing the system to be unbootable.

  
  

  Upgrading from 16.04 to 18.04 using 'do-release-upgrade -d' results
  in:

  Errors were encountered while processing:
   initramfs-tools
  Exception during pm.DoInstall():  E:Sub-process /usr/bin/dpkg returned an 
error code (1)

  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable 

[Group.of.nepali.translators] [Bug 1769182] Re: ./configure --enable-arm needed for ARM events

[Launchpad Bug Tracker]

This bug was fixed in the package rasdaemon - 0.5.6-2ubuntu1.1

---
rasdaemon (0.5.6-2ubuntu1.1) xenial; urgency=medium

  * debian/rules: Enable ARM events --enable-arm (LP: #1769182)

rasdaemon (0.5.6-2ubuntu1) xenial; urgency=medium

  * Cherrypick upstream patches to support ARM kernel trace events.
LP: #1741978

 -- Manoj Iyer   Wed, 09 May 2018 14:54:44
-0500

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

** Changed in: rasdaemon (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/1769182

Title:
  ./configure --enable-arm needed for ARM events

Status in rasdaemon package in Ubuntu:
  Fix Released
Status in rasdaemon source package in Xenial:
  Fix Released
Status in rasdaemon source package in Artful:
  Fix Released
Status in rasdaemon source package in Bionic:
  Fix Released
Status in rasdaemon package in Debian:
  Fix Released

Bug description:
  [Impact]
  The UEFI 2.6 spec added support for ARM processor errors and errors
  that have unrecognized CPER section types. rasdaemon needs to support ARM 
kernel trace events. To enable arm events we need to configure rasdaemon 
package with --enable-arm 

  [Test]
  debian/rules needs --enable-arm to enable arm events. I have a test build of 
the rasdaemon package in ppa:centriq-team/lp1741978-rasdaemon. I tested this on 
an a QDF2400 system. Here are the results for bionic, artful and xenial.

  --- bionic ---
  ubuntu@awrep3:~$ sudo service rasdaemon status
  ● rasdaemon.service - RAS daemon to log the RAS events
 Loaded: loaded (/lib/systemd/system/rasdaemon.service; enabled; vendor 
preset
 Active: active (running) since Mon 2018-04-23 15:25:18 UTC; 17s ago
   Main PID: 3369 (rasdaemon)
  Tasks: 1 (limit: 7065)
 CGroup: /system.slice/rasdaemon.service
 └─3369 /usr/sbin/rasdaemon -f -r

  Apr 23 15:25:18 awrep3 rasdaemon[3369]: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Enabled event ras:arm_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Can't parse /proc/cpuinfo: missing 
[vend
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Can't register mce handler
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Can't get traces from ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording mc_event events
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording aer_event events
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording extlog_event 
events
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording mce_record events
  Apr 23 15:25:19 awrep3 rasdaemon[3369]: rasdaemon: Recording arm_event events

  ubuntu@awrep3:~$ grep rasdaemon /var/log/syslog 
  Apr 23 15:25:18 awrep3 rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Enabled event ras:mc_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Enabled event ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: Enabled event ras:mc_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Enabled event ras:arm_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't parse /proc/cpuinfo: 
missing [vendor_id] [cpu family] [model] [cpu MHz] [flags]
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't register mce handler
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't get 
ras:extlog_mem_event traces. Perhaps this feature is not supported on your 
system.
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't get traces from 
ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Listening to events for 
cpus 0 to 45
  Apr 23 15:25:18 awrep3 rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: Enabled event ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: ras:arm_event event enabled
  Apr 23 

[Group.of.nepali.translators] [Bug 1766832] Re: test_140_kernel_modules_not_tainted in kernel security test failed with 4.15 kvm kernel

[Launchpad Bug Tracker]

This bug was fixed in the package linux-kvm - 4.15.0-1010.10

---
linux-kvm (4.15.0-1010.10) bionic; urgency=medium

  [ Ubuntu: 4.15.0-22.24 ]

  * CVE-2018-3639 (powerpc)
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- stf-barrier: set eieio instruction bit 6 for future optimisations
  * CVE-2018-3639 (x86)
- x86/nospec: Simplify alternative_msr_write()
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static
  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

linux-kvm (4.15.0-1009.9) bionic; urgency=medium

  * linux-kvm: 4.15.0-1009.9 -proposed tracker (LP: #1767409)

  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Depends on linux-base that provides the necessary tools

  * Unable to start docker application with B-KVM kernel (LP: #1763630)
- kvm: [config] enable NF_NAT, NF_CONNTRACK
- kvm: [config] enable IP_NF_TABLES

  * test_078_SLAB_freelist_randomization failed on 4.15 KVM kernel
(LP: #1764975)
- kvm: [config] enable CONFIG_SLAB_FREELIST_{HARDENED,RANDOM}

  * linux-kvm 4.15 needs CONFIG_VMAP_STACK set (LP: #1764985)
- kvm: [config] enable CONFIG_VMAP_STACK

  * test_140_kernel_modules_not_tainted in kernel security test failed with 4.15
kvm kernel (LP: #1766832)
- kvm: [config] enable CONFIG_MODULE_UNLOAD

  [ Ubuntu: 4.15.0-21.22 ]

  * linux: 4.15.0-21.22 -proposed tracker (LP: #1767397)
  * initramfs-tools exception during pm.DoInstall with  do-release-upgrade from
16.04 to 18.04  (LP: #1766727)
- Add linux-image-* Breaks on s390-tools (<< 2.3.0-0ubuntu3)
  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Depends on linux-base that provides the necessary tools
  * linux-image packages need to Breaks flash-kernel << 3.90ubuntu2
(LP: #1766629)
- linux-image-* breaks on flash-kernel (<< 3.90ubuntu2)

 -- Stefan Bader   Thu, 17 May 2018 10:30:53
+0200

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

Title:
  test_140_kernel_modules_not_tainted in kernel security test failed
  with 4.15 kvm kernel

Status in linux-kvm package in Ubuntu:
  Fix Released
Status in linux-kvm source package in Xenial:
  Fix Committed
Status in linux-kvm source package in Bionic:
  Fix Released

Bug description:
  == Justification ==
  In the Bionic KVM and Xenial KVM kernel, the CONFIG_MODULE_UNLOAD was not 
set, this will cause the rmmod command in test_072_strict_devmem test from the 
kernel security test suite fail to run, and induce a failure in the following 
test_140_kernel_modules_not_tainted test.

  == Test ==
  Before enabling the config, rmmod command will return:
  "ERROR: Module signpost is in use"
  After the config was enabled, rmmod will succeed and it will pass with this 
test_140_kernel_modules_not_tainted test.

  == Fix ==
  Set CONFIG_MODULE_UNLOAD to "y" to allow 

[Group.of.nepali.translators] [Bug 1765564] Re: fsnotify: Fix fsnotify_mark_connector race

[Launchpad Bug Tracker]

This bug was fixed in the package linux-azure - 4.15.0-1012.12

---
linux-azure (4.15.0-1012.12) bionic; urgency=medium

  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Add versioned dependency for linux-base

  [ Ubuntu: 4.15.0-22.24 ]

  * CVE-2018-3639 (powerpc)
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- stf-barrier: set eieio instruction bit 6 for future optimisations
  * CVE-2018-3639 (x86)
- x86/nospec: Simplify alternative_msr_write()
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static
  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

  [ Ubuntu: 4.15.0-21.22 ]

  * linux: 4.15.0-21.22 -proposed tracker (LP: #1767397)
  * initramfs-tools exception during pm.DoInstall with  do-release-upgrade from
16.04 to 18.04  (LP: #1766727)
- Add linux-image-* Breaks on s390-tools (<< 2.3.0-0ubuntu3)
  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Depends on linux-base that provides the necessary tools
  * linux-image packages need to Breaks flash-kernel << 3.90ubuntu2
(LP: #1766629)
- linux-image-* breaks on flash-kernel (<< 3.90ubuntu2)

linux-azure (4.15.0-1011.11) bionic; urgency=medium

  * linux-azure: 4.15.0-1011.11 -proposed tracker (LP: #1770294)

  * fsnotify: Fix fsnotify_mark_connector race (LP: #1765564)
- fsnotify: Fix fsnotify_mark_connector race

 -- Stefan Bader   Wed, 16 May 2018 18:31:36
+0200

** Changed in: linux-azure (Ubuntu)
   Status: In Progress => 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/1765564

Title:
  fsnotify: Fix fsnotify_mark_connector race

Status in Linux:
  Incomplete
Status in linux package in Ubuntu:
  Invalid
Status in linux-azure package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Fix Released
Status in linux source package in Artful:
  Fix Committed
Status in linux-azure source package in Artful:
  Invalid
Status in linux source package in Bionic:
  Fix Committed
Status in linux-azure source package in Bionic:
  Fix Released

Bug description:
  On Azure we have had sporadic cases of soft lockups in fsnotify that
  may very well be mitigated by the following fix. The LKML thread is
  "kernel panics with 4.14.X".

  This should be applied to 4.13 and 4.15 versions of the linux-azure
  kernel, and possibly the 4.15 generic kernel in bionic as well.

  -

  fsnotify() acquires a reference to a fsnotify_mark_connector through
  the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
  appears that no precautions are taken in fsnotify_put_mark() to
  ensure that fsnotify() drops its reference to this
  fsnotify_mark_connector before assigning a value to its 'destroy_next'
  field. This can result in fsnotify_put_mark() assigning a value
  to a connector's 'destroy_next' field right before fsnotify() tries to
  traverse the 

[Group.of.nepali.translators] [Bug 1657682] Re: Support latest Redpine WLAN/BT RS9113 driver

[Launchpad Bug Tracker]

This bug was fixed in the package linux-oem - 4.15.0-1006.9

---
linux-oem (4.15.0-1006.9) bionic; urgency=medium

  * linux-image-4.15.0-20-generic install after upgrade from xenial breaks
(LP: #1767133)
- Packaging: Depends on linux-base that provides the necessary tools

  [ Ubuntu: 4.15.0-22.24 ]

  * CVE-2018-3639 (powerpc)
- powerpc/64s: Add support for a store forwarding barrier at kernel 
entry/exit
- stf-barrier: set eieio instruction bit 6 for future optimisations
  * CVE-2018-3639 (x86)
- x86/nospec: Simplify alternative_msr_write()
- x86/bugs: Concentrate bug detection into a separate function
- x86/bugs: Concentrate bug reporting into a separate function
- x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits
- x86/bugs, KVM: Support the combination of guest and host IBRS
- x86/bugs: Expose /sys/../spec_store_bypass
- x86/cpufeatures: Add X86_FEATURE_RDS
- x86/bugs: Provide boot parameters for the spec_store_bypass_disable
  mitigation
- x86/bugs/intel: Set proper CPU features and setup RDS
- x86/bugs: Whitelist allowed SPEC_CTRL MSR values
- x86/bugs/AMD: Add support to disable RDS on Fam[15,16,17]h if requested
- x86/KVM/VMX: Expose SPEC_CTRL Bit(2) to the guest
- x86/speculation: Create spec-ctrl.h to avoid include hell
- prctl: Add speculation control prctls
- x86/process: Allow runtime control of Speculative Store Bypass
- x86/speculation: Add prctl for Speculative Store Bypass mitigation
- nospec: Allow getting/setting on non-current task
- proc: Provide details on speculation flaw mitigations
- seccomp: Enable speculation flaw mitigations
- x86/bugs: Make boot modes __ro_after_init
- prctl: Add force disable speculation
- seccomp: Use PR_SPEC_FORCE_DISABLE
- seccomp: Add filter flag to opt-out of SSB mitigation
- seccomp: Move speculation migitation control to arch code
- x86/speculation: Make "seccomp" the default mode for Speculative Store
  Bypass
- x86/bugs: Rename _RDS to _SSBD
- proc: Use underscores for SSBD in 'status'
- Documentation/spec_ctrl: Do some minor cleanups
- x86/bugs: Fix __ssb_select_mitigation() return type
- x86/bugs: Make cpu_show_common() static
  * LSM Stacking prctl values should be redefined as to not collide with
upstream prctls (LP: #1769263) // CVE-2018-3639
- SAUCE: LSM stacking: adjust prctl values

linux-oem (4.15.0-1005.8) bionic; urgency=medium

  * linux-oem: 4.15.0-1005.8 -proposed tracker (LP: #1767398)
- source built with a clean tree

  * [i915 CNL-Y] system hangs soon after bootup (LP: #1769843)
- SAUCE: drm/i915/execlists: Use rmb() to order CSB reads

  * hts221 sensor stops working after resume from S3/S4 (LP: #1769658)
- SAUCE: iio: humidity: hts221: Fix sensor reads after resume

  * Support Intel Atom (Baytrail-I) HS-UART serdev slaves over tty
(LP: #1769610)
- serdev: ttyport: release tty lock sooner on open
- serdev: ttyport: ignore carrier detect to avoid hangups
- serdev: ttyport: do not used keyed wakeup in write_wakeup
- serdev: Make .remove in struct serdev_device_driver optional
- serdev: Introduce devm_serdev_device_open()
- serdev: do not generate modaliases for controllers
- serdev: only match serdev devices
- serdev: add method to set parity
- SAUCE: (no-up) Support HS-UART serdev slaves over tty
- [Config] CONFIG_HSUART_SERIAL_DEVICE=y

  * Support latest Redpine WLAN/BT RS9113 driver (LP: #1657682)
- SAUCE: rsi: add rx control block to handle rx packets in USB
- SAUCE: rsi: add bluetooth rx endpoint
- SAUCE: rsi: add header file rsi_91x
- SAUCE: rsi: add coex support
- SAUCE: Bluetooth: bt: rsi: add new rsi bluetooth driver
- SAUCE: rsi: handle BT traffic in driver
- SAUCE: rsi: add module parameter operating mode
- SAUCE: rsi: sdio changes to support BT
- SAUCE: rsi: improve RX handling in SDIO interface
- SAUCE: rsi: use dynamic RX control blocks instead of MAX_RX_URB
- SAUCE: rsi: improve RX packet handling in USB interface
- SAUCE: rsi: add support for hardware scan offload
- SAUCE: rsi: move xtend_desc structure from rsi_main.h to rsi_mgmt.h
- SAUCE: rsi: move descriptor preparation to core
- SAUCE: rsi: enable 80MHz clock by default
- SAUCE: rsi: roaming enhancements
- SAUCE: rsi: add module parameter rsi_reg
- SAUCE: rsi: regulatory modifications for 'dlcar' mode
- SAUCE: rsi: device disconnect changes
- SAUCE: rsi: tx improvements
- SAUCE: rsi: drop RX broadcast/multicast packets with invalid PN
- SAUCE: rsi: fix for incorrect data pointer alignment in 64-bit
- SAUCE: rsi: Remove stack VLA usage
- SAUCE: rsi: fix nommu_map_sg overflow kernel panic
- SAUCE: rsi: Fix 'invalid vdd' warning in mmc
- SAUCE: Redpine: Fix wowlan issue with S4
- SAUCE: Redpine: rsi: Add deep sleep enable 

[Group.of.nepali.translators] [Bug 1703415] Re: Bluetooth audio devices/profiles are missing after logging in from GDM

[Bug Watch Updater]

** Changed in: gdm
   Status: Confirmed => Expired

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

Title:
  Bluetooth audio devices/profiles are missing after logging in from GDM

Status in gdm:
  Expired
Status in PulseAudio:
  Confirmed
Status in gdm3 package in Ubuntu:
  Fix Released
Status in pulseaudio package in Ubuntu:
  Triaged
Status in gdm3 source package in Xenial:
  Triaged
Status in pulseaudio source package in Xenial:
  Triaged
Status in gdm3 source package in Zesty:
  Triaged
Status in pulseaudio source package in Zesty:
  Triaged
Status in gdm3 package in Debian:
  New

Bug description:
  This is actually a PulseAudio bug, but the workaround is to disable
  Bluetooth audio in GDM.

  Further discussion (and the source of my understanding about this
  issue) upstream are here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805414

  To summarise:

  GDM opens the A2DP profile for a11y purposes to allow screenreaders to
  output over BT audio devices. However Pulse doesn't release those
  devices when no audio is being played and the upshot is that once in
  the users session A2DP is not available for any Bluetooth audio
  devices, this means that you can only use the low quality profile
  HSP/HFP.

  There is a proposed workaround, but this means that a11y tools which
  need to output audio won't be able to use Bluetooth devices within
  GDM.

  I think that for 17.10 shipping this work-around is acceptable, and we
  should revisit in the 18.04 cycle to try and get a proper fix in PA.
  The suggested PA bug is:

  https://bugs.freedesktop.org/show_bug.cgi?id=57167

  but that hasn't seen movement since 2012.

  = The work around =

  From the Debian wiki:  https://wiki.debian.org/BluetoothUser/a2dp

  Disable the Bluetooth sink in the GDM PA daemon.

  Add this to /var/lib/gdm3/.config/pulse/default.pa

  #!/usr/bin/pulseaudio -nF
  #

  # load system wide configuration
  .include /etc/pulse/default.pa

  ### unload driver modules for Bluetooth hardware
  .ifexists module-bluetooth-policy.so
unload-module module-bluetooth-policy
  .endif

  .ifexists module-bluetooth-discover.so
unload-module module-bluetooth-discover
  .endif


  I have tested this, and I can confirm that it allows access to A2DP
  again in the user session.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gdm/+bug/1703415/+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 1769182] Re: ./configure --enable-arm needed for ARM events

[Launchpad Bug Tracker]

This bug was fixed in the package rasdaemon - 0.6.0-1ubuntu0.1

---
rasdaemon (0.6.0-1ubuntu0.1) bionic; urgency=medium

  * debian/rules: Enable ARM events --enable-arm (LP: #1769182)

 -- Manoj Iyer   Wed, 02 May 2018 15:01:16
-0500

** Changed in: rasdaemon (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/1769182

Title:
  ./configure --enable-arm needed for ARM events

Status in rasdaemon package in Ubuntu:
  Fix Released
Status in rasdaemon source package in Xenial:
  Fix Committed
Status in rasdaemon source package in Artful:
  Fix Committed
Status in rasdaemon source package in Bionic:
  Fix Released
Status in rasdaemon package in Debian:
  Fix Released

Bug description:
  [Impact]
  The UEFI 2.6 spec added support for ARM processor errors and errors
  that have unrecognized CPER section types. rasdaemon needs to support ARM 
kernel trace events. To enable arm events we need to configure rasdaemon 
package with --enable-arm 

  [Test]
  debian/rules needs --enable-arm to enable arm events. I have a test build of 
the rasdaemon package in ppa:centriq-team/lp1741978-rasdaemon. I tested this on 
an a QDF2400 system. Here are the results for bionic, artful and xenial.

  --- bionic ---
  ubuntu@awrep3:~$ sudo service rasdaemon status
  ● rasdaemon.service - RAS daemon to log the RAS events
 Loaded: loaded (/lib/systemd/system/rasdaemon.service; enabled; vendor 
preset
 Active: active (running) since Mon 2018-04-23 15:25:18 UTC; 17s ago
   Main PID: 3369 (rasdaemon)
  Tasks: 1 (limit: 7065)
 CGroup: /system.slice/rasdaemon.service
 └─3369 /usr/sbin/rasdaemon -f -r

  Apr 23 15:25:18 awrep3 rasdaemon[3369]: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Enabled event ras:arm_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Can't parse /proc/cpuinfo: missing 
[vend
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Can't register mce handler
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: Can't get traces from ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording mc_event events
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording aer_event events
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording extlog_event 
events
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Recording mce_record events
  Apr 23 15:25:19 awrep3 rasdaemon[3369]: rasdaemon: Recording arm_event events

  ubuntu@awrep3:~$ grep rasdaemon /var/log/syslog 
  Apr 23 15:25:18 awrep3 rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Enabled event ras:mc_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Enabled event ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: ras:mc_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon[3370]: rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: Enabled event ras:mc_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Enabled event ras:arm_event
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't parse /proc/cpuinfo: 
missing [vendor_id] [cpu family] [model] [cpu MHz] [flags]
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't register mce handler
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't get 
ras:extlog_mem_event traces. Perhaps this feature is not supported on your 
system.
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Can't get traces from 
ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon[3369]: rasdaemon: Listening to events for 
cpus 0 to 45
  Apr 23 15:25:18 awrep3 rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon: ras:aer_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: Enabled event ras:aer_event
  Apr 23 15:25:18 awrep3 rasdaemon: Can't write to set_event
  Apr 23 15:25:18 awrep3 rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: ras:arm_event event enabled
  Apr 23 15:25:18 awrep3 rasdaemon: Enabled event ras:arm_event
  Apr 23 15:25:18 awrep3 rasdaemon: Can't parse /proc/cpuinfo: missing 
[vendor_id] [cpu family] [model] [cpu MHz] [flags]
  Apr 23 15:25:18 awrep3 rasdaemon: Can't 

[Group.of.nepali.translators] [Bug 1771345] Re: lscpu possible crash in min/max frequency

[Launchpad Bug Tracker]

This bug was fixed in the package util-linux - 2.32-0.1ubuntu1

---
util-linux (2.32-0.1ubuntu1) cosmic; urgency=low

  * Merge from Debian unstable.  Remaining changes:
- Build hwclock with audit support.
- Drop debian/hwclock.rules and hwclock.default, recent kernels sync the
  RTC automatically.
- Add sulogin-fallback-static-sh.patch: Add support for /bin/static-sh as
  fallback if the regular shell fails to execute. Patch ported from
  sysvinit. (see LP #505887)
- Add sulogin-lockedpwd.patch: Make sure file systems can be fixed on
  machines with locked root accounts (as Ubuntu does by default). Don't
  require --force for sulogin.
- Drop the Breaks: cloud-utils, Ubuntu has a different cloud-utils
  packaging and this does not affect Ubuntu ≥ 16.04 any more.
- Add debian/util-linux.maintscript to clean upstart jobs on upgrade. This
  needs to be kept until after 18.04 LTS.
- Clean up weekly fstrim cron file, now a systemd timer unit.
- Remove obsolete upstart job files on upgrade of rfkill.  This change
  can be dropped after Ubuntu 18.04.
- Update s390-tools breaks/replaces, to the correct version for ubuntu.
- Enable fstrim.timer by default.
  * Dropped changes, merged upstream:
- Cherrypick upstream patches to add zones support to lsmem/chmem.
- lscpu: Decode ARM CPUs (patch taken from 2.32)
  * Bugs fixed in new upstream release:
- possible crash in min/max frequency (LP: #1771345)

util-linux (2.32-0.1) unstable; urgency=medium

  * Non-maintainer upload.
  [ Ben Hutchings ]
  * debian/control: Remove mention of minimum kernel version for rfkill

  [ Laurent Bigonville ]
  * New upstream release.
- Drop all the patches merged upstream
  * debian/libfdisk1.symbols: Add new exported symbols

util-linux (2.31.1-0.5) unstable; urgency=medium

  * Non-maintainer upload.

  [ Laurent Bigonville ]
  * debian/rules: Enable SMACK support for libmount
  * Enable audit support (Closes: #745771)

  [ Salvatore Bonaccorso ]
  * bash-completion: (umount) use findmnt, escape a space in paths.
(CVE-2018-7738)
Fixes "code execution in bash-completion for umount". (Closes: #892179)

util-linux (2.31.1-0.4ubuntu4) cosmic; urgency=medium

  * No-change rebuild for ncurses soname changes.

 -- Julian Andres Klode   Tue, 15 May 2018 15:45:21
+0200

** Changed in: util-linux (Ubuntu)
   Status: Fix Committed => Fix Released

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

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

Title:
  lscpu possible crash in min/max frequency

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  Fix Committed
Status in util-linux source package in Artful:
  Fix Released
Status in util-linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  lscpu prior to 2.32 does not correctly check for NULL members in min/max CPU 
frequency arrays and can call atof() on them, leading to crashes. It seems 
that's what caused the verification to fail for bug 1732865. The following 
fixes have been committed upstream:

  from 2.30: https://github.com/karelzak/util-
  linux/commit/0145d84a381fc2fcd7d37e0dbf3d9dff69609ecd

  from 2.32: https://github.com/karelzak/util-
  linux/commit/95f09bc63c564c50ec2c393352801cc056faaea2

  I plan to backport them to xenial (both patches); and artful, bionic
  (second patch, they are > 2.30).

  [Regression potential]
  The worst possible regression is that lscpu would fail to correctly report 
min/max frequencies, but it seems unlikely, as we're only adding checks against 
null pointers / move an atof into a loop.

  [Test case]
  Extract attached segvtest.tar.gz and run lscpu -s segvtest and check that it 
does not crash (this removes min mhz file for cpu #0 for testing).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1771345/+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 1615381] Re: apt-get autoremove may remove current kernel

[Eric Desrochers]

Thanks for the heads-up Balint.

I saw the "full backport" discussion in the ML, thanks !

For now, I'm setting Xenial as 'high' priority as it has been brought to
my attention that 'uu' in Xenial removed a running kernel recently :

/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
...
Removing linux-image-4.13.0-39-generic (4.13.0-39.44~16.04.1) ...^M
WARN: Proceeding with removing running kernel image.^M
...


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

** Also affects: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: unattended-upgrades (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: New => Confirmed

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

** Changed in: apt (Ubuntu Trusty)
   Status: New => Won't Fix

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

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

** Also affects: unattended-upgrades (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: apt (Ubuntu Artful)
   Status: New => Won't Fix

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

Title:
  apt-get autoremove may remove current kernel

Status in apt package in Ubuntu:
  Won't Fix
Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in apt source package in Trusty:
  Won't Fix
Status in unattended-upgrades source package in Trusty:
  New
Status in apt source package in Xenial:
  Won't Fix
Status in unattended-upgrades source package in Xenial:
  Confirmed
Status in apt source package in Artful:
  Won't Fix
Status in unattended-upgrades source package in Artful:
  New

Bug description:
  This may happen, if you boot one of the older kernels, that is not
  protected by /etc/apt/apt.conf.d/01autoremove-kernels

  Workaround: run
  /etc/kernel/postinst.d/apt-auto-removal
  during each boot (e.g. by using cron).
  Note: The workaround breaks autoremoving feature of new unneeded kernels in  
unattended-upgrades i.e. the setting 
'Unattended-Upgrade::Remove-New-Unused-Dependencies "true"' (which is default 
in 16.04 unless 'Unattended-Upgrade::Remove-Unused-Dependencies "true"' is set 
in '/etc/apt/apt.conf.d/50unattended-upgrades'.

  
  In shell:

  $ uname -r
  4.4.0-22-generic
  $ apt-get -s autoremove
  NOTE: This is only a simulation!
    apt-get needs root privileges for real execution.
    Keep also in mind that locking is deactivated,
    so don't depend on the relevance to the real current situation!
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following packages will be REMOVED:
    linux-headers-4.4.0-21 linux-headers-4.4.0-21-generic linux-headers-4.4.0-22
    linux-headers-4.4.0-22-generic linux-headers-4.4.0-31-generic
    linux-image-4.4.0-21-generic linux-image-4.4.0-22-generic
    linux-image-4.4.0-31-generic linux-image-extra-4.4.0-21-generic
    linux-image-extra-4.4.0-22-generic linux-image-extra-4.4.0-31-generic
  0 upgraded, 0 newly installed, 11 to remove and 13 not upgraded.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apt 1.2.12~ubuntu16.04.1
  ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8
  Uname: Linux 4.4.0-22-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CurrentDesktop: XFCE
  Date: Sun Aug 21 16:11:27 2016
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2016-04-28 (114 days ago)
  InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  SourcePackage: apt
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.kernel.postinst.d.apt-auto-removal: [modified]
  mtime.conffile..etc.kernel.postinst.d.apt-auto-removal: 
2016-07-30T12:15:32.706300

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1615381/+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 1772671] Re: Kernel produces empty lines in /proc/PID/status

[Tyler Hicks]

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

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

** Changed in: linux (Ubuntu Xenial)
   Status: Incomplete => In Progress

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Changed in: linux (Ubuntu)
   Status: Incomplete => Invalid

** Description changed:

+ [Impact]
+ The CVE-2018-3639 for Xenial introduced a double newline sequence in the 
/proc/PID/status files. This breaks some userspace tools, such as iotop, that 
parse those files.
+ 
+ [Test Case]
+ Incorrect output in 4.4.0-127.153-generic:
+ 
+ $ cat /proc/self/status
+  ...
+ Seccomp:  0
+ 
+ Speculation_Store_Bypass: thread vulnerable
+ ...
+ 
+ Expected output:
+ 
+ $ cat /proc/self/status
+  ...
+ Seccomp:  0
+ Speculation_Store_Bypass: thread vulnerable
+ ...
+ 
+ [Regression Potential]
+ None
+ 
+ [Original Report]
+ 
  Hello,
  
  after running updates today to linux-
  image-4.4.0-127-generic_4.4.0-127.153 and rebooting i noticed that iotop
  is not working any more. Reason are empty lines in /proc/PID/status,
  which confuse iotop (and me)
  
  In new view there is an empy line between Seccomp and
  Speculation_Store_Bypass:
  
  
  Seccomp:0
  
  Speculation_Store_Bypass:   vulnerable
  
  Speculation_Store_Bypass seems to be new in /proc/PID/status, may be a 
relation to spectre/meltdown patches.
  
  iotop is first application which is failing here, but iam afraid of
  more.
  
  Thanks

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

Title:
  Kernel produces empty lines in /proc/PID/status

Status in iotop package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in iotop source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  In Progress

Bug description:
  [Impact]
  The CVE-2018-3639 for Xenial introduced a double newline sequence in the 
/proc/PID/status files. This breaks some userspace tools, such as iotop, that 
parse those files.

  [Test Case]
  Incorrect output in 4.4.0-127.153-generic:

  $ cat /proc/self/status
   ...
  Seccomp:  0

  Speculation_Store_Bypass: thread vulnerable
  ...

  Expected output:

  $ cat /proc/self/status
   ...
  Seccomp:  0
  Speculation_Store_Bypass: thread vulnerable
  ...

  [Regression Potential]
  None

  [Original Report]

  Hello,

  after running updates today to linux-
  image-4.4.0-127-generic_4.4.0-127.153 and rebooting i noticed that
  iotop is not working any more. Reason are empty lines in
  /proc/PID/status, which confuse iotop (and me)

  In new view there is an empy line between Seccomp and
  Speculation_Store_Bypass:

  
  Seccomp:0

  Speculation_Store_Bypass:   vulnerable
  
  Speculation_Store_Bypass seems to be new in /proc/PID/status, may be a 
relation to spectre/meltdown patches.

  iotop is first application which is failing here, but iam afraid of
  more.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iotop/+bug/1772671/+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 1772935] Re: linux-hwe-edge: 4.15.0-23.25~16.04.1 -proposed tracker

[Brad Figg]

** Changed in: kernel-sru-workflow/prepare-package
   Status: In Progress => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-meta
   Status: In Progress => Fix Released

** Changed in: kernel-sru-workflow/prepare-package-signed
   Status: In Progress => Fix Released

** Description changed:

  This bug is for tracking the  upload package. This
  bug will contain status and testing results related to that upload.
  
  For an explanation of the tasks and the associated workflow see: 
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  -- swm properties --
  kernel-stable-master-bug: 1772927
  phase: Packaging
+ kernel-stable-phase:Uploaded
+ kernel-stable-phase-changed:Thursday, 24. May 2018 12:31 UTC

** Description changed:

  This bug is for tracking the  upload package. This
  bug will contain status and testing results related to that upload.
  
  For an explanation of the tasks and the associated workflow see: 
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  -- swm properties --
  kernel-stable-master-bug: 1772927
- phase: Packaging
- kernel-stable-phase:Uploaded
- kernel-stable-phase-changed:Thursday, 24. May 2018 12:31 UTC
+ phase: Uploaded

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

Title:
  linux-hwe-edge: 4.15.0-23.25~16.04.1 -proposed tracker

Status in Kernel SRU Workflow:
  In Progress
Status in Kernel SRU Workflow automated-testing series:
  New
Status in Kernel SRU Workflow certification-testing series:
  Invalid
Status in Kernel SRU Workflow prepare-package series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-meta series:
  Fix Released
Status in Kernel SRU Workflow prepare-package-signed series:
  Fix Released
Status in Kernel SRU Workflow promote-to-proposed series:
  New
Status in Kernel SRU Workflow promote-to-security series:
  New
Status in Kernel SRU Workflow promote-to-updates series:
  New
Status in Kernel SRU Workflow regression-testing series:
  New
Status in Kernel SRU Workflow security-signoff series:
  New
Status in Kernel SRU Workflow upload-to-ppa series:
  New
Status in Kernel SRU Workflow verification-testing series:
  New
Status in linux-hwe-edge package in Ubuntu:
  Invalid
Status in linux-hwe-edge source package in Xenial:
  Confirmed

Bug description:
  This bug is for tracking the  upload package.
  This bug will contain status and testing results related to that
  upload.

  For an explanation of the tasks and the associated workflow see: 
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
  -- swm properties --
  kernel-stable-master-bug: 1772927
  phase: Uploaded

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel-sru-workflow/+bug/1772935/+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 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package vlan - 1.9-3.2ubuntu5.17.10.1

---
vlan (1.9-3.2ubuntu5.17.10.1) artful; urgency=medium

  * Revert change for lp1573272; instead fix by redesigning when vlan
interfaces are created; after raw-device ifup, not during raw-device
udev processing. (LP: #1701023)

 -- Dan Streetman   Thu, 19 Apr 2018 18:10:17
-0400

** Changed in: vlan (Ubuntu Artful)
   Status: Fix Committed => Fix Released

** Changed in: ifupdown (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Released
Status in vlan source package in Trusty:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in vlan source package in Xenial:
  Fix Released
Status in ifupdown source package in Artful:
  Fix Released
Status in vlan source package in Artful:
  Fix Released
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package vlan - 1.9-3.2ubuntu1.16.04.5

---
vlan (1.9-3.2ubuntu1.16.04.5) xenial; urgency=medium

  * Revert change for lp1573272; instead fix by redesigning when vlan
interfaces are created; after raw-device ifup, not during raw-device
udev processing. (LP: #1701023)

 -- Dan Streetman   Thu, 19 Apr 2018 18:10:17
-0400

** Changed in: ifupdown (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Released
Status in vlan source package in Trusty:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in vlan source package in Xenial:
  Fix Released
Status in ifupdown source package in Artful:
  Fix Released
Status in vlan source package in Artful:
  Fix Released
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

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

[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package vlan - 1.9-3ubuntu10.6

---
vlan (1.9-3ubuntu10.6) trusty; urgency=medium

  * Revert change for lp1573272; instead fix by redesigning when vlan
interfaces are created; after raw-device ifup, not during raw-device
udev processing. (LP: #1701023)

 -- Dan Streetman   Thu, 19 Apr 2018 18:10:17
-0400

** Changed in: ifupdown (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Released
Status in vlan source package in Trusty:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in vlan source package in Xenial:
  Fix Released
Status in ifupdown source package in Artful:
  Fix Released
Status in vlan source package in Artful:
  Fix Released
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

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

[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package ifupdown - 0.8.10ubuntu1.4

---
ifupdown (0.8.10ubuntu1.4) xenial; urgency=medium

  * We are not even reading the contents of the per-interface state files
when running ifquery, so there is no need to lock them. Not locking
will allow ifquery to be called recursively from ifup and ifdown.
(LP: #1701023)

 -- Dan Streetman   Fri, 27 Apr 2018 08:56:12
-0400

** Changed in: vlan (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Released
Status in vlan source package in Trusty:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in vlan source package in Xenial:
  Fix Released
Status in ifupdown source package in Artful:
  Fix Released
Status in vlan source package in Artful:
  Fix Released
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

___
Mailing list: 

[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package ifupdown - 0.8.16ubuntu2.1

---
ifupdown (0.8.16ubuntu2.1) artful; urgency=medium

  * We are not even reading the contents of the per-interface state files
when running ifquery, so there is no need to lock them. Not locking
will allow ifquery to be called recursively from ifup and ifdown.
(LP: #1701023)

 -- Dan Streetman   Fri, 27 Apr 2018 08:53:27
-0400

** Changed in: vlan (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Released
Status in vlan source package in Trusty:
  Fix Released
Status in ifupdown source package in Xenial:
  Fix Released
Status in vlan source package in Xenial:
  Fix Released
Status in ifupdown source package in Artful:
  Fix Released
Status in vlan source package in Artful:
  Fix Released
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

___
Mailing list: 

[Group.of.nepali.translators] [Bug 1771345] Re: lscpu possible crash in min/max frequency

[Launchpad Bug Tracker]

This bug was fixed in the package util-linux - 2.30.1-0ubuntu4.2

---
util-linux (2.30.1-0ubuntu4.2) artful; urgency=medium

  * d/patches/Avoid-crash-in-min-max-caculation-when-cpu-0-being-o.patch:
Cherry pick upstream patch to avoid SEGV in min/max frequency.
LP: #1771345

 -- Julian Andres Klode   Wed, 16 May 2018 12:44:06
+0200

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

Title:
  lscpu possible crash in min/max frequency

Status in util-linux package in Ubuntu:
  Fix Committed
Status in util-linux source package in Xenial:
  Fix Committed
Status in util-linux source package in Artful:
  Fix Released
Status in util-linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  lscpu prior to 2.32 does not correctly check for NULL members in min/max CPU 
frequency arrays and can call atof() on them, leading to crashes. It seems 
that's what caused the verification to fail for bug 1732865. The following 
fixes have been committed upstream:

  from 2.30: https://github.com/karelzak/util-
  linux/commit/0145d84a381fc2fcd7d37e0dbf3d9dff69609ecd

  from 2.32: https://github.com/karelzak/util-
  linux/commit/95f09bc63c564c50ec2c393352801cc056faaea2

  I plan to backport them to xenial (both patches); and artful, bionic
  (second patch, they are > 2.30).

  [Regression potential]
  The worst possible regression is that lscpu would fail to correctly report 
min/max frequencies, but it seems unlikely, as we're only adding checks against 
null pointers / move an atof into a loop.

  [Test case]
  Extract attached segvtest.tar.gz and run lscpu -s segvtest and check that it 
does not crash (this removes min mhz file for cpu #0 for testing).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1771345/+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 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package vlan - 1.9-3.2ubuntu6

---
vlan (1.9-3.2ubuntu6) bionic; urgency=medium

  * Revert change for lp1573272; instead fix by redesigning when vlan
interfaces are created; after raw-device ifup, not during raw-device
udev processing. (LP: #1701023)

 -- Dan Streetman   Thu, 19 Apr 2018 18:10:17
-0400

** Changed in: vlan (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Committed
Status in vlan source package in Trusty:
  Fix Committed
Status in ifupdown source package in Xenial:
  Fix Committed
Status in vlan source package in Xenial:
  Fix Committed
Status in ifupdown source package in Artful:
  Fix Committed
Status in vlan source package in Artful:
  Fix Committed
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

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

[Group.of.nepali.translators] [Bug 1701023] Re: (on trusty) version 1.9-3ubuntu10.4 regression blocking boot completion

[Launchpad Bug Tracker]

This bug was fixed in the package ifupdown - 0.8.17ubuntu1.1

---
ifupdown (0.8.17ubuntu1.1) bionic; urgency=medium

  * We are not even reading the contents of the per-interface state files
when running ifquery, so there is no need to lock them. Not locking
will allow ifquery to be called recursively from ifup and ifdown.
(LP: #1701023)

 -- Dan Streetman   Fri, 27 Apr 2018 08:00:07
-0400

** Changed in: ifupdown (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/1701023

Title:
  (on trusty) version 1.9-3ubuntu10.4 regression blocking boot
  completion

Status in ifupdown package in Ubuntu:
  In Progress
Status in vlan package in Ubuntu:
  Fix Released
Status in ifupdown source package in Trusty:
  Fix Committed
Status in vlan source package in Trusty:
  Fix Committed
Status in ifupdown source package in Xenial:
  Fix Committed
Status in vlan source package in Xenial:
  Fix Committed
Status in ifupdown source package in Artful:
  Fix Committed
Status in vlan source package in Artful:
  Fix Committed
Status in ifupdown source package in Bionic:
  Fix Released
Status in vlan source package in Bionic:
  Fix Released
Status in ifupdown package in Debian:
  Fix Released
Status in vlan package in Debian:
  New

Bug description:
  [impact]

  in bug 1573272, the vlan pkg was changed to perform a full ifup inside
  its if-pre-up.d/vlan script.  This allowed correct ordering of ifup
  for a vlan and its raw-device, as previously there was a race
  condition between them (see that bug for details).

  However, this causes hangs during ifup with certain specific configs.
  The reasons are given starting in comment 13.

  The result is a regression for those using the specific ifupdown
  configs; when they try to reboot and/or ifup -a, it will hang trying
  to bring up their network, preventing boot from finishing (or hanging
  before the network is fully configured).

  [test case]

  upgrade to the latest vlan package and configure the system with an
  affected ifupdown config, then reboot.  The reboot will hang while
  trying to bring the network up.

  see the original description below for an example ifupdown config to
  reproduce this, although there are other possible configs that
  will/may trigger this regression.

  [regression potential]

  The fix for this moves the creation of the vlan(s) corresponding to a
  physical raw-device 'hotplug' event out of the udev processing path
  for the raw-device, and into an ifup post script for the raw-device
  ifup.  If this is not done correctly, then any interfaces that are
  hotplugged, and have vlans configured on them, may fail to correctly
  create/configure their vlan(s).

  This change does remove the direct call to ifup from the if-pre-up.d
  (or if-up.d) scripts, so there should not be any regression potential
  for more ifup deadlocks.

  [other info]

  this required both ifupdown and vlan to be patched.  vlan was patched
  to remove the problematic call to ifup from the vlan pre-up script,
  and add a call to create the vlan interface(s) from a new post-up
  script, as well as adding a parameter to vlan-network-interface script
  to handle the call from udev itself differently than a call from
  elsewhere (such as the if-up.d/vlan script).  this works for bootup
  and ifup/ifup -a, but fails for device hotplug because of a bug in
  ifupdown that prevents calling ifquery from an ifup script; that has
  been patched upstream already, and is the only ifupdown change needed
  here.

  
  [original description]

  When upgrading from version 1.9-3ubuntu10.1, a previously working
  machine can't successfully reboot completely.

  ifup is hanging indefinitely, with this process structure (from
  "pstree -a 1299"):

  ifup,1299 -a
    └─run-parts,1501 /etc/network/if-pre-up.d
    └─bridge,1502 /etc/network/if-pre-up.d/bridge
    └─bridge,1508 /etc/network/if-pre-up.d/bridge
    └─vlan,1511 /etc/network/if-pre-up.d/vlan
    └─ifup,1532 eth0

  
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
    address 192.168.10.65
    netmask 255.255.255.192
    gateway 192.168.10.66

  auto eth0.11
    address 192.168.11.1
    netmask 255.255.255.0

  auto br1134
  iface br1134 inet manual
    bridge_ports eth0.1134
    bridge_stp off
    bridge_fd 0
  

  The underlying interface eth0.1134 is not explicitly defined, but was
  previously auto-created during "ifup -a" execution. This apparently
  fails now.

  Reverting back to the 10.1 version re-establishes old behavior.

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

___
Mailing 

[Group.of.nepali.translators] [Bug 1771345] Re: lscpu possible crash in min/max frequency

[Launchpad Bug Tracker]

This bug was fixed in the package util-linux - 2.31.1-0.4ubuntu3.1

---
util-linux (2.31.1-0.4ubuntu3.1) bionic; urgency=medium

  * d/patches/Avoid-crash-in-min-max-caculation-when-cpu-0-being-o.patch:
Cherry pick upstream patch to avoid SEGV in min/max frequency.
LP: #1771345

 -- Julian Andres Klode   Wed, 16 May 2018 12:41:37
+0200

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

Title:
  lscpu possible crash in min/max frequency

Status in util-linux package in Ubuntu:
  Fix Committed
Status in util-linux source package in Xenial:
  Fix Committed
Status in util-linux source package in Artful:
  Fix Committed
Status in util-linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  lscpu prior to 2.32 does not correctly check for NULL members in min/max CPU 
frequency arrays and can call atof() on them, leading to crashes. It seems 
that's what caused the verification to fail for bug 1732865. The following 
fixes have been committed upstream:

  from 2.30: https://github.com/karelzak/util-
  linux/commit/0145d84a381fc2fcd7d37e0dbf3d9dff69609ecd

  from 2.32: https://github.com/karelzak/util-
  linux/commit/95f09bc63c564c50ec2c393352801cc056faaea2

  I plan to backport them to xenial (both patches); and artful, bionic
  (second patch, they are > 2.30).

  [Regression potential]
  The worst possible regression is that lscpu would fail to correctly report 
min/max frequencies, but it seems unlikely, as we're only adding checks against 
null pointers / move an atof into a loop.

  [Test case]
  Extract attached segvtest.tar.gz and run lscpu -s segvtest and check that it 
does not crash (this removes min mhz file for cpu #0 for testing).

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