[Group.of.nepali.translators] [Bug 1800562] Re: Remove obsolete "nousb" option in kdump command-line for newer kernels

[dann frazier]

** Also affects: kdump-tools (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: kdump-tools (Ubuntu)

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

Title:
  Remove obsolete "nousb" option in kdump command-line for newer kernels

Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kdump-tools source package in Xenial:
  New
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in kdump-tools source package in Bionic:
  New
Status in makedumpfile source package in Bionic:
  Confirmed
Status in kdump-tools source package in Eoan:
  New
Status in makedumpfile source package in Eoan:
  Won't Fix
Status in kdump-tools source package in Focal:
  New
Status in makedumpfile source package in Focal:
  Confirmed
Status in kdump-tools source package in Groovy:
  New
Status in makedumpfile source package in Groovy:
  Won't Fix

Bug description:
  [Impact]
  * Kdump command-line include an obsolete "nousb" parameter by default, which 
can cause a misimpression: users will think they are not booting with USB, but 
they are.

  * Since kernel v4.5, the correct parameter to disable USB subsystem
  initialization is "usbcore.nousb" always (instead of "nousb" in case
  the subsystem is built-in). This was changed by commit 097a9ea0e48
  ("usb: make "nousb" a clear module parameter").

  * USB may be pretty essential in case for example kdump users need to
  decrypt a disk under LUKS, and there's only an USB keyboard connected
  to the system. Given the option is innocuous since Bionic, we should
  just drop it to prevent confusion.

  
  [Test Case]

  1) Deploy a Disco VM e.g. with uvt-kvm
  2) Install the kdump-tools package
  3) Run `kdump-config test`and check for the 'nousb' parameter:

  $ kdump-config test
  ...
  kexec command to be used:
    /sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic 
root=LABEL=cloudimg-rootfs ro console=tty1 console=ttyS0 nr_cpus=1 
systemd.unit=kdump-tools.service irqpoll nousb ata_piix.prefer_ms_hyperv=0" 
/var/lib/kdump/vmlinuz

  
  [Regression Potential]

  The regression potential is extremely low, since the "nousb" parameter
  is not used since Bionic although is there. Any bugs we would have by
  changing this are still valid by not removing the option - the
  semantics with or without "nosub" is the same since from Bionic.

  NOTICE we won't change Xenial, it can use kernel 4.4 which indeed
  disables USB by taking the "nousb" parameter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+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 1845048] Re: Improve sysctl handling on kdump-tools

[dann frazier]

Guillherme's MR was merged in 1.6.8-1, so marking Fix Released.

** Changed in: kdump-tools (Ubuntu)
   Status: New => Fix Released

** Changed in: makedumpfile (Ubuntu)
   Status: In Progress => Invalid

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

Title:
  Improve sysctl handling on kdump-tools

Status in kdump-tools package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Invalid
Status in makedumpfile source package in Xenial:
  Opinion
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Eoan:
  Won't Fix
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Groovy:
  Fix Released
Status in kdump-tools package in Debian:
  New

Bug description:
  [impact]

  Documentation, and past behavior, for kdump-tools was that the
  KDUMP_SYSCTL variable in the /etc/default/kdump-tools file would be
  applied to the system kernel params at kdump 'load'.  However this is
  no longer true, and those params are no longer applied to the system's
  kernel param settings.

  [test case]

  install linux-crashdump (and kdump-tools).

  Edit the /etc/default/kdump-tools file to set the KDUMP_SYSCTL param
  to something other than default, e.g.:

  KDUMP_SYSCTL="kernel.panic_on_oops=1 kernel.panic_on_warn=1"

  reboot, or unload/reload kdump, to pick up the changes to the file.

  Check if the panic_on_warn param is set:

  $ cat /proc/sys/kernel/panic_on_warn
  0

  the problem does not seem to be with sysctl, as manually calling it
  does work:

  $ KDUMP_SYSCTL="kernel.panic_on_oops=1 kernel.panic_on_warn=1"
  $ cat /proc/sys/kernel/panic_on_warn
  0
  $ sudo sysctl -w $KDUMP_SYSCTL
  kernel.panic_on_oops = 1
  kernel.panic_on_warn = 1
  $ cat /proc/sys/kernel/panic_on_warn
  1

  [regression potential]

  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/1845048/+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 1845048] Re: Improve sysctl handling on kdump-tools

[dann frazier]

Correction: looks like it was 1:1.6.7-4. git-debrebase confused me.

** Changed in: makedumpfile (Ubuntu Groovy)
   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/1845048

Title:
  Improve sysctl handling on kdump-tools

Status in kdump-tools package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Invalid
Status in makedumpfile source package in Xenial:
  Opinion
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Eoan:
  Won't Fix
Status in makedumpfile source package in Focal:
  In Progress
Status in makedumpfile source package in Groovy:
  Fix Released
Status in kdump-tools package in Debian:
  New

Bug description:
  [impact]

  Documentation, and past behavior, for kdump-tools was that the
  KDUMP_SYSCTL variable in the /etc/default/kdump-tools file would be
  applied to the system kernel params at kdump 'load'.  However this is
  no longer true, and those params are no longer applied to the system's
  kernel param settings.

  [test case]

  install linux-crashdump (and kdump-tools).

  Edit the /etc/default/kdump-tools file to set the KDUMP_SYSCTL param
  to something other than default, e.g.:

  KDUMP_SYSCTL="kernel.panic_on_oops=1 kernel.panic_on_warn=1"

  reboot, or unload/reload kdump, to pick up the changes to the file.

  Check if the panic_on_warn param is set:

  $ cat /proc/sys/kernel/panic_on_warn
  0

  the problem does not seem to be with sysctl, as manually calling it
  does work:

  $ KDUMP_SYSCTL="kernel.panic_on_oops=1 kernel.panic_on_warn=1"
  $ cat /proc/sys/kernel/panic_on_warn
  0
  $ sudo sysctl -w $KDUMP_SYSCTL
  kernel.panic_on_oops = 1
  kernel.panic_on_warn = 1
  $ cat /proc/sys/kernel/panic_on_warn
  1

  [regression potential]

  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kdump-tools/+bug/1845048/+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 1936857] Re: grub-install: error: efibootmgr: not found.

[dann frazier]

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

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

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

Title:
  grub-install: error: efibootmgr: not found.

Status in grub2 package in Ubuntu:
  New
Status in grub2 source package in Xenial:
  Confirmed
Status in grub2 source package in Bionic:
  Confirmed

Bug description:
  grub-install from 2.02~beta2-36ubuntu3.32 on xenial/arm64 fails with:

  ubuntu@ubuntu:~$ sudo grub-install
  Installing for arm64-efi platform.
  grub-install: error: efibootmgr: not found.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1936857/+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 1936857] [NEW] grub-install: error: efibootmgr: not found.

[dann frazier]

Public bug reported:

grub-install from 2.02~beta2-36ubuntu3.32 on xenial/arm64 fails with:

ubuntu@ubuntu:~$ sudo grub-install
Installing for arm64-efi platform.
grub-install: error: efibootmgr: not found.

** Affects: grub2 (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: grub2 (Ubuntu Xenial)
 Importance: Undecided
 Status: Confirmed

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

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

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

Title:
  grub-install: error: efibootmgr: not found.

Status in grub2 package in Ubuntu:
  New
Status in grub2 source package in Xenial:
  Confirmed

Bug description:
  grub-install from 2.02~beta2-36ubuntu3.32 on xenial/arm64 fails with:

  ubuntu@ubuntu:~$ sudo grub-install
  Installing for arm64-efi platform.
  grub-install: error: efibootmgr: not found.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1936857/+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 1766728] Re: update linux-base on xenial and earlier

[dann frazier]

Marking the devel release fixed as well, since backport versions are by
definition already fixed there.

** Changed in: linux-base (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  update linux-base on xenial and earlier

Status in linux-base package in Ubuntu:
  Fix Released
Status in linux-base source package in Precise:
  Fix Released
Status in linux-base source package in Trusty:
  Fix Released
Status in linux-base source package in Xenial:
  Fix Released
Status in linux-base source package in Artful:
  Invalid

Bug description:
  [Impact]

  After some changes on linux package on bionic, linux-azure-edge and
  linux-hwe-edge, which are based on that package, now require a linux-
  base that provides linux-update-symlinks and linux-check-removal.
  Using the latest version also means translations will be present.

  [Test Case]

  Installing the latest linux-azure-edge will fail the config stage
  because maintainer scripts call into non-existing linux-update-
  symlinks and linux-check-removal.

  Test result: It works with xenial kernels and fixes the problem with
  hwe-edge.

  [Regression Potential]

  New functions on perl module are tested during build time. It could
  break symlinks creation for other kernels. perf bash completion is not
  distributed, so does not conflict with linux-tools-common. Older
  kernels still have their links working.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-base/+bug/1766728/+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 1916063] [NEW] sru curtin 2021-02-18 - 21.2-0ubuntu1

[dann frazier]

Public bug reported:

[  Should we request that the MAAS testing portion of curtin's 
  SRU Special Case Exception be omitted for >= focal, since
  MAAS has migrated to a snap there, and MAAS PPAs provide
  their own curtin builds? ]

[  This template is seeded by a cut & paste of the last SRU bug
  I found, bug 1881003. ]

== Begin SRU Template ==
[Impact]
This release sports both bug-fixes and new features and we would like to
make sure all of our supported customers have access to these improvements.

See the changelog entry below for a full list of changes and bugs.

[Test Case]
The following development and SRU process was followed:
https://wiki.ubuntu.com/CurtinUpdates

Curtin now contains an extensive integration test suite that is ran using
the SRU package for each releases. These suite has documentation here:
https://curtin.readthedocs.io/en/latest/topics/integration-testing.html

In order to avoid regression to existing MAAS product, the MAAS team will
run their continuous integration test against the curtin that is in
-proposed. A successful run will be required before the proposed curtin
can be let into -updates.

The curtin team will be in charge of attaching the artifacts and console
output of the appropriate run to the bug. Curtin team members will not
mark ‘verification-done’ until this has happened.

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

== End SRU Template ==
* New upstream release.
  - Release 21.2 [Michael Hudson-Doyle] (LP: #1913357)
  - Revert "apt_config: stop using the deprecated apt-key command"
[Michael Hudson-Doyle] (LP: #1912801)
  - partition_handler: fix NameError when reusing a vtoc partition
[Michael Hudson-Doyle]
  - install_grub: convert in-target EFI loader path to ESP path.
[Dimitri John Ledkov] (LP: #1906379)
  - block: fixes for verifying existing multipath partitions
[Michael Hudson-Doyle]
  - multipath: use udev DM_NAME for find_mpath_id, fix 4k sector calc
[Michael Hudson-Doyle] (LP: #1878041)
* New upstream release.
  - Release 21.1 [Michael Hudson-Doyle] (LP: #1911841)
  - This adds arm64 compatibility for RH installations [Mark Klein]
  - vmtest: add Hirsute release classes, tool to add vmtest class
[Ryan Harper]
  - vmtest: fix image-sync after maas URL stream rename
[Ryan Harper] (LP: #1908543)
  - storage_config: set ptable to vtoc for 'virt' dasds as well as 'ECKD'
[Michael Hudson-Doyle]
  - install_grub: Fix bootloader-id for RHEL systems, must be redhat
[Ryan Harper] (LP: #1906543)
  - vmtests: remove LP: #1888726 skip_by_date decorators
  - storage_config: only produce type: dasd actions for ECKD dasds
[Michael Hudson-Doyle]
  - storage_config: handle some FBA dasd oddities [Michael Hudson-Doyle]
  - apt_config: stop using the deprecated apt-key command
[Nishanth Aravamudan] (LP: #1892494)
  - allow adding a vtoc partition without a device id [Michael Hudson-Doyle]
  - simplify dasdview parsing code [Michael Hudson-Doyle]
  - fix construction of DasdPartitionTable from fdasd output
[Michael Hudson-Doyle]
  - Don't install grub if it is already found on CentOS/RHEL
[Lee Trager] (LP: #1895067)
  - vmtests: Replace newly added Eoan test with Groovy [Ryan Harper]
  - vmtests: test using a disk with RAID partition on it directly in a RAID
[Michael Hudson-Doyle]
  - fix verification of vtoc partitions [Michael Hudson-Doyle] (LP: #1899471)
  - create an empty vtoc in disk_handler [Michael Hudson-Doyle]
  - remove unused parameters from dasd code [Michael Hudson-Doyle]
  - remove support for calling get_path_to_storage_volume on a dasd action
[Michael Hudson-Doyle]
  - clear-holders: fix identification of multipath partitions
[Ryan Harper] (LP: #1900900)
  - vmtests: remove skip_by_dates for now-fixed bcache issue
  - debian/rules: drop PKG_VERSION and UPSTREAM_VERSION [Paride Legovini]
  - deb packaging: fully cleanup directory tree after build
[Paride Legovini] (LP: #1899698)
  - udevadm_info should use maxsplit=1 instead of maxsplit=2
[Sergey Bykov] (LP: #1895021)
  - vmtests/multipath-lvm: dont assume device-mapper block names
[Ryan Harper] (LP: #1898758)
  - vmtest: fix the groovy arm64 subarch [Paride Legovini] (LP: #1898757)
  - tools/curtainer: dearmor gpg key and use apt-key add
[Ryan Harper] (LP: #1898609)
  - Support imsm external metadata RAID containers
[Gyorgy Szombathelyi] (LP: #1893661)
  - Drop tools/new-upstream-snapshot [Paride Legovini]
* New upstream release.
  - Release 20.2 (LP: #1896947)
- Handle multiple separators which were found in TestAllindata vmtest
- verify_ptable_flag: dos primary partitions use ptable_uuid map for flag
- net_meta: add disabled mode to skip writing any network config
  [Lucas Moura]
- vmtest: trigger guest panic to fail fast
- Replace grub-shell-helper with 

[Group.of.nepali.translators] [Bug 1900796] Re: Moonshot ProLiant m400 fails to boot "Wrong Ramdisk Image Format"

[dann frazier]

** Also affects: flash-kernel (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: plymouth (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: flash-kernel (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: flash-kernel (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: plymouth (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: flash-kernel (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: flash-kernel (Ubuntu Hirsute)
   Importance: Undecided
   Status: Fix Released

** Also affects: plymouth (Ubuntu Hirsute)
   Importance: Undecided
   Status: Invalid

** Changed in: plymouth (Ubuntu Groovy)
   Status: New => Invalid

** Changed in: plymouth (Ubuntu Focal)
   Status: New => Invalid

** Changed in: plymouth (Ubuntu Bionic)
   Status: New => Invalid

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

** Changed in: flash-kernel (Ubuntu Groovy)
   Status: New => Confirmed

** Changed in: flash-kernel (Ubuntu Focal)
   Status: New => Confirmed

** Changed in: flash-kernel (Ubuntu Bionic)
   Status: New => Confirmed

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

Title:
  Moonshot ProLiant m400 fails to boot "Wrong Ramdisk Image Format"

Status in ubuntu-kernel-tests:
  New
Status in flash-kernel package in Ubuntu:
  Fix Released
Status in plymouth package in Ubuntu:
  Invalid
Status in flash-kernel source package in Xenial:
  New
Status in plymouth source package in Xenial:
  Invalid
Status in flash-kernel source package in Bionic:
  Confirmed
Status in plymouth source package in Bionic:
  Invalid
Status in flash-kernel source package in Focal:
  Confirmed
Status in plymouth source package in Focal:
  Invalid
Status in flash-kernel source package in Groovy:
  Confirmed
Status in plymouth source package in Groovy:
  Invalid
Status in flash-kernel source package in Hirsute:
  Fix Released
Status in plymouth source package in Hirsute:
  Invalid

Bug description:
  Issue found on ARM64 node ms10-35-mcdivittb0-kernel with F-5.8.
  Install the plymouth package from proposed will cause system failed to boot, 
with error message:
    Wrong Ramdisk Image Format
    Ramdisk image is corrupt or invalid

  It's 100% reproducible.

  Steps to reproduce this:
  1. Deploy Focal on this node (Architecture set to arm64/xgene-uboot, it can't 
be deployed if set to arm64/generic, PXE boot failed with TFTP error: 'File not 
found' (1))
  2. Enable proposed pocket.
  3. Install the linux-generic-hwe-20.04-edge and reboot
  4. It's now running with 5.8.0-25-generic on Focal
  5. Install plymouth from proposed and reboot

  In step 5 it will generate the new boot image.

  $ sudo apt install plymouth
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following additional packages will be installed:
    plymouth-theme-ubuntu-text
  Suggested packages:
    desktop-base plymouth-themes
  The following packages will be upgraded:
    plymouth plymouth-theme-ubuntu-text
  2 upgraded, 0 newly installed, 0 to remove and 18 not upgraded.
  Need to get 121 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Do you want to continue? [Y/n]
  Get:1 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 
plymouth-theme-ubuntu-text arm64 0.9.4git20200323-0ubuntu6.1 [9148 B]
  Get:2 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main arm64 plymouth 
arm64 0.9.4git20200323-0ubuntu6.1 [112 kB]
  Fetched 121 kB in 0s (326 kB/s)
  (Reading database ... 112559 files and directories currently installed.)
  Preparing to unpack 
.../plymouth-theme-ubuntu-text_0.9.4git20200323-0ubuntu6.1_arm64.deb ...
  Unpacking plymouth-theme-ubuntu-text (0.9.4git20200323-0ubuntu6.1) over 
(0.9.4git20200323-0ubuntu6) ...
  Preparing to unpack .../plymouth_0.9.4git20200323-0ubuntu6.1_arm64.deb ...
  Unpacking plymouth (0.9.4git20200323-0ubuntu6.1) over 
(0.9.4git20200323-0ubuntu6) ...
  Setting up plymouth (0.9.4git20200323-0ubuntu6.1) ...
  update-initramfs: deferring update (trigger activated)
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  Setting up plymouth-theme-ubuntu-text (0.9.4git20200323-0ubuntu6.1) ...
  update-initramfs: deferring update (trigger activated)
  Processing triggers for man-db (2.9.1-1) ...
  Processing triggers for systemd (245.4-4ubuntu3.2) ...
  Processing 

[Group.of.nepali.translators] [Bug 1907489] [NEW] restore reverted commit "crypto: arm64/sha - avoid non-standard inline asm tricks"

[dann frazier]

Public bug reported:

[Impact]
To address bug 1905336, we reverted an upstream commit. Upstream have now 
pulled in a commit to properly fix the underlying issue. Once we merge that 
fix, we should be able to reapply the reverted commit.

[Test Case]
If the kernel boots and we can still load the sha{1,2}_ce modules, we should be 
good.

[Fix]
After this is applied:
  https://www.spinics.net/lists/stable/msg431217.html
We should reapply the commit we reverted here:
  
https://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=4baa2fdd354700e2304e10cdbc64402621c3fa29


[Where Problems May Occur]
Although we shipped the reverted patch for many releases - the whole time we 
did so, the impacted modules were not loadable. Once we reapply it, xenial 
users will be running that code for the first time. If there are issues with 
the code, users of the sha{1,2}_ce modules may now hit them. Issues could 
include kernel oopses, corruption, etc.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Invalid

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Assignee: dann frazier (dannf)
 Status: In Progress

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

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

Title:
  restore reverted commit "crypto: arm64/sha - avoid non-standard inline
  asm tricks"

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

Bug description:
  [Impact]
  To address bug 1905336, we reverted an upstream commit. Upstream have now 
pulled in a commit to properly fix the underlying issue. Once we merge that 
fix, we should be able to reapply the reverted commit.

  [Test Case]
  If the kernel boots and we can still load the sha{1,2}_ce modules, we should 
be good.

  [Fix]
  After this is applied:
https://www.spinics.net/lists/stable/msg431217.html
  We should reapply the commit we reverted here:

https://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=4baa2fdd354700e2304e10cdbc64402621c3fa29

  
  [Where Problems May Occur]
  Although we shipped the reverted patch for many releases - the whole time we 
did so, the impacted modules were not loadable. Once we reapply it, xenial 
users will be running that code for the first time. If there are issues with 
the code, users of the sha{1,2}_ce modules may now hit them. Issues could 
include kernel oopses, corruption, etc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907489/+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 1905336] Re: sha1_ce and sha2_ce modules no longer load

[dann frazier]

Reported upstream:
  https://www.spinics.net/lists/stable/msg429412.html

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

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

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

** Summary changed:

- sha1_ce and sha2_ce modules no longer load
+ sha1_ce and sha2_ce modules no longer load on arm64

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

Title:
  sha1_ce and sha2_ce modules no longer load on arm64

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Confirmed

Bug description:
  [Impact]
  The sha{1,2}_ce modules no longer load on arm64, preventing the use of the 
hardware accelerated ARMv8 crypto extensions for SHA1, SHA-224/SHA-256.

  [Test Case]
  sudo modprobe sha1_ce
  Currently fails:
  [   33.838295] module sha1_ce: unsupported RELA relocation: 275

  [Fix]

  [Where problems could occur]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1905336/+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 1899993] Re: EFI: Fails when BootCurrent entry does not exist

[dann frazier]

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

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

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => dann frazier (dannf)

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Groovy)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: curtin (Ubuntu Groovy)
   Status: New => Invalid

** Changed in: curtin (Ubuntu Focal)
   Status: New => Invalid

** Changed in: curtin (Ubuntu Bionic)
   Status: New => Invalid

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

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

** Changed in: linux (Ubuntu Bionic)
     Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Hirsute)
   Status: Triaged => In Progress

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

Title:
  EFI: Fails when BootCurrent entry does not exist

Status in curtin package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in curtin source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  In Progress
Status in curtin source package in Bionic:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in curtin source package in Focal:
  Invalid
Status in linux source package in Focal:
  In Progress
Status in curtin source package in Groovy:
  Invalid
Status in linux source package in Groovy:
  In Progress
Status in curtin source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  In Progress

Bug description:
  Split out of bug 1894217.

  We're seeing a situation where curtin fails when the variable
  BootCurrent references does not exist.

  At boot, efibootmgr -v shows:

  BootCurrent: 0003
  Timeout: 10 seconds
  BootOrder: 0003,0004,0005,0006,0001

  Note that there are actually no individual boot entries in this
  output. BootCurrent and BootOrder are referencing Boot entries that do
  not apepar to exist.

  Later, curtin tries to set a new BootOrder that places the value of
  BootCurrent at the front. This causes efibootmgr to error out,
  apparently escalating to an installation failure:

  UEFI efibootmgr output after install:
  {'current': '0003', 'timeout': '10 seconds', 'order': [''], 
'entries': {'': {'name
  ': 'ubuntu', 'path': 
'HD(1,GPT,0937ffdf-628c-4161-8b2f-5920235669c6,0x800,0x10)/File(\\EFI\\ub
  untu\\shimx64.efi)'}}}
  Setting currently booted 0003 as the first UEFI loader.
  New UEFI boot order: 0003,
  Running command ['mount', '--bind', '/dev', 
'/tmp/tmp6ha4_iz2/target/dev'] with allowed re
  turn codes [0] (capture=False)
  Running command ['mount', '--bind', '/proc', 
'/tmp/tmp6ha4_iz2/target/proc'] with allowed 
  return codes [0] (capture=False)
  Running command ['mount', '--bind', '/run', 
'/tmp/tmp6ha4_iz2/target/run'] with allowed re
  turn codes [0] (capture=False)
  Running command ['mount', '--bind', '/sys', 
'/tmp/tmp6ha4_iz2/target/sys'] with allowed re
  turn codes [0] (capture=False)
  Running command ['mount', '--bind', '/sys/firmware/efi/efivars', 
'/tmp/tmp6ha4_iz2/target/
  sys/firmware/efi/efivars'] with allowed return codes [0] (capture=False)
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6ha4_iz2/target', 
  'efibootmgr', '-o', '0003,'] with allowed return codes [0] (capture=False)
  Invalid BootOrder order entry value0003
   ^
  efibootmgr: entry 0003 does not exist

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/183/+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 1899993] Re: EFI: Fails when BootCurrent entry does not exist

[dann frazier]

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

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

** Also affects: curtin (Ubuntu Groovy)
   Importance: Undecided
   Status: New

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

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

** Also affects: linux (Ubuntu Hirsute)
   Importance: Undecided
 Assignee: dann frazier (dannf)
   Status: Triaged

** Also affects: curtin (Ubuntu Hirsute)
   Importance: Medium
   Status: Invalid

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

** Also affects: curtin (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

Title:
  EFI: Fails when BootCurrent entry does not exist

Status in curtin package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in curtin source package in Xenial:
  New
Status in linux source package in Xenial:
  New
Status in curtin source package in Bionic:
  New
Status in linux source package in Bionic:
  New
Status in curtin source package in Focal:
  New
Status in linux source package in Focal:
  New
Status in curtin source package in Groovy:
  New
Status in linux source package in Groovy:
  New
Status in curtin source package in Hirsute:
  Invalid
Status in linux source package in Hirsute:
  Triaged

Bug description:
  Split out of bug 1894217.

  We're seeing a situation where curtin fails when the variable
  BootCurrent references does not exist.

  At boot, efibootmgr -v shows:

  BootCurrent: 0003
  Timeout: 10 seconds
  BootOrder: 0003,0004,0005,0006,0001

  Note that there are actually no individual boot entries in this
  output. BootCurrent and BootOrder are referencing Boot entries that do
  not apepar to exist.

  Later, curtin tries to set a new BootOrder that places the value of
  BootCurrent at the front. This causes efibootmgr to error out,
  apparently escalating to an installation failure:

  UEFI efibootmgr output after install:
  {'current': '0003', 'timeout': '10 seconds', 'order': [''], 
'entries': {'': {'name
  ': 'ubuntu', 'path': 
'HD(1,GPT,0937ffdf-628c-4161-8b2f-5920235669c6,0x800,0x10)/File(\\EFI\\ub
  untu\\shimx64.efi)'}}}
  Setting currently booted 0003 as the first UEFI loader.
  New UEFI boot order: 0003,
  Running command ['mount', '--bind', '/dev', 
'/tmp/tmp6ha4_iz2/target/dev'] with allowed re
  turn codes [0] (capture=False)
  Running command ['mount', '--bind', '/proc', 
'/tmp/tmp6ha4_iz2/target/proc'] with allowed 
  return codes [0] (capture=False)
  Running command ['mount', '--bind', '/run', 
'/tmp/tmp6ha4_iz2/target/run'] with allowed re
  turn codes [0] (capture=False)
  Running command ['mount', '--bind', '/sys', 
'/tmp/tmp6ha4_iz2/target/sys'] with allowed re
  turn codes [0] (capture=False)
  Running command ['mount', '--bind', '/sys/firmware/efi/efivars', 
'/tmp/tmp6ha4_iz2/target/
  sys/firmware/efi/efivars'] with allowed return codes [0] (capture=False)
  Running command ['unshare', '--fork', '--pid', '--', 'chroot', 
'/tmp/tmp6ha4_iz2/target', 
  'efibootmgr', '-o', '0003,'] with allowed return codes [0] (capture=False)
  Invalid BootOrder order entry value0003
   ^
  efibootmgr: entry 0003 does not exist

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/183/+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 1861039] Re: debian-distro-info --stable still reports stretch

[dann frazier]

** Also affects: distro-info-data (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: distro-info-data (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: distro-info-data (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: distro-info-data (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: distro-info-data (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: distro-info-data (Ubuntu Precise)
   Importance: Undecided
   Status: New

** Also affects: distro-info-data (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: distro-info-data (Ubuntu Focal)
   Status: New => Fix Released

** Changed in: distro-info-data (Ubuntu Disco)
   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/1861039

Title:
  debian-distro-info --stable still reports stretch

Status in distro-info-data package in Ubuntu:
  Fix Released
Status in distro-info-data source package in Precise:
  New
Status in distro-info-data source package in Trusty:
  New
Status in distro-info-data source package in Xenial:
  New
Status in distro-info-data source package in Bionic:
  New
Status in distro-info-data source package in Disco:
  Won't Fix
Status in distro-info-data source package in Eoan:
  New
Status in distro-info-data source package in Focal:
  Fix Released

Bug description:
  [Impact]
  The debian-distro-info command reports out of date information. I noticed 
this when debugging a  vagrant-mutate autopkgtest failure (which ended up being 
unrelated).

  [Test Case]
  $ debian-distro-info --stable
  stretch

  After update:
  $ debian-distro-info --stable
  buster

  [Regression Risk]
  There maybe some fallout where scripts that are not compatible with buster 
begin to fail once they begin picking up buster as stable instead of stretch.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/distro-info-data/+bug/1861039/+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 1858615] Re: dmidecode triggers system reboot on Inforce 6640

[dann frazier]

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

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

** Changed in: dmidecode (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  dmidecode triggers system reboot on Inforce 6640

Status in cloud-init:
  Invalid
Status in dmidecode package in Ubuntu:
  Fix Released
Status in dmidecode source package in Xenial:
  In Progress
Status in dmidecode source package in Bionic:
  In Progress
Status in dmidecode source package in Eoan:
  In Progress
Status in dmidecode source package in Focal:
  Fix Released
Status in dmidecode package in Debian:
  Unknown

Bug description:
  [Impact]
  Running 'sudo dmidecode' on non-UEFI ARM systems can cause them to 
crash/reboot. cloud-init apparently runs dmidecode as root, so it breaks any 
cloud-init based installation.

  [Test Case]
  sudo dmidecode

  [Fix]
  Upstream has the following fix:

  commit e12ec26e19e02281d3e7258c3aabb88a5cf5ec1d
  Author: Jean Delvare 
  Date: Mon Aug 26 14:20:15 2019 +0200

  dmidecode: Only scan /dev/mem for entry point on x86

  [Regression Risk]
  In Ubuntu, dmidecode only builds on amd64, arm64, armhf & i386.
  The fix is to disable code on !x86, so the regression risk is restricted to 
ARM platforms, where we know /dev/mem trolling is bad news.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1858615/+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 1850540] Re: multi-zone raid0 corruption

[dann frazier]

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

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

** Also affects: ubuntu-release-notes
   Importance: Undecided
   Status: New

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

Title:
  multi-zone raid0 corruption

Status in Release Notes for Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed
Status in linux source package in Precise:
  New
Status in mdadm source package in Precise:
  New
Status in linux source package in Trusty:
  Confirmed
Status in mdadm source package in Trusty:
  Confirmed
Status in linux source package in Xenial:
  Confirmed
Status in mdadm source package in Xenial:
  Confirmed
Status in linux source package in Bionic:
  Confirmed
Status in mdadm source package in Bionic:
  Confirmed
Status in linux source package in Disco:
  Confirmed
Status in mdadm source package in Disco:
  Confirmed
Status in linux source package in Eoan:
  Confirmed
Status in mdadm source package in Eoan:
  Confirmed
Status in linux source package in Focal:
  Confirmed
Status in mdadm source package in Focal:
  Confirmed
Status in mdadm package in Debian:
  Unknown

Bug description:
  Bug 1849682 tracks the temporarily revert of the fix for this issue,
  while this bug tracks the re-application of that fix once we have a
  full solution.

  Fix checklist:
  [ ] Restore c84a1372df929 md/raid0: avoid RAID0 data corruption due to layout 
confusion.
  [ ] Also apply these fixes:
  33f2c35a54dfd md: add feature flag MD_FEATURE_RAID0_LAYOUT
  3874d73e06c9b md/raid0: fix warning message for parameter default_layout
  [ ] If upstream, include https://marc.info/?l=linux-raid=157239231220119=2
  [ ] mdadm update (see Comment #2)
  [ ] Packaging work to detect/aide admin before reboot

  Users of RAID0 arrays are susceptible to a corruption issue if:
   - The members of the RAID array are not all the same size[*]
   - Data has been written to the array while running kernels < 3.14 *and* >= 
3.14.

  This is because of an change in v3.14 that accidentally changed how data was 
written - as described in the upstream commit message:
  
https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9

  That change has been applied to stable, but we reverted it to fix
  1849682 until we have a full solution ready.

  To summarize, upstream is dealing with this by adding a versioned
  layout in v5.4, and that is being backported to stable kernels - which
  is why we're now seeing it. Layout version 1 is the pre-3.14 layout,
  version 2 is post 3.14. Mixing version 1 & version 2 layouts can cause
  corruption. However, until an mdadm exists that is able to set a
  layout in the array, there's no way for the kernel to know which
  version(s) was used to write the existing data. This undefined mode is
  considered "Version 0", and the kernel will now refuse to start these
  arrays w/o user intervention.

  The user experience is pretty awful here. A user upgrades to the next
  SRU and all of a sudden their system stops at an (initramfs) prompt. A
  clueful user can spot something like the following in dmesg:

  Here's the message which , as you can see from the log in Comment #1,
  is hidden in a ton of other messages:

  [ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with 
default_layout setting
  [ 72.728149] md/raid0: please set raid.default_layout to 1 or 2
  [ 72.733979] md: pers->run() failed ...
  mdadm: failed to start array /dev/md0: Unknown error 524

  What that is trying to say is that you should determine if your data -
  specifically the data toward the end of your array - was most likely
  written with a pre-3.14 or post-3.14 kernel. Based on that, reboot
  with the kernel parameter raid0.default_layout=1 or
  raid0.default_layout=2 on the kernel command line. And note it should
  be *raid0.default_layout* not *raid.default_layout* as the message
  says - a fix for that message is now queued for stable:

  
https://github.com/torvalds/linux/commit/3874d73e06c9b9dc15de0b7382fc223986d75571)

  IMHO, we should work with upstream to create a web page that clearly
  walks the user through this process, and update the error message to
  point to that page. I'd also like to see if we can detect this problem
  *before* the user reboots (debconf?) and help the user fix things.
  e.g. "We detected that you have RAID0 arrays that maybe susceptible to
  a corruption problem", guide the user to choosing a layout, and update
  the mdadm initramfs hook to poke the answer in via sysfs before
  starting the array on reboot.

  Note that it also seems like we should 

[Group.of.nepali.translators] [Bug 1851542] Re: autopkgtest fails due to aspell SRU

[dann frazier]

** No longer affects: apport (Ubuntu Xenial)

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

Title:
  autopkgtest fails due to aspell SRU

Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Bionic:
  Fix Committed
Status in apport source package in Disco:
  Fix Committed
Status in apport source package in Eoan:
  Fix Committed
Status in apport source package in Focal:
  Fix Released

Bug description:
  [Impact]
  A new autopkgtest test regression began appearing after (and due to) an 
aspell SRU.

  ==
  FAIL: test_install_packages_versioned (__main__.T)
  install_packages() with versions and with cache
  --
  Traceback (most recent call last):
File "./test_backend_apt_dpkg.py", line 557, in 
test_install_packages_versioned
  self.assertIn(result, 'aspell-doc version 1.1 required, but 
0.60.7~20110707-3build1 is available\n')
  AssertionError: 'aspell-doc version 1.1 required, but 
0.60.7~20110707-3ubuntu0.1 is available\n' not found in 'aspell-doc version 1.1 
required, but 0.60.7~20110707-3build1 is available\n'

  --
  Ran 37 tests in 191.123s

  FAILED (failures=1)

  [Test Case]
  ## From within autopkgtest source package, with autopkgtest deps installed
  ## This is a slightly modified version if debian/tests/upstream-system

  # do not run in the source tree, as we want to check the system-installed
  # apport
  TESTDIR=${ADTTMP:-/tmp}/apport-tests
  mkdir -p $TESTDIR
  cp test/test_* test/run "$TESTDIR"
  cd "$TESTDIR"

  # clean up old crash reports
  rm -rf /var/crash/*

  export GNUPGHOME=$TESTDIR/gnupg
  mkdir -m 700 $GNUPGHOME

  ./run backend_apt_dpkg

  [Fix]
  
http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/focal/apport/ubuntu/revision/2717

  [Regression Risk]
  Code is restricted to a test that is only ran via autopkgtest.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1851542/+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 1850540] [NEW] multi-zone raid0 corruption

[dann frazier]

Public bug reported:

Bug 1849682 tracks the temporarily revert of the fix for this issue,
while this bug tracks the re-application of that fix once we have a full
solution.

Users of RAID0 arrays are susceptible to a corruption issue if:
 - The members of the RAID array are not all the same size[*]
 - Data has been written to the array while running kernels < 3.14 *and* >= 
3.14.

This is because of an change in v3.14 that accidentally changed how data was 
written - as described in the upstream commit message:
https://github.com/torvalds/linux/commit/c84a1372df929033cb1a0441fb57bd3932f39ac9

That change has been applied to stable, but we reverted it to fix
1849682 until we have a full solution ready.

To summarize, upstream is dealing with this by adding a versioned layout
in v5.4, and that is being backported to stable kernels - which is why
we're now seeing it. Layout version 1 is the pre-3.14 layout, version 2
is post 3.14. Mixing version 1 & version 2 layouts can cause corruption.
However, unless a layout-version-aware kernel *created* the array,
there's no way for the kernel to know which version(s) was used to write
the existing data. This undefined mode is considered "Version 0", and
the kernel will now refuse to start these arrays w/o user intervention.

The user experience is pretty awful here. A user upgrades to the next
SRU and all of a sudden their system stops at an (initramfs) prompt. A
clueful user can spot something like the following in dmesg:

Here's the message which , as you can see from the log in Comment #1, is
hidden in a ton of other messages:

[ 72.720232] md/raid0:md0: cannot assemble multi-zone RAID0 with default_layout 
setting
[ 72.728149] md/raid0: please set raid.default_layout to 1 or 2
[ 72.733979] md: pers->run() failed ...
mdadm: failed to start array /dev/md0: Unknown error 524

What that is trying to say is that you should determine if your data -
specifically the data toward the end of your array - was most likely
written with a pre-3.14 or post-3.14 kernel. Based on that, reboot with
the kernel parameter raid0.default_layout=1 or raid0.default_layout=2 on
the kernel command line. And note it should be *raid0.default_layout*
not *raid.default_layout* as the message says - a fix for that message
is now queued for stable:

https://github.com/torvalds/linux/commit/3874d73e06c9b9dc15de0b7382fc223986d75571)

IMHO, we should work with upstream to create a web page that clearly
walks the user through this process, and update the error message to
point to that page. I'd also like to see if we can detect this problem
*before* the user reboots (debconf?) and help the user fix things. e.g.
"We detected that you have RAID0 arrays that maybe susceptible to a
corruption problem", guide the user to choosing a layout, and update the
mdadm initramfs hook to poke the answer in via sysfs before starting the
array on reboot.

Note that it also seems like we should investigate backporting this to <
3.14 kernels. Imagine a user switching between the trusty HWE kernel and
the GA kernel.

References from users of other distros:
https://blog.icod.de/2019/10/10/caution-kernel-5-3-4-and-raid0-default_layout/
https://www.linuxquestions.org/questions/linux-general-1/raid-arrays-not-assembling-4175662774/

[*] Which surprisingly is not the case reported in this bug - the user
here had a raid0 of 8 identically-sized devices. I suspect there's a bug
in the detection code somewhere.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Precise)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Precise)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Trusty)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Trusty)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Bionic)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Disco)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Disco)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Eoan)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Eoan)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Focal)
 Importance: Undecided
 Status: New

** Affects: mdadm (Ubuntu Focal)
 Importance: Undecided
 Status: New

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

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

** Also affects: linux (Ubuntu Eoan)
   Importance: Undecided
   

[Group.of.nepali.translators] [Bug 1842284] Re: initramfs does not copy ehci-platform

[dann frazier]

** Changed in: initramfs-tools (Ubuntu Eoan)
   Status: In Progress => Fix Released

** Changed in: initramfs-tools (Ubuntu Disco)
   Status: New => Fix Released

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: New => Fix Released

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

Title:
  initramfs does not copy ehci-platform

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in initramfs-tools source package in Disco:
  Fix Released
Status in initramfs-tools source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  If you install Ubuntu onto USB storage behind a Platform USB host controller, 
it will not be able to boot because the generated initramfs will not include 
the host controller driver.

  [Test Case]
  Install to a USB stick attached to platform USB controller and reboot. 
Booting will fail because it will be unable to find the root file system.

  [Regression Risk]
  Driver is only loaded when system requires ehci-platform, minimizing the 
impact to all other systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1842284/+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 1842284] Re: initramfs does not copy ehci-platform

[dann frazier]

** Also affects: initramfs-tools (Ubuntu Eoan)
   Importance: Undecided
   Status: In Progress

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Disco)
   Importance: Undecided
   Status: New

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

Title:
  initramfs does not copy ehci-platform

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in initramfs-tools source package in Disco:
  New
Status in initramfs-tools source package in Eoan:
  In Progress

Bug description:
  [Impact]
  If you install Ubuntu onto USB storage behind a Platform USB host controller, 
it will not be able to boot because the generated initramfs will not include 
the host controller driver.

  [Test Case]
  Install to a USB stick attached to platform USB controller and reboot. 
Booting will fail because it will be unable to find the root file system.

  [Regression Risk]
  Driver is only loaded when system requires ehci-platform, minimizing the 
impact to all other systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1842284/+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 1824016] Re: Built-Using incorrect

[dann frazier]

** Changed in: linux-signed-hwe (Ubuntu Cosmic)
   Status: New => Invalid

** Changed in: linux-signed-hwe (Ubuntu Disco)
   Status: New => Invalid

** Changed in: linux-signed-hwe-edge (Ubuntu Disco)
   Status: New => Invalid

** Changed in: linux-signed-hwe-edge (Ubuntu Cosmic)
   Status: New => Invalid

** Changed in: linux-signed (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux-signed (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux-signed (Ubuntu Bionic)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed (Ubuntu Cosmic)
   Status: New => In Progress

** Changed in: linux-signed (Ubuntu Cosmic)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed (Ubuntu Disco)
   Status: New => In Progress

** Changed in: linux-signed (Ubuntu Disco)
     Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed-hwe (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux-signed-hwe (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed-hwe (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux-signed-hwe (Ubuntu Bionic)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed-hwe-edge (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux-signed-hwe-edge (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-signed-hwe-edge (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: linux-signed-hwe-edge (Ubuntu Bionic)
 Assignee: (unassigned) => dann frazier (dannf)

** Description changed:

  [Impact]
  The Build-Using control file field is incorrect for linux-signed-hwe & 
linux-signed-hwe-edge. They claim they were built against the "linux" package, 
but should be linux-hwe/linux-hwe-edge respectively.
  
  [Test Case]
  Look at the Packages file.
  
  [Fix]
  Detect and insert the correct package name at build time.
  
  [Regression Risk]
+ Hm.. maybe if something gets added using the PACKAGE keyword in control.stub 
that isn't intended to be replaced gets accidentally replaced, screwing up some 
other control field?

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

Title:
  Built-Using incorrect

Status in linux-signed package in Ubuntu:
  In Progress
Status in linux-signed-hwe package in Ubuntu:
  Invalid
Status in linux-signed-hwe-edge package in Ubuntu:
  Invalid
Status in linux-signed source package in Xenial:
  In Progress
Status in linux-signed-hwe source package in Xenial:
  In Progress
Status in linux-signed-hwe-edge source package in Xenial:
  In Progress
Status in linux-signed source package in Bionic:
  In Progress
Status in linux-signed-hwe source package in Bionic:
  In Progress
Status in linux-signed-hwe-edge source package in Bionic:
  In Progress
Status in linux-signed source package in Cosmic:
  In Progress
Status in linux-signed-hwe source package in Cosmic:
  Invalid
Status in linux-signed-hwe-edge source package in Cosmic:
  Invalid
Status in linux-signed source package in Disco:
  In Progress
Status in linux-signed-hwe source package in Disco:
  Invalid
Status in linux-signed-hwe-edge source package in Disco:
  Invalid

Bug description:
  [Impact]
  The Build-Using control file field is incorrect for linux-signed-hwe & 
linux-signed-hwe-edge. They claim they were built against the "linux" package, 
but should be linux-hwe/linux-hwe-edge respectively.

  [Test Case]
  Look at the Packages file.

  [Fix]
  Detect and insert the correct package name at build time.

  [Regression Risk]
  Hm.. maybe if something gets added using the PACKAGE keyword in control.stub 
that isn't intended to be replaced gets accidentally replaced, screwing up some 
other control field?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1824016/+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 1821408] Re: scsi: libsas: Support SATA PHY connection rate unmatch fixing during discovery

[dann frazier]

** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Won't Fix

** Changed in: linux (Ubuntu Cosmic)
   Status: In Progress => Won't Fix

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

** Description changed:

  [Impact]
  SATA disks may be unusable
  will not be usable when:
   - The disk is connected through a SAS expander
   - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas)
   - link rate between expander & disk is greater than link between controller 
and expander
  
+ This is unlikely to occur in any production environment, but has
+ occurred in early silicon testing. Fixing this would be helpful in those
+ environments.
+ 
  [Test Case]
  See conditions in "Impact"
  
  Can be simulated with:
  for f in  /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do
-   echo "3.0 Gbit" | sudo tee $f
+   echo "3.0 Gbit" | sudo tee $f
  done
  
  [Fix]
  cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing 
during discovery
  
  [Regression Risk]
  Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas.
  Code change is all within an "if" statement that meets these restrictions.
  A bug in this code could possibly reduce the speed of an otherwise working 
disk connection.

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

Title:
  scsi: libsas: Support SATA PHY connection rate unmatch fixing during
  discovery

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  Won't Fix
Status in linux source package in Cosmic:
  Won't Fix
Status in linux source package in Disco:
  In Progress

Bug description:
  [Impact]
  SATA disks may be unusable
  will not be usable when:
   - The disk is connected through a SAS expander
   - Controller uses a libsas-based driver (mvsas, aic94xx, hisi_sas)
   - link rate between expander & disk is greater than link between controller 
and expander

  This is unlikely to occur in any production environment, but has
  occurred in early silicon testing. Fixing this would be helpful in
  those environments.

  [Test Case]
  See conditions in "Impact"

  Can be simulated with:
  for f in  /sys/class/sas_phy/phy-1\:*/maximum_linkrate; do
    echo "3.0 Gbit" | sudo tee $f
  done

  [Fix]
  cec9771d2e954 scsi: libsas: Support SATA PHY connection rate unmatch fixing 
during discovery

  [Regression Risk]
  Impact is restricted to drivers that use libsas: mvsas, aic94xx & hisi_sas.
  Code change is all within an "if" statement that meets these restrictions.
  A bug in this code could possibly reduce the speed of an otherwise working 
disk connection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1821408/+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 1820764] Re: CVE-2018-12178 CVE-2018-12180 CVE-2018-12181

[dann frazier]

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

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

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

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

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

** Also affects: edk2 (Ubuntu Disco)
   Importance: Undecided
   Status: Fix Released

** Also affects: edk2 (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

Title:
  CVE-2018-12178 CVE-2018-12180 CVE-2018-12181

Status in edk2 package in Ubuntu:
  Fix Released
Status in edk2 source package in Precise:
  New
Status in edk2 source package in Trusty:
  New
Status in edk2 source package in Xenial:
  New
Status in edk2 source package in Bionic:
  New
Status in edk2 source package in Cosmic:
  New
Status in edk2 source package in Disco:
  Fix Released
Status in edk2 package in Debian:
  Unknown

Bug description:
  [Impact]
  Security vulnerabilities.

  [Test Case]

  [Fix]

  [Regression Risk]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1820764/+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 1784926] Re: ipmi-locate fails to detect BMCs described by ACPI

[dann frazier]

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

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

** Changed in: freeipmi (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

Title:
  ipmi-locate fails to detect BMCs described by ACPI

Status in freeipmi package in Ubuntu:
  Fix Released
Status in freeipmi source package in Xenial:
  In Progress
Status in freeipmi source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  ipmi-locate will not detect and report BMCs in systems where the firmware 
describes them only in an ACPI SPMI table. I surveyed several IPMI-capable 
systems, and all but 1 describe their BMCs in SMBIOS, with a subset of those 
also describing their BMC in ACPI as well. ipmi-locate works fine on those 
systems because it successfully parses the SMBIOS (dmidecode) info. But, one 
system - the HiSilicon D06 - only describes the BMC in ACPI. For this system, 
ipmi-locate fails to find a BMC.

  One way this surfaces to the user is with MAAS. MAAS uses ipmi-locate
  to look for a BMC to determine which version of the IPMI protocol it
  supports. The way the query works is that it checks for >= 2.0 support
  and, if that fails, it assumes 1.5 support. Since ipmi-locate fails to
  find *any* support, the fallback to 1.5 is triggered and MAAS tries to
  talk to the system w/ IPMI LAN 1.5 protocol. This system actually
  supports IPMI LAN 2.0 protocol, which is incompatible with 1.5 LAN
  protocol, so MAAS is unable to power control the system. Even if you
  manually enlist the node and tell it the node is IPMI 2.0,
  commissioning will attempt to re-detect the BMC and reset it to 1.5.

  [Test Case]
  On a system where /sys/firmware/acpi/tables/SPMI* exists:
  $ sudo ipmi-locate

  At least one of the "[Probing KCS|SMIC|BT|SSIF] device using ACPI"
  tests should not report "FAILED".

  [Fix]
  The following patch series from upstream git fixes the problem:

  40ba578f8 Correct order of bytes in specification_revision field of ACPI SPMI 
table
  d92888128 Allow sysfs SPMI parsing on ARM platforms
  158a901d7 Add support for parsing SPMI tables exposed via sysfs
  184c74649 Split RSDT/XSDT parsing into new function
  3c6fa7054 Don't try to separate the header from the ACPI table data
  d8673cf67 Fix acpi spmi searching corner case

  [Regression Risk]
  While neither myself nor upstream are aware of a system where the existing 
freeipmi ACPI/SPMI parsing code works - and works *correctly* - it is possible 
that there is such a system. From my experimentation and reading of the code - 
even if the existing code to extract an SPMI table from /dev/mem were to work, 
the parsing of that table would be buggy and would not report correct 
information (see commits 3c6fa7054 and 40ba578f8 for details). However - an 
earlier version of this code did apparently work at some point on some system - 
so it's possible that my parsing fixes would now break said system. Note that 
for this to be an issue for the MAAS use-case, that system would also need to 
*not* also describe the IPMI device in SMBIOS, which my survey of 4 systems 
shows to be nearly always the case (except for the 1 case that triggered this 
whole thing).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1784926/+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 1797092] Re: xenial guest on arm64 drops to busybox under openstack bionic-rocky

[dann frazier]

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

** Changed in: linux-raspi2 (Ubuntu)
   Status: New => Fix Released

** Changed in: linux-raspi2 (Ubuntu Bionic)
   Status: New => Fix Released

** Changed in: linux-raspi2 (Ubuntu Cosmic)
   Status: New => Fix Released

** Changed in: linux-snapdragon (Ubuntu Cosmic)
   Status: New => Fix Released

** Changed in: linux-snapdragon (Ubuntu)
   Status: New => Fix Released

** Changed in: linux-snapdragon (Ubuntu Bionic)
   Status: New => Fix Released

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

Title:
  xenial guest on arm64 drops to busybox under openstack bionic-rocky

Status in linux package in Ubuntu:
  Fix Released
Status in linux-raspi2 package in Ubuntu:
  Fix Released
Status in linux-snapdragon package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux-raspi2 source package in Xenial:
  Fix Committed
Status in linux-snapdragon source package in Xenial:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released
Status in linux-raspi2 source package in Bionic:
  Fix Released
Status in linux-snapdragon source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released
Status in linux-raspi2 source package in Cosmic:
  Fix Released
Status in linux-snapdragon source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  on openstack rocky-bionic (with patch, see 1771662), xenial guests will fail 
to launch as they drop to the busybox prompt after booting. The reason is that 
the EFI firmware image switched to ACPI mode by default in bionic. We knew that 
was happening, and backported some minimal ACPI support to keep xenial guests 
booting (bug 1744754). But, now we're seeing guests panic when trying to 
initialize PCI.

  [Test Case]
  Deploy rocky-bionic OpenStack and try to launch a xenial guest.

  [Fix]
  Backport ACPI/PCIe support for arm64 from upstream.

  [ Regression Risk ]
  TLDR: Definitely warrants some regression testing on armhf/arm64, but 
regression risk seems low for other architectures. Here's a patch-by-patch risk 
analysis:

  > 0001-UBUNTU-Config-CONFIG_PCI_ECAM-y.patch
  Enables code that will be added in the next patch.

  > 0002-PCI-Provide-common-functions-for-ECAM-mapping.patch
  Only adds new code w/ no callers yet

  > 0003-PCI-generic-thunder-Use-generic-ECAM-API.patch
  As noted in the commit message:
  "The patch does not introduce any functional changes other than a very minor 
one: with the new code, on 64-bit platforms, we do just a single ioremap for 
the whole config space."

  > 0004-PCI-of-Move-PCI-I-O-space-management-to-PCI-core-cod.patch
  As noted, no functional change.

  > 0005-PCI-Move-ecam.h-to-linux-include-pci-ecam.h.patch
  As noted, no functional change.

  > 0006-PCI-Add-parent-device-field-to-ECAM-struct-pci_confi.patch
  This makes changes to the ecam code, but that was added in this series, so no 
regression risk there. The pci-thunder-pem changes will be regression tested on 
the hardware that uses that driver (Cavium ThunderX).

  > 0007-PCI-Add-pci_unmap_iospace-to-unmap-I-O-resources.patch
  Only adds new code, w/ no callers yet

  > 0008-PCI-ACPI-Support-I-O-resources-when-parsing-host-bri.patch
  Adds and calls a new function that is a no-op on !ARM (PCI_IOBASE is only 
defined on ARM). Also adds a call to pci_unmap_iospace(), which was added in a 
previous patch and is also a no-op on !ARM.

  > 0009-UBUNTU-Config-CONFIG_ACPI_MCFG-y.patch
  Enables code that will be added in the next patch.

  > 0010-PCI-ACPI-Add-generic-MCFG-table-handling.patch
  Adds parsing of a new ACPI table. A possible regression risk to platforms an 
MCFG table that were working fine w/ 4.4 and there's a latent bug in this 
parsing code.

  > 0011-PCI-Refactor-pci_bus_assign_domain_nr-for-CONFIG_PCI.patch
  As noted, no functional change intended.

  > 0012-PCI-Factor-DT-specific-pci_bus_find_domain_nr-code-o.patch
  Again, no functional change.

  > 0013-ARM64-PCI-Add-acpi_pci_bus_find_domain_nr.patch
  Only impacts ARM due to CONFIG_PCI_DOMAINS_GENERIC guard

  > 0014-ARM64-PCI-ACPI-support-for-legacy-IRQs-parsing-and-c.patch
  arm64-specific PCI initialization code - mitigate risk by regression testing 
on supported platforms (X-Gene, ThunderX).

  > 0015-ARM64-PCI-Support-ACPI-based-PCI-host-controller.patch
  Adds new code for arm64-ACPI support. We didn't previously support these 
devices, so regression risk is negligible.

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

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

[Group.of.nepali.translators] [Bug 1797092] Re: xenial guest on arm64 drops to busybux under openstack bionic-rocky

[dann frazier]

@ppisati: Would you be able to regression test this on armhf?

** Description changed:

- on openstack rocky-bionic (with patch, see 1771662), xenial guests will
- fail to launch as they drop to the busybox prompt after booting.
- However, bionic guests will build and launch successfully.
+ [Impact]
+ on openstack rocky-bionic (with patch, see 1771662), xenial guests will fail 
to launch as they drop to the busybox prompt after booting.
  
- Dann F believes this may be related to the xenial image not containing
- appropriate acpi modifications.
+ [Test Case]
+ Deploy rocky-bionic OpenStack and try to launch a xenial guest.
  
- xenial guest console log:
  
- https://pastebin.canonical.com/p/ntRxFJTvjV/
+ [Fix]
+ Backport ACPI/PCIe support for arm64 from upstream.
  
- xenial virshxml:
+ [ Regression Risk ]
+ TLDR: Definitely warrants some regression testing on armhf/arm64, but 
regression risk seems low for other architectures. Here's a patch-by-patch risk 
analysis:
  
- https://pastebin.canonical.com/p/cCY4ZVynP7/
+ > 0001-UBUNTU-Config-CONFIG_PCI_ECAM-y.patch
+ Enables code that will be added in the next patch.
  
- bionic virshxml for comparison:
+ > 0002-PCI-Provide-common-functions-for-ECAM-mapping.patch
+ Only adds new code w/ no callers yet
  
- https://pastebin.canonical.com/p/MSV3xG7t7g/
+ > 0003-PCI-generic-thunder-Use-generic-ECAM-API.patch
+ As noted in the commit message:
+ "The patch does not introduce any functional changes other than a very minor 
one: with the new code, on 64-bit platforms, we do just a single ioremap for 
the whole config space."
  
- validation:
+ > 0004-PCI-of-Move-PCI-I-O-space-management-to-PCI-core-cod.patch
+ As noted, no functional change.
  
- https://pastebin.canonical.com/p/nC9pfSkXVs/
+ > 0005-PCI-Move-ecam.h-to-linux-include-pci-ecam.h.patch
+ As noted, no functional change.
+ 
+ > 0006-PCI-Add-parent-device-field-to-ECAM-struct-pci_confi.patch
+ This makes changes to the ecam code, but that was added in this series, so no 
regression risk there. The pci-thunder-pem changes will be regression tested on 
the hardware that uses that driver (Cavium ThunderX).
+ 
+ > 0007-PCI-Add-pci_unmap_iospace-to-unmap-I-O-resources.patch
+ Only adds new code, w/ no callers yet
+ 
+ > 0008-PCI-ACPI-Support-I-O-resources-when-parsing-host-bri.patch
+ Adds and calls a new function that is a no-op on !ARM (PCI_IOBASE is only 
defined on ARM). Also adds a call to pci_unmap_iospace(), which was added in a 
previous patch and is also a no-op on !ARM.
+ 
+ > 0009-UBUNTU-Config-CONFIG_ACPI_MCFG-y.patch
+ Enables code that will be added in the next patch.
+ 
+ > 0010-PCI-ACPI-Add-generic-MCFG-table-handling.patch
+ Adds parsing of a new ACPI table. A possible regression risk to platforms an 
MCFG table that were working fine w/ 4.4 and there's a latent bug in this 
parsing code.
+ 
+ > 0011-PCI-Refactor-pci_bus_assign_domain_nr-for-CONFIG_PCI.patch
+ As noted, no functional change intended.
+ 
+ > 0012-PCI-Factor-DT-specific-pci_bus_find_domain_nr-code-o.patch
+ Again, no functional change.
+ 
+ > 0013-ARM64-PCI-Add-acpi_pci_bus_find_domain_nr.patch
+ Only impacts ARM due to CONFIG_PCI_DOMAINS_GENERIC guard
+ 
+ > 0014-ARM64-PCI-ACPI-support-for-legacy-IRQs-parsing-and-c.patch
+ arm64-specific PCI initialization code - mitigate risk by regression testing 
on supported platforms (X-Gene, ThunderX).
+ 
+ > 0015-ARM64-PCI-Support-ACPI-based-PCI-host-controller.patch
+ Adds new code for arm64-ACPI support. We didn't previously support these 
devices, so regression risk is negligible.

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

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

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

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

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

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

Title:
  xenial guest on arm64 drops to busybux under openstack bionic-rocky

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Triaged
Status in linux source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  on openstack rocky-bionic (with patch, see 1771662), xenial guests will fail 
to launch as they drop to the busybox prompt after booting.

  [Test Case]
  Deploy rocky-bionic OpenStack and try to launch a xenial guest.

  
  [Fix]
  Backport ACPI/PCIe support for arm64 from upstream.

  [ Regression Risk ]
  TLDR: Definitely warrants some regression testing on armhf/arm64, but 
regression risk seems low for other architectures. Here's a patch-by-patch risk 
analysis:

  > 0001-UBUNTU-Config-CONFIG_PCI_ECAM-y.patch
  Enables code that will be added in the next patch.

  > 

[Group.of.nepali.translators] [Bug 1785739] Re: [Regression] APM Merlin boards fail to recover link after interface down/up

[dann frazier]

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

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

** Changed in: linux (Ubuntu Cosmic)
 Assignee: dann frazier (dannf) => (unassigned)

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

** Description changed:

  [Impact]
  On an APM Merlin (X-Gene2) board, the onboard 1G interface fails to 
re-establish link when the interface is brought down and back up. Juju + MAAS 
provider does this after every install (so to configure a bridge), making this 
config unusable.
  
  This was actually a regression introduced by the fix for LP: #1632739 in
  4.4.0-48.69.
  
  [Test Case]
  1) From a remote system, start a ping to the IP address of the Merlin board's 
eth0 interface.
  2) On the merlin board: sudo ifconfig eth0 down; sudo ifconfig eth0 up
  3) Ping should recover, but doesn't
  
  [Fix]
  commit 84a527a41f38a80353f185d05e41b021e1ff672b
  Author: Shaohui Xie 
  Date:   Tue May 10 17:42:26 2016 +0800
  
- net: phylib: fix interrupts re-enablement in phy_start
+ net: phylib: fix interrupts re-enablement in phy_start
  
  [Regression Risk]
+ The fix appears to be straightforward - don't enable interrupts on a phy that 
does not have a valid interrupt. Fixes are upstream, so any regressions should 
get upstream support for fixing.

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

Title:
  [Regression] APM Merlin boards fail to recover link after interface
  down/up

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  [Impact]
  On an APM Merlin (X-Gene2) board, the onboard 1G interface fails to 
re-establish link when the interface is brought down and back up. Juju + MAAS 
provider does this after every install (so to configure a bridge), making this 
config unusable.

  This was actually a regression introduced by the fix for LP: #1632739
  in 4.4.0-48.69.

  [Test Case]
  1) From a remote system, start a ping to the IP address of the Merlin board's 
eth0 interface.
  2) On the merlin board: sudo ifconfig eth0 down; sudo ifconfig eth0 up
  3) Ping should recover, but doesn't

  [Fix]
  commit 84a527a41f38a80353f185d05e41b021e1ff672b
  Author: Shaohui Xie 
  Date:   Tue May 10 17:42:26 2016 +0800

  net: phylib: fix interrupts re-enablement in phy_start

  [Regression Risk]
  The fix appears to be straightforward - don't enable interrupts on a phy that 
does not have a valid interrupt. Fixes are upstream, so any regressions should 
get upstream support for fixing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1785739/+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 1771283] Re: iperf2 long time run on 40Gb/s NIC crashes

[dann frazier]

Thanks Manoj & Bob - I'll take a look at sponsoring your upload. Do you
mind filing a bug in Debian as well, and linking that bug to this one
using "Also affects distribution/package"? That way we'll know when we
can drop our diff & resync w/ Debian.

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

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

** Also affects: iperf (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

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

Title:
  iperf2 long time run on 40Gb/s NIC crashes

Status in iperf package in Ubuntu:
  New
Status in iperf source package in Xenial:
  New
Status in iperf source package in Artful:
  New
Status in iperf source package in Bionic:
  New
Status in iperf source package in Cosmic:
  New

Bug description:
  ubuntu@recht:~$ iperf -c 192.168.121.2 -P10 -w 130k -t 3600
  
  Client connecting to 192.168.121.2, TCP port 5001
  TCP window size:  254 KByte (WARNING: requested  127 KByte)
  
  [ 10] local 192.168.121.3 port 40756 connected with 192.168.121.2 port 5001
  [ 12] local 192.168.121.3 port 40760 connected with 192.168.121.2 port 5001
  [ 11] local 192.168.121.3 port 40758 connected with 192.168.121.2 port 5001
  [  8] local 192.168.121.3 port 40754 connected with 192.168.121.2 port 5001
  [  9] local 192.168.121.3 port 40752 connected with 192.168.121.2 port 5001
  [  7] local 192.168.121.3 port 40750 connected with 192.168.121.2 port 5001
  [  6] local 192.168.121.3 port 40746 connected with 192.168.121.2 port 5001
  [  5] local 192.168.121.3 port 40748 connected with 192.168.121.2 port 5001
  [  3] local 192.168.121.3 port 40744 connected with 192.168.121.2 port 5001
  [  4] local 192.168.121.3 port 40742 connected with 192.168.121.2 port 5001
  Segmentation fault (core dumped)

  Will report more information with gdb attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iperf/+bug/1771283/+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 1695093] Re: arm64: "unsupported RELA relocation: 275" loading certain modules

[dann frazier]

** Changed in: linux (Ubuntu Zesty)
   Status: Fix Committed => Won't Fix

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

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

** Changed in: gcc-6 (Ubuntu Zesty)
   Status: Triaged => Won't Fix

** Changed in: gcc-5 (Ubuntu Zesty)
   Status: Triaged => Won't Fix

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

Title:
  arm64: "unsupported RELA relocation: 275" loading certain modules

Status in Linux:
  In Progress
Status in gcc-5 package in Ubuntu:
  Fix Released
Status in gcc-6 package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in gcc-5 source package in Xenial:
  Fix Released
Status in gcc-6 source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  Fix Released
Status in gcc-5 source package in Yakkety:
  Won't Fix
Status in gcc-6 source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in gcc-5 source package in Zesty:
  Won't Fix
Status in gcc-6 source package in Zesty:
  Won't Fix
Status in linux source package in Zesty:
  Won't Fix

Bug description:
  [Impact]
  Certain kernel modules are unloadable (libceph & scsi_debug) due to the 
compiler generating unsupported relocations.

  This symptom is similar to LP: #1533009 but, in that case it impacted
  all modules, and the fix for that appears to remain in place.

  [Test Case]

  With the hwe-z kernel:

  ubuntu@grotian:~$ sudo modprobe libceph
  modprobe: ERROR: could not insert 'libceph': Exec format error
  ubuntu@grotian:~$ dmesg
  [66988.470307] module libceph: unsupported RELA relocation: 275

  [Regression Risk]
  The scope of the fix is restricted to aarch64, so regressions should only 
impact the arm64 port of Ubuntu. Regressions could impact when literal loads 
are used - which may have performance impacts or possibly cause software to 
fail to build/run where it previously did. This is somewhat mitigated by the 
fact that this has been fixed in artful gcc-5/gcc-6 and used on our buildds for 
some time. Only "somewhat", because gcc-7 is now the default.

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

[dann frazier]

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

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

** Changed in: rasdaemon (Ubuntu Bionic)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: rasdaemon (Ubuntu)
 Assignee: (unassigned) => Manoj Iyer (manjo)

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

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

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

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

Status in rasdaemon package in Ubuntu:
  In Progress
Status in rasdaemon source package in Xenial:
  New
Status in rasdaemon source package in Artful:
  New
Status in rasdaemon source package in Bionic:
  In Progress
Status in rasdaemon package in Debian:
  Unknown

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 

[Group.of.nepali.translators] [Bug 1571017] Re: [arm64] libmozjs24 crashes w/ 48-bit VA

[dann frazier]

** Changed in: mozjs24 (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

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

** Changed in: mozjs (Ubuntu Yakkety)
   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/1571017

Title:
  [arm64] libmozjs24 crashes w/ 48-bit VA

Status in Spidermonkey Javascript engine:
  Fix Released
Status in mozjs package in Ubuntu:
  New
Status in mozjs24 package in Ubuntu:
  Fix Released
Status in mozjs source package in Xenial:
  Won't Fix
Status in mozjs24 source package in Xenial:
  In Progress
Status in mozjs source package in Yakkety:
  Won't Fix
Status in mozjs24 source package in Yakkety:
  Won't Fix
Status in mozjs package in Debian:
  Fix Released
Status in mozjs24 package in Debian:
  Fix Released

Bug description:
  [Impact]
  libmozjs24 does not support 48-bit virtual addresses on arm64. 48-bit virtual 
addresses are enabled in the Ubuntu 16.04 kernel (though not on the kernel used 
on the buildds). This causes applications to crash.

  [Test Case]
  = mozjs =
  $ sudo apt install couchdb-bin
  $ couchjs a.js 
  Segmentation fault

  = mozjs24 =
  $ cat a.js
  print("hello")
  $ js24 a.js
  Segmentation fault

  [Regression Risk]
  The fix for mozjs24 is ifdef'd to only apply to arm64. Since arm64 is 
currently segfaulting with a very simple program, there's very little chance of 
making things worse.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mozjs/+bug/1571017/+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 1741978] Re: Add support for ARM events

[dann frazier]

** Also affects: rasdaemon (Ubuntu Bionic)
   Importance: High
   Status: 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 Committed
Status in rasdaemon source package in Zesty:
  Won't Fix
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.

  [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 1763532] Re: set reasonable default cmdlines for arm64

[dann frazier]

** Changed in: kexec-tools (Ubuntu Artful)
   Status: New => Invalid

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

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

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

** Changed in: kexec-tools (Ubuntu)
   Status: New => Fix Released

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

** Changed in: kexec-tools (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: makedumpfile (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: makedumpfile (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  set reasonable default cmdlines for arm64

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in kexec-tools source package in Artful:
  Invalid
Status in makedumpfile source package in Artful:
  In Progress
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  [Impact]
  Crash dump support doesn't work by default on any known arm64 platform. Users 
have to figure out working incantations for the crashkernel= parameter and the 
parameters passed to the crash-dump kernel themselves and manual edit 2 
different config files.

  [Test Case]
  Using either a Centriq 2400 or a Cavium ThunderX CRB (these platforms are 
known to support crashdump), and with a kernel >= 4.13 (xenial-ga did not 
support crashdump):

  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  If you want to verify that the dump is usable, install the
  corresponding linux-image--dbgsym package and run:

  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.

  crash should successfully load, placing you at a "crash>" prompt. At that 
prompt, you can issue the 'bt' command to see a backtrace.
  Note: you need crash from zesty (7.1.8-1ubuntu1) or later.

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1763532/+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 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** Changed in: makedumpfile (Ubuntu Artful)
   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/1694859

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  Fix Released
Status in makedumpfile package in Debian:
  Fix Released

Bug description:
  Note: Updates are being staged at ppa:dannf/arm64-kdump.

  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  If you want to verify that the dump is usable, install the
  corresponding linux-image--dbgsym package and run:

  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.

  crash should successfully load, placing you at a "crash>" prompt. At that 
prompt, you can issue the 'bt' command to see a backtrace.
  Note: you need crash from zesty (7.1.8-1ubuntu1) or later.

  [Regression Risk]
  = Kernel =
  3 patches here touch code outside of arch/arm64/:

  memblock: add memblock_clear_nomap()
  This adds a new function with no callers, so regression risk is negligible.
  (A later patch adds a call to it under arch/arm64/).

  memblock: add memblock_cap_memory_range()
  This refactors some of the code in memblock_mem_limit_remove_map() into a new 
function. The only existing caller of memblock_mem_limit_remove_map() is under 
arch/arm64/, so the regression risk outside of arm64 is negligible.

  efi/libstub/arm*: Set default address and size cells values for an empty dtb
  Because this code is for EFI platforms that support device-tree, it is 
de-facto ARM-specific (as noted in the patch title).

  For arm64, we have mitigated the risk by explicit regression testing on 
several platforms:
   - Qualcomm QDF2400
   - Cavium ThunderX CRB1S
   - HP m400 (X-Gene)
   - HiSilicon D05 (Hi07)

  = kexec-tools =
  == zesty ==
  For zesty, 10 patches are required to add kdump support.

  0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
  This modifies a function used on armhf & x86. The description explains the 
change, and why it does not impact those archs:

  -
  The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
  be affected by this change because
  * arm
    The callback function only returns -1 or 0, and the return value of
    kexec_iomem_for_each_line() will never be used.
  * sh, x86
    The callback function may return (-1 for sh,) 0 or 1, but always returns
    1 once we have reached the maximum number of entries allowed.
    Even so the current kexec_iomem_for_each_line() counts them up.
    This change actually fixes this bug.
  -

  0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
  This generalizes a function that was duplicated by arm & x86 and makes it 
common so arm64 can use it.

  The remaining 8 of these only touch code in kexec/arch/arm64, so
  regression risk for other architectures is negligible.

  Finally, I have tested this update on both i386 and amd64 VMs. i386
  crashes do not currently work in zesty (filed LP: #1699874), and my
  test results show no change there. amd64 worked before, and continues
  to work with these changes.

  == yakkety ==
  Since yakkety is based on an older upstream, 6 additional patches are 
required:

  arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
  This is a cleanup patch, cherry-picked because it allows later patches to 
apply w/o backporting. ARM-specific.

  kexec-add-max_size-to-memory_ranges.patch:
  Adds a new element to struct, to be used by later commits.

  kexec-add-generic-helper-to-add-to-memoryq_regions.patch,
  kexec-add-mem_regions-sorting-implementation.patch,
  kexec-add-helper-to-exlude-a-region-from-a-set-of-me.patch,
  kexec-fix-mem_regions_sort.patch:
  These patches only add new functions, which will be 

[Group.of.nepali.translators] [Bug 1624569] Re: thunder: chip errata w/ multiple CQEs for a TSO packet

[dann frazier]

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

Title:
  thunder: chip errata w/ multiple CQEs for a TSO packet

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

Bug description:
  [Impact]
  With small segment sizes, it is possible for the driver to free an SKB before 
transmitting it, potentially resulting in a crash.

  [Test Case]
  The test case for this is to use a small MTU (200) and mount an NFS exported 
directory. Create several (~4) 1M files w/ dd, then copy them locally. However, 
I have not been able to trigger the crash myself.

  [Regression Risk]
  Fix is upstream, so regressions will have upstream support. Fix is limited to 
a driver that is only applicable to the Cavium Thunder-X SoC, so risk is 
negligible to other platforms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1624569/+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 1623627] Re: thunder: faulty TSO padding

[dann frazier]

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

Title:
  thunder: faulty TSO padding

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

Bug description:
  [Impact]
  Certain packet sizes will trigger spurious TCP retransmissions on Cavium 
Thunder-X systems when TSO is enabled (the default). This can result in excess 
traffic and additional latency.

  [Test Case]
  Connect 2 systems to a 10G switch:
   - 1 ThunderX node (the client)
   - 1 "other" node - doesn't have to be ThunderX (the server)
  On the server, run the "receiver" command from the attached tcptest tarball:
$ ./receiver
  Also on the server, run tcpdump to capture the traffic:
$ sudo tcpdump -i  -w tcpdump.out
  On the client, run the "sender" command from the tcptest tarball, with a 1461 
packet size:
$ ./sender  1461 1461
  Kill the tcpdump process, and open it in wireshark.

  On failure, you'll see several "[TCP Spurious Retransmission]" packets
  - on success you should see none.

  [Regression Risk]
  Fix is upstream, so regressions will have upstream support. Fix is limited to 
a driver that is only applicable to the Cavium Thunder-X SoC, so risk is 
negligible to other platforms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1623627/+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 1582181] Re: AArch64: slow cpuinfo due to redundant loop

[dann frazier]

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

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

** Also affects: lshw (Ubuntu Bionic)
   Importance: Undecided
 Assignee: Ike Panhc (ikepanhc)
   Status: In Progress

** Description changed:

- lshw on AArch64 hardware is painfully slow.
- This affects both lshw in current Ubuntu releases and vanilla upstream.
- 
- For a 48 core node, cpuinfo parsing added up to 30 seconds (8 lines
- per core in /proc/cpuinfo add up to 384 lines to parse).
- 
- For a 96 core node, parsing took up to 5 minutes (!).
- 
- I think the problem was introduced by [1], and can be summarized as:
- - CPU capabilities should be added only to the current CPU core,
-   and NOT to all previous CPU cores parsed.
- 
- My suggestion is dropping the loop in [1], thus calling the 
- and  only for currentcpu.
- 
- I put together a small patch (basically removing the for loop in question)
- at [2] (or see attachement), which should be applied on top of version
- "02.16-2ubuntu1.3" from Ubuntu Trusty 14.04.
- 
- After applying the patch at [2], parsing for the above system (48 cores)
- takes less than 1 second (instead of 30s), with the exact same results ...
- 
- [1]
- https://github.com/lyonel/lshw/commit/beb89de5a3c10449fe73f1c77b2486d868e5bc9a
- #diff-f4010714738fa4cdd5999499579da2b3R217
- 
- [2] http://paste.ubuntu.com/16456620/
- 
- # lsb_release -rd
- Description:Ubuntu 14.04.4 LTS
- Release:14.04
- 
- BR,
- Alex
- 
  [Impact]
  lshw takes too long time on parsing /proc/cpuinfo on aarch64 system
  It takes minutes on 96cores and almost 10min on 224cores system.
  
  [Test Case]
  `time sudo lshw` and it shall be less then 15sec
  
  [Regression Potential]
  This patch only modifies codes for aarch64. Lowest regression rick on other 
arch and has been tested on aarch64
  
  [Other Info]
  Patch has been merged into upstream branch.
  https://github.com/lyonel/lshw/commit/20cda77239e8604e798b87a0441e694edb0214d1

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

Title:
  AArch64: slow cpuinfo due to redundant loop

Status in lshw package in Ubuntu:
  In Progress
Status in lshw source package in Xenial:
  New
Status in lshw source package in Artful:
  New
Status in lshw source package in Bionic:
  In Progress

Bug description:
  [Impact]
  lshw takes too long time on parsing /proc/cpuinfo on aarch64 system
  It takes minutes on 96cores and almost 10min on 224cores system.

  [Test Case]
  `time sudo lshw` and it shall be less then 15sec

  [Regression Potential]
  This patch only modifies codes for aarch64. Lowest regression rick on other 
arch and has been tested on aarch64

  [Other Info]
  Patch has been merged into upstream branch.
  https://github.com/lyonel/lshw/commit/20cda77239e8604e798b87a0441e694edb0214d1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lshw/+bug/1582181/+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 1757481] Re: Only enable APM on disks that advertise it

[dann frazier]

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

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

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

Title:
  Only enable APM on disks that advertise it

Status in hdparm package in Ubuntu:
  Fix Released
Status in hdparm source package in Xenial:
  In Progress
Status in hdparm source package in Artful:
  In Progress
Status in hdparm source package in Bionic:
  Fix Released
Status in hdparm package in Debian:
  Unknown

Bug description:
  [Impact]
  hdparm can cause certain systems to occasionally fail to boot. hdparm tries 
to enable APM on every (non-USB/non-firewire) disk in the system without first 
checking if APM is supported. This *should*
  be OK, since hdparm fails gracefully in this case. However, sending APM 
commands to disks that don't support it can have side-effects. I received a 
report that this was causing bus resets on a Cavium Sabre system with the disk 
below that would sometimes escalate to a boot failure.

  [Test Case]
  Boot a system with a non-USB/non-firewire disk that does not support APM and 
verify that there are no kernel messages like:

  SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 53 40 fe 21 04
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   APM_level = not supported

  
  [Regression Risk]
  This change entered Debian and Ubuntu 1 month ago, and no regressions have 
been reported. One source of regressions might be that configuring APM on a 
disk that claims not to support it did have some positive side-effect that 
would no longer occur.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1757481/+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 1757481] [NEW] Only enable APM on disks that advertise it

[dann frazier]

Public bug reported:

[Impact]
hdparm can cause certain systems to occasionally fail to boot. hdparm tries to 
enable APM on every (non-USB/non-firewire) disk in the system without first 
checking if APM is supported. This *should*
be OK, since hdparm fails gracefully in this case. However, sending APM 
commands to disks that don't support it can have side-effects. I received a 
report that this was causing bus resets on a Cavium Sabre system with the disk 
below that would sometimes escalate to a boot failure.

[Test Case]
Boot a system with a non-USB/non-firewire disk that does not support APM and 
verify that there are no kernel messages like:

SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 53 40 fe 21 04
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 APM_level = not supported


[Regression Risk]
This change entered Debian and Ubuntu 1 month ago, and no regressions have been 
reported. One source of regressions might be that configuring APM on a disk 
that claims not to support it did have some positive side-effect that would no 
longer occur.

** Affects: hdparm (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: hdparm (Ubuntu Xenial)
 Importance: Undecided
 Assignee: dann frazier (dannf)
 Status: In Progress

** Affects: hdparm (Ubuntu Artful)
 Importance: Undecided
 Assignee: dann frazier (dannf)
 Status: In Progress

** Affects: hdparm (Ubuntu Bionic)
 Importance: Undecided
 Status: Fix Released

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

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

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

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

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

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

** Changed in: hdparm (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: hdparm (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  Only enable APM on disks that advertise it

Status in hdparm package in Ubuntu:
  Fix Released
Status in hdparm source package in Xenial:
  In Progress
Status in hdparm source package in Artful:
  In Progress
Status in hdparm source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  hdparm can cause certain systems to occasionally fail to boot. hdparm tries 
to enable APM on every (non-USB/non-firewire) disk in the system without first 
checking if APM is supported. This *should*
  be OK, since hdparm fails gracefully in this case. However, sending APM 
commands to disks that don't support it can have side-effects. I received a 
report that this was causing bus resets on a Cavium Sabre system with the disk 
below that would sometimes escalate to a boot failure.

  [Test Case]
  Boot a system with a non-USB/non-firewire disk that does not support APM and 
verify that there are no kernel messages like:

  SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 04 53 40 fe 21 04
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   APM_level = not supported

  
  [Regression Risk]
  This change entered Debian and Ubuntu 1 month ago, and no regressions have 
been reported. One source of regressions might be that configuring APM on a 
disk that claims not to support it did have some positive side-effect that 
would no longer occur.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1757481/+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 1590168] Re: workaround cavium thunderx silicon erratum 27704

[dann frazier]

This fix landed upstream in v4.11, so marking Fix Released.

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

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

Title:
  workaround cavium thunderx silicon erratum 27704

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix

Bug description:
  The arm-smmu driver doesn't allow 2 different devices (SMMU 0/1) to
  share a namespace. So if 2 devices are connected to same SMMU, it may
  lead to memory corruption.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1590168/+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 1744754] Re: qemu-efi-aarch64 in >= artful can't boot xenial cloud images

[dann frazier]

My backport for option #3 has been merged, so no need for a change in
the cloud images or edk2.

** Changed in: cloud-images
   Status: New => Invalid

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

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

Title:
  qemu-efi-aarch64 in >= artful can't boot xenial cloud images

Status in cloud-images:
  Invalid
Status in edk2 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in edk2 source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  After upgrading an Ubuntu/arm64 KVM host past xenial, your xenial-based 
guests will fail to boot.

  [Test Case]
  Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.

  [Regression Risk]
  I've tested booting a xenial cloud image in bionic (ACPI mode), and 
regression tested w/ xenial's qemu-efi (DTB mode). I've regression tested on a 
Cavium ThunderX CRB1S, Caviumt ThunderX CRB2S and an APM X-Gene 2 Merlin board.

  Patches 1-5 change only code in the GICv3 driver. The xenial GA kernel
  only supported 2 GICv3 systems - the 1 socket and 2 socket variants of
  the Cavium ThunderX CRB - and I've regression tested on those systems.

  Patch 6 only adds new macro definitions.

  Patch 7 is restricted to devicetree code, except for a change to
  earlycon.c:param_setup_earlycon(). In the case that 'earlycon' is
  passed on the cmdline (vs. earlycon=something), this function used to
  return 0 - but now it will return -ENODEV on non-devicetree systems,
  which is a subtle API change. However, according to kernel-
  parameters.txt (and the code itself), 'earlycon' by itself is only
  valid on devicetree systems. Just to be sure, I booted an x86 system
  up w/ 'earlycon' with and without this series, and observed no
  difference.

  Patch 8 adds the SPCR table parser, but no caller to it yet. It also
  modifies the same earlycon code as Patch 7 - here it avoids earlycon
  init in the case that the devicetree-specific 'earlycon' was passed.
  As mentioned in my analysis Patch 7, this codepath is only supported
  for devicetree systems, and has been regression tested on x86.

  Patch 9 turns on CONFIG_ACPI_SPCR_TABLE - however, this driver will
  only be built for arm64. TBH, I'm not 100% sure how Kconfig knows not
  to build this for other archs - but I checked the logs, and there's no
  spcr.o built on other archs. (Not that that should be a problem - they
  would just grow a bit of unused code).

  Patch 10 only touches arm64-specific code, adding the call to
  parse_spcr(), so risk is limited to arm64.

  Patch 11 adds a new match method to the ARM-specific pl011 console
  driver, so regression risk to other architectures is negligible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1744754/+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 1754076] Re: i2c-thunderx: erroneous error message "unhandled state: 0"

[dann frazier]

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

** Also affects: linux (Ubuntu Bionic)
   Importance: Undecided
   Status: Incomplete

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

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

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

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  i2c-thunderx: erroneous error message "unhandled state: 0"

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Artful:
  In Progress
Status in linux source package in Bionic:
  In Progress

Bug description:
  [Impact]
  A misleading error is occasionally emitted by the kernel.

  [Test Case]
  Boot a ThunderX system and watch for the error:

  i2c-thunderx :01:09.4: unhandled state: 0

  [Regression Risk]
  Driver is specific to a platform, and the only functional change is skipping 
the emission of an error message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1754076/+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 1743884] Re: installed GRUB menu does not appear on term used for install

[dann frazier]

The released fix for this introduced a regression (LP: #1752767), so I'm
reverting while we seek a better fix.

** Changed in: grub2 (Ubuntu Xenial)
   Status: In Progress => Confirmed

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

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

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

Title:
  installed GRUB menu does not appear on term used for install

Status in grub2 package in Ubuntu:
  Confirmed
Status in grub2 source package in Xenial:
  Confirmed
Status in grub2 source package in Artful:
  Confirmed
Status in grub2 source package in Bionic:
  Confirmed

Bug description:
  [Impact]
  I have a UEFI-based server with both a graphical head and a serial console 
(Cavium Sabre). If I boot the netboot (d-i) installer, the install menu appears 
on both, and I'm able to interact with the installer over both the serial 
console and the graphical head. However, when booting into the *installed* 
system (w/ HIDDEN_TIMEOUT disabled), the GRUB menu only appears over the 
graphical head. I can use either serial or graphical for input - that is, if I 
monitor the graphical head I can see the changes I'm typing on the serial 
console, but the serial console remains blank until I boot into Linux.

  Note: MAAS installations are not impacted by this because curtin adds
  an /etc/default/grub.d stub that manually sets
  "GRUB_TERMINAL=console".

  [Test Case]
  Install the system using d-i over the serial console.
  Comment out the HIDDEN variables in /etc/default/grub.
  sudo update-grub
  Reboot - and watch for the GRUB menu over the serial console.

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1743884/+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 1694859] Re: arm64 kernel crashdump support

[dann frazier]

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

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

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

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

** Changed in: makedumpfile (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: kexec-tools (Ubuntu Artful)
   Status: New => Fix Released

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  In Progress
Status in makedumpfile package in Debian:
  Unknown

Bug description:
  Note: Updates are being staged at ppa:dannf/arm64-kdump.

  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  If you want to verify that the dump is usable, install the
  corresponding linux-image--dbgsym package and run:

  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.

  crash should successfully load, placing you at a "crash>" prompt. At that 
prompt, you can issue the 'bt' command to see a backtrace.
  Note: you need crash from zesty (7.1.8-1ubuntu1) or later.

  [Regression Risk]
  = Kernel =
  3 patches here touch code outside of arch/arm64/:

  memblock: add memblock_clear_nomap()
  This adds a new function with no callers, so regression risk is negligible.
  (A later patch adds a call to it under arch/arm64/).

  memblock: add memblock_cap_memory_range()
  This refactors some of the code in memblock_mem_limit_remove_map() into a new 
function. The only existing caller of memblock_mem_limit_remove_map() is under 
arch/arm64/, so the regression risk outside of arm64 is negligible.

  efi/libstub/arm*: Set default address and size cells values for an empty dtb
  Because this code is for EFI platforms that support device-tree, it is 
de-facto ARM-specific (as noted in the patch title).

  For arm64, we have mitigated the risk by explicit regression testing on 
several platforms:
   - Qualcomm QDF2400
   - Cavium ThunderX CRB1S
   - HP m400 (X-Gene)
   - HiSilicon D05 (Hi07)

  = kexec-tools =
  == zesty ==
  For zesty, 10 patches are required to add kdump support.

  0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
  This modifies a function used on armhf & x86. The description explains the 
change, and why it does not impact those archs:

  -
  The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
  be affected by this change because
  * arm
    The callback function only returns -1 or 0, and the return value of
    kexec_iomem_for_each_line() will never be used.
  * sh, x86
    The callback function may return (-1 for sh,) 0 or 1, but always returns
    1 once we have reached the maximum number of entries allowed.
    Even so the current kexec_iomem_for_each_line() counts them up.
    This change actually fixes this bug.
  -

  0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
  This generalizes a function that was duplicated by arm & x86 and makes it 
common so arm64 can use it.

  The remaining 8 of these only touch code in kexec/arch/arm64, so
  regression risk for other architectures is negligible.

  Finally, I have tested this update on both i386 and amd64 VMs. i386
  crashes do not currently work in zesty (filed LP: #1699874), and my
  test results show no change there. amd64 worked before, and continues
  to work with these changes.

  == yakkety ==
  Since yakkety is based on an older upstream, 6 additional patches are 
required:

  arm-fix-

[Group.of.nepali.translators] [Bug 1694859] Re: arm64 kernel crashdump support

[dann frazier]

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

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

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

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: In Progress => 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/1694859

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in kexec-tools source package in Xenial:
  Fix Released
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Fix Released
Status in kexec-tools source package in Yakkety:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Won't Fix
Status in kexec-tools source package in Zesty:
  Fix Released
Status in linux source package in Zesty:
  Fix Released
Status in makedumpfile source package in Zesty:
  Fix Released
Status in kexec-tools source package in Artful:
  Fix Released
Status in linux source package in Artful:
  Fix Released
Status in makedumpfile source package in Artful:
  In Progress
Status in makedumpfile package in Debian:
  Unknown

Bug description:
  Note: Updates are being staged at ppa:dannf/arm64-kdump.

  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  If you want to verify that the dump is usable, install the
  corresponding linux-image--dbgsym package and run:

  sudo crash /usr/lib/debug/boot/vmlinux-
  /var/crash//dump.

  crash should successfully load, placing you at a "crash>" prompt. At that 
prompt, you can issue the 'bt' command to see a backtrace.
  Note: you need crash from zesty (7.1.8-1ubuntu1) or later.

  [Regression Risk]
  = Kernel =
  3 patches here touch code outside of arch/arm64/:

  memblock: add memblock_clear_nomap()
  This adds a new function with no callers, so regression risk is negligible.
  (A later patch adds a call to it under arch/arm64/).

  memblock: add memblock_cap_memory_range()
  This refactors some of the code in memblock_mem_limit_remove_map() into a new 
function. The only existing caller of memblock_mem_limit_remove_map() is under 
arch/arm64/, so the regression risk outside of arm64 is negligible.

  efi/libstub/arm*: Set default address and size cells values for an empty dtb
  Because this code is for EFI platforms that support device-tree, it is 
de-facto ARM-specific (as noted in the patch title).

  For arm64, we have mitigated the risk by explicit regression testing on 
several platforms:
   - Qualcomm QDF2400
   - Cavium ThunderX CRB1S
   - HP m400 (X-Gene)
   - HiSilicon D05 (Hi07)

  = kexec-tools =
  == zesty ==
  For zesty, 10 patches are required to add kdump support.

  0001-kexec-extend-the-semantics-of-kexec_iomem_for_each_l.patch:
  This modifies a function used on armhf & x86. The description explains the 
change, and why it does not impact those archs:

  -
  The current users of kexec_iomem_for_each_line(), arm, sh and x86, will not
  be affected by this change because
  * arm
    The callback function only returns -1 or 0, and the return value of
    kexec_iomem_for_each_line() will never be used.
  * sh, x86
    The callback function may return (-1 for sh,) 0 or 1, but always returns
    1 once we have reached the maximum number of entries allowed.
    Even so the current kexec_iomem_for_each_line() counts them up.
    This change actually fixes this bug.
  -

  0002-kexec-generalize-and-rename-get_kernel_stext_sym.patch:
  This generalizes a function that was duplicated by arm & x86 and makes it 
common so arm64 can use it.

  The remaining 8 of these only touch code in kexec/arch/arm64, so
  regression risk for other architectures is negligible.

  Finally, I have tested this update on both i386 and amd64 VMs. i386
  crashes do not currently work in zesty (filed LP: #1699874), and my
  test results show no change there. amd64 worked before, and continues
  to work with these changes.

  == yakkety ==
  Since yakkety is based on an older upstream, 6 additional patches are 
required:

  arm-fix-get_kernel_stext_sym-to-close-its-file.patch:
  This is a cleanup patch, cherry-picked because it allows later patches to 
apply w/o backporting. ARM-specific.

  kexec-add-max_size-to-memory_ranges.patch:
  Adds a new element to struct, to be used by later commits.

  

[Group.of.nepali.translators] [Bug 1745492] Re: Backport of Debian bug #785714 for Xenial to avoid unclean reboots

[dann frazier]

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

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

** No longer affects: kexec-tools (Ubuntu Artful)

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

Title:
  Backport of Debian bug #785714 for Xenial to avoid unclean reboots

Status in kexec-tools package in Ubuntu:
  New
Status in kexec-tools source package in Xenial:
  New
Status in kexec-tools package in Debian:
  Fix Released

Bug description:
  Debian bug #785714 is a fairly substantial one, as it causes unclean
  shutdowns.  In our case, KVM hosts with many guests will begin to
  partially shutdown a couple before kexec jumps the gun and reboots the
  machine.  Without this fix, kexec is of only minimal use on Xenial

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1745492/+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 1351267] Re: partman-auto prefers to give disk to swap, leaving root too small

[dann frazier]

This is no longer an issue post-xenial, since we now default to swap files.
For xenial, a low-touch solution might be to just cap the minimum swap size at 
2G, as per this attached patch.

** Patch added: "partman-auto.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1351267/+attachment/5057359/+files/partman-auto.debdiff

** Also affects: partman-auto (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: partman-auto (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: partman-auto (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: partman-auto (Ubuntu Xenial)
   Importance: Undecided => Medium

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

Title:
  partman-auto prefers to give disk to swap, leaving root too small

Status in partman-auto package in Ubuntu:
  Triaged
Status in partman-auto source package in Xenial:
  In Progress

Bug description:
  I was trying to install Ubuntu 14.04.1 LTS on an Oracle VirtualBox VM
  with 6.5GB of RAM and 8GB (default for a new Virtual HDD on
  VirtualBox) of disk space.

  I selected the option "Erase disk and install Ubuntu" (and post crash
  "Erase Ubuntu 14.04.1 LTS and reinstall") and let it use the defaults.

  The installer gives the error:

   "Some of the partitions you created are too small. Please make the
  following partitions at least this large:

   / 3.4 GB

   If you do not go back to the partitioner and increase the size of
  these partitions, the installation may fail."

  The message is very confusing to a new user who did not specify any
  partition sizes themselves.

  The installer created a 6GB Swap partition on the 8GB drive. The
  installer then could not install to the root partition and failed
  midway:

  "The installer encountered an error copying files to the hard disk:

  [Errno 28] No space left on device

  This is due to there being insufficient disk space for the install to
  complete on the target partition. Please run the installer again and
  select a larger partition to install into."

  ..then a box appears stating that the installer has crashed:

  "Installer crashed

  We're sorry; the installer crashed. After you close this window, we'll
  allow you to file a bug report using the integrated bug reporting
  tool. This will gather information about your system and your
  installation process. The details will be sent to our bug tracker and
  a developer will attend to the problem as soon as possible."

  The box cannot be closed. No bug reporting tool launches. The computer
  requires restarting to become usable again.

  Please let me know if you need any more information as this is my
  first bug report.

  Thanks for your time,
  Matthew

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1351267/+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 1743638] Re: Missing install-time driver for QLogic QED 25/40/100Gb Ethernet NIC

[dann frazier]

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

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

Title:
  Missing install-time driver for QLogic QED 25/40/100Gb Ethernet NIC

Status in debian-installer package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Fix Committed
Status in linux-firmware package in Ubuntu:
  New
Status in linux-hwe package in Ubuntu:
  Invalid
Status in linux-hwe-edge package in Ubuntu:
  Invalid
Status in debian-installer source package in Xenial:
  New
Status in linux source package in Xenial:
  In Progress
Status in linux-firmware source package in Xenial:
  New
Status in linux-hwe source package in Xenial:
  In Progress
Status in linux-hwe-edge source package in Xenial:
  In Progress
Status in debian-installer source package in Artful:
  New
Status in linux source package in Artful:
  In Progress
Status in linux-firmware source package in Artful:
  New
Status in linux-hwe source package in Artful:
  Invalid
Status in linux-hwe-edge source package in Artful:
  Invalid
Status in debian-installer source package in Bionic:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-firmware source package in Bionic:
  New
Status in linux-hwe source package in Bionic:
  Invalid
Status in linux-hwe-edge source package in Bionic:
  Invalid

Bug description:
  [Impact]
  Network installs over a QLogic QED 25/40/100Gb Ethernet NIC will not work.

  [Test Case]
  Attempt to use the netinst installer to install a system over this NIC.

  [Regression Risk]
  The fix is just add to add additional kernel modules to the installer to 
support this NIC. The biggest risk I see there is that it increases the size of 
the installer, which could potentially grow to bit for some smaller systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1743638/+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 1743638] Re: Missing install-time driver for QLogic QED 25/40/100Gb Ethernet NIC

[dann frazier]

** Also affects: debian-installer (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  Missing install-time driver for QLogic QED 25/40/100Gb Ethernet NIC

Status in debian-installer package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Fix Committed
Status in linux-hwe package in Ubuntu:
  Invalid
Status in linux-hwe-edge package in Ubuntu:
  Invalid
Status in debian-installer source package in Xenial:
  New
Status in linux source package in Xenial:
  In Progress
Status in linux-hwe source package in Xenial:
  In Progress
Status in linux-hwe-edge source package in Xenial:
  In Progress
Status in debian-installer source package in Artful:
  New
Status in linux source package in Artful:
  In Progress
Status in linux-hwe source package in Artful:
  Invalid
Status in linux-hwe-edge source package in Artful:
  Invalid
Status in debian-installer source package in Bionic:
  New
Status in linux source package in Bionic:
  Fix Committed
Status in linux-hwe source package in Bionic:
  Invalid
Status in linux-hwe-edge source package in Bionic:
  Invalid

Bug description:
  [Impact]
  Network installs over a QLogic QED 25/40/100Gb Ethernet NIC will not work.

  [Test Case]
  Attempt to use the netinst installer to install a system over this NIC.

  [Regression Risk]
  The fix is just add to add additional kernel modules to the installer to 
support this NIC. The biggest risk I see there is that it increases the size of 
the installer, which could potentially grow to bit for some smaller systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1743638/+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 1744754] Re: qemu-efi-aarch64 in >= artful can't boot xenial cloud images

[dann frazier]

@Robert: Actually, X-Gene is supported on trusty, which is non-GICv3,
but your point is taken. I personally think option #3 would be the best
option, but wasn't sure of the feasibility. However, I've been working
on the necessary kernel backports in the background over the past week,
and I now have something working that looks pretty clean/minimal. I'm
doing some regression testing now, and plan to submit to the kernel team
later this week.

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

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

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

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

Title:
  qemu-efi-aarch64 in >= artful can't boot xenial cloud images

Status in cloud-images:
  New
Status in edk2 package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Fix Released
Status in edk2 source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  In Progress

Bug description:
  [Impact]
  After upgrading your KVM hypervisor past xenial, your xenial-based guests 
will fail to boot.

  [Test Case]
  Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1744754/+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 1744754] [NEW] qemu-efi-aarch64 in >= artful can't boot xenial cloud images

[dann frazier]

Public bug reported:

[Impact]
After upgrading your KVM hypervisor past xenial, your xenial-based guests will 
fail to boot.

[Test Case]
Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.

[Regression Risk]
TBD

** Affects: cloud-images
 Importance: Undecided
 Status: New

** Affects: edk2 (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

** Affects: edk2 (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Status: Incomplete


** Tags: xenial

** Also affects: cloud-images
   Importance: Undecided
   Status: New

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

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

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

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

Title:
  qemu-efi-aarch64 in >= artful can't boot xenial cloud images

Status in cloud-images:
  New
Status in edk2 package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in edk2 source package in Xenial:
  New
Status in linux source package in Xenial:
  Incomplete

Bug description:
  [Impact]
  After upgrading your KVM hypervisor past xenial, your xenial-based guests 
will fail to boot.

  [Test Case]
  Boot a xenial cloud image with qemu-efi-aarch64 from artful/bionic.

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1744754/+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 1743638] Re: Missing install-time driver for QLogic QED 25/40/100Gb Ethernet NIC

[dann frazier]

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

** Also affects: linux (Ubuntu Bionic)
   Importance: High
 Assignee: dann frazier (dannf)
   Status: In Progress

** Also affects: linux-hwe (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

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

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

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

** Also affects: linux-hwe-edge (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-hwe-edge (Ubuntu Artful)
   Status: New => Invalid

** Changed in: linux-hwe-edge (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: linux-hwe (Ubuntu Artful)
   Status: New => Invalid

** Changed in: linux-hwe (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: linux-hwe-edge (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: linux-hwe-edge (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

** Changed in: linux-hwe (Ubuntu Xenial)
   Status: New => In Progress

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

** Changed in: linux (Ubuntu Artful)
   Importance: Undecided => High

** Changed in: linux-hwe (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: linux-hwe-edge (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Artful)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux-hwe (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  Missing install-time driver for QLogic QED 25/40/100Gb Ethernet NIC

Status in linux package in Ubuntu:
  In Progress
Status in linux-hwe package in Ubuntu:
  Invalid
Status in linux-hwe-edge package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  In Progress
Status in linux-hwe source package in Xenial:
  In Progress
Status in linux-hwe-edge source package in Xenial:
  In Progress
Status in linux source package in Artful:
  In Progress
Status in linux-hwe source package in Artful:
  Invalid
Status in linux-hwe-edge source package in Artful:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in linux-hwe source package in Bionic:
  Invalid
Status in linux-hwe-edge source package in Bionic:
  Invalid

Bug description:
  [Impact]
  Network installs over a QLogic QED 25/40/100Gb Ethernet NIC will not work.

  [Test Case]
  Attempt to use the netinst installer to install a system over this NIC.

  [Regression Risk]
  The fix is just add to add additional kernel modules to the installer to 
support this NIC. The biggest risk I see there is that it increases the size of 
the installer, which could potentially grow to bit for some smaller systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1743638/+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 722950] Re: ctrl-x does not work in grub-efi

[dann frazier]

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

** Changed in: grub2 (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Changed in: grub2 (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

Title:
  ctrl-x does not work in grub-efi

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

Bug description:
  Binary package hint: grub2

  If I boot the Natty daily livecd in EFI mode and press e at the grub
  prompt to edit the command, it says to press ctrl-x to boot the entry.
  Pressing ctrl-x results in it just inserting the letter 'x' instead of
  booting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/722950/+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 1692876] Re: ubuntu-server ARM64 ISOs lack partition table with EFI System Partition

[dann frazier]

** Description changed:

  [Impact]
  On some arm64/efi platforms, the firmware will not be able to boot from an 
ISO dd'd to a USB stick.
  
  [Test Case]
  My test is to attach the ISO as an "HD/USB Image" to a Cavium CRB1S w/ AMI 
UEFI firmware using the BMC's Virtual Media. Note that the BMC requires that 
the file be renamed with a ".img" suffix.
  
  [Regression Risk]
- For d-i, this is aligning the xorriso boot options with the same ones now 
used to build the server ISO.
+ For d-i, this is aligning the xorriso boot options with the same ones now 
used to build the server ISO. Regression risk has been mitigated by testing on 
real hardware connected as both CD and disk images.

** Changed in: ubuntu-cdimage
   Status: In Progress => Fix Committed

** Also affects: debian-installer (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: debian-installer (Ubuntu Xenial)
   Status: New => Fix Committed

** Changed in: debian-installer (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  ubuntu-server ARM64 ISOs lack partition table with EFI System
  Partition

Status in Ubuntu CD Images:
  Fix Committed
Status in debian-installer package in Ubuntu:
  Fix Committed
Status in debian-installer source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  On some arm64/efi platforms, the firmware will not be able to boot from an 
ISO dd'd to a USB stick.

  [Test Case]
  My test is to attach the ISO as an "HD/USB Image" to a Cavium CRB1S w/ AMI 
UEFI firmware using the BMC's Virtual Media. Note that the BMC requires that 
the file be renamed with a ".img" suffix.

  [Regression Risk]
  For d-i, this is aligning the xorriso boot options with the same ones now 
used to build the server ISO. Regression risk has been mitigated by testing on 
real hardware connected as both CD and disk images.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-cdimage/+bug/1692876/+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 722950] Re: ctrl-x does not work in grub-efi

[dann frazier]

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

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

Title:
  ctrl-x does not work in grub-efi

Status in grub2 package in Ubuntu:
  Triaged
Status in grub2 source package in Xenial:
  Confirmed
Status in grub2 source package in Zesty:
  Confirmed
Status in grub2 source package in Artful:
  Fix Released

Bug description:
  Binary package hint: grub2

  If I boot the Natty daily livecd in EFI mode and press e at the grub
  prompt to edit the command, it says to press ctrl-x to boot the entry.
  Pressing ctrl-x results in it just inserting the letter 'x' instead of
  booting.

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

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

[Group.of.nepali.translators] [Bug 1731241] Re: grub exit on arm64-efi crashes

[dann frazier]

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

** Changed in: grub2 (Ubuntu Xenial)
 Assignee: (unassigned) => Ike Panhc (ikepanhc)

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

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

** Changed in: grub2 (Ubuntu)
 Assignee: Ike Panhc (ikepanhc) => (unassigned)

** Description changed:

  [Impact]
  
-  * grub exit on arm64-efi causes exception
+  * grub exit on arm64-efi causes EFI exception, requiring reboot to
+ recover.
  
  [Test Case]
  
-  * Using grub cmdline and exit shall return to UEFI
+  * Using grub cmdline and exit shall return to UEFI
  
  [Regression Potential]
  
-  * Low regression risk due to
-- Only codes on exit with efi platform modified
-- patch cherry-picked from upstream and already in grub2 since zesty
+  * Low regression risk due to
+    - Only codes on exit with efi platform modified
+    - patch cherry-picked from upstream and already in grub2 since zesty
  
  [Other Info]
-  
-  * Patch on upstream
+ 
+  * Patch on upstream
  
  commit c945ca75c3b2b900040b905323b1226cb60a1166
  Author: Mark Salter 
  Date: Fri Aug 15 12:22:43 2014 -0400
  
- Fix exit to EFI firmware
+ Fix exit to EFI firmware
  
- The current code for EFI grub_exit() calls grub_efi_fini() before
- returning to firmware. In the case of ARM, this leaves a timer
- event running which could lead to a firmware crash. This patch
- changes this so that grub_machine_fini() is called with a NORETURN
- flag. This allows machine-specific shutdown to happen as well
- as the shutdown done by grub_efi_fini().
+ The current code for EFI grub_exit() calls grub_efi_fini() before
+ returning to firmware. In the case of ARM, this leaves a timer
+ event running which could lead to a firmware crash. This patch
+ changes this so that grub_machine_fini() is called with a NORETURN
+ flag. This allows machine-specific shutdown to happen as well
+ as the shutdown done by grub_efi_fini().
  
- Signed-off-by: Mark Salter 
+ Signed-off-by: Mark Salter 

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

Title:
  grub exit on arm64-efi crashes

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

Bug description:
  [Impact]

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

  [Test Case]

   * Using grub cmdline and exit shall return to UEFI

  [Regression Potential]

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

  [Other Info]

   * Patch on upstream

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

  Fix exit to EFI firmware

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

  Signed-off-by: Mark Salter 

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

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

[Group.of.nepali.translators] [Bug 1722579] [NEW] xgene nic unresponsive after ifdown/ifup

[dann frazier]

Public bug reported:

[Impact]
Sean Feole discovered that if you ifdown/ifup the NIC on an X-Gene 2 system, 
the NIC does not come back online. While the interface is reported as up, you 
cannot ping the system. In addition to the obvious problems this causes for a 
sysadmin, it also breaks software that does this automatically, such as juju 
when it sets up a host bridge.

[Test Case]
Boot an X-Gene 2 system, and start pinging it from a remote system. Assuming 
the pinged interface is eth0, run:

$ sudo ifdown eth0; sudo ifup eth0

System will cease responding to pings.

[Regression Risk]
(Still under investigation)

** Affects: linux (Ubuntu)
 Importance: Undecided
 Assignee: dann frazier (dannf)
 Status: Fix Released

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Assignee: dann frazier (dannf)
 Status: In Progress

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

Title:
  xgene nic unresponsive after ifdown/ifup

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

Bug description:
  [Impact]
  Sean Feole discovered that if you ifdown/ifup the NIC on an X-Gene 2 system, 
the NIC does not come back online. While the interface is reported as up, you 
cannot ping the system. In addition to the obvious problems this causes for a 
sysadmin, it also breaks software that does this automatically, such as juju 
when it sets up a host bridge.

  [Test Case]
  Boot an X-Gene 2 system, and start pinging it from a remote system. Assuming 
the pinged interface is eth0, run:

  $ sudo ifdown eth0; sudo ifup eth0

  System will cease responding to pings.

  [Regression Risk]
  (Still under investigation)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722579/+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 1722313] Re: [SRU][xenial] Add "--with-audit" config option so that the hwclock command creates an audit record when the hardware clock is altered.

[dann frazier]

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

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

** Also affects: util-linux (Ubuntu Zesty)
   Importance: Undecided
   Status: New

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

Title:
  [SRU][xenial] Add "--with-audit" config option so that the hwclock
  command creates an audit record when the hardware clock is altered.

Status in util-linux package in Ubuntu:
  New
Status in util-linux source package in Xenial:
  New
Status in util-linux source package in Zesty:
  New
Status in util-linux source package in Artful:
  New
Status in util-linux package in Debian:
  Unknown

Bug description:
  [IMPACT]
  There is a requirement for Common Criteria EAL2 certification that changes to 
the system's hardware clock be audited/monitored. In Ubuntu the hwclock command 
can be used to alter the system's hardware clock. Thus this event needs to be 
audited for EAL2. The hwclock command within util-linux has the ability to 
create an audit event when the system's hardware clock is altered, but this 
ability is enabled via the --with-audit config option. This option is currently 
not enabled.

  Only the hwclock and the login commands within util-linux package use
  this --with-audit config option to enable auditing. However, it
  appears the login command is not built nor shipped in util-linux.
  Ubuntu uses the login command from shadow instead. Thus, only hwclock
  command would be affected by this change. The change would enable (1)
  call to audit_open to create a netlink socket descritor. (2) generate
  an audit entry when system hardware clock altered. The entry will be
  logged into the /var/log/audit/audit.log IF auditd is installed and
  running.

  [TEST]

  This has been tested on both P8 and amd64 architectures. With the
  patch all the Common Criteria testcases pass for hwclock. Before this
  patch, the functional part of the testcase passed, but the check for
  the triggered audit records would fail. Attached the Common Criteria
  testcase below.

  Also, the util-linux package has testcases that get run during the
  build. All of these pass. Pointer to build log below.

  [REGRESSION POTENTIAL]
  The regression potential for this should be small. This change does not take 
away from any current functionality. It just adds the ability to generate an 
audit entry when system hardware clock is altered.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1722313/+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 1595739] Re: please backport arm64 mem{set, cpy, move} optimizations

[dann frazier]

These changes landed upstream in glibc 2.24, so are now in Ubuntu. Marking Fix 
Released.
Given the test results in Comment #2, marking the xenial task "Won't Fix".


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

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

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

Title:
  please backport arm64 mem{set,cpy,move} optimizations

Status in glibc package in Ubuntu:
  Fix Released
Status in glibc source package in Xenial:
  Won't Fix

Bug description:
  Optimizations to AArch64's memset, memcpy & memmove routines have
  recently landed upstream. The attached patch applies these clean
  cherry-picks to the current glibc packaging.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1595739/+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 1642298] Re: Grub package upgrades overwrites NVRAM, causing MAAS boot order to be overwritten.

[dann frazier]

** Changed in: grub2 (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

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

Title:
  Grub package upgrades overwrites NVRAM, causing MAAS boot order to be
  overwritten.

Status in curtin:
  Confirmed
Status in MAAS:
  Fix Committed
Status in MAAS 2.2 series:
  Triaged
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Trusty:
  Triaged
Status in grub2 source package in Xenial:
  Triaged
Status in grub2 source package in Yakkety:
  Won't Fix

Bug description:
  [Impact]
  Typically when you install Ubuntu on an EFI system, it installs a new default 
EFI boot entry that makes the system reboot directly into the OS. During MAAS 
installs, curtin is careful to disable that behavior. MAAS requires the default 
boot entry to remain PXE, so that it can direct the system to boot from disk or 
network as necessary. curtin does this by passing --no-nvram to grub-install 
when installing the bootloader.

  *Update*: newer curtin releases actually allow the creation of a new
  boot entry, but updates the boot menu to make PXE the default. That
  change is orthogonal to this bug.

  ***However***, this doesn't stop a new default boot entry from being
  added after deploy. If the user installs a grub package update or
  manually runs 'grub-install', booting from disk will become the
  default, and MAAS will lose control of the system.

  [Proposed Solution (er... glorified workaround)]
  The GRUB package in zesty now has support for setting the --no-nvram flag 
*persistently*. This is implemented via a debconf template 
(grub2/update_nvram). If curtin sets this flag to "false" during install, 
post-deploy grub updates will also pass the --no-nvram flag when running 
grub-install.

  This isn't a perfect solution - users can still call grub-install
  manually and omit this flag.

  [Test Case]
   - MAAS deploy an EFI system.
   - After deploy, login and run 'sudo apt --reinstall install grub-efi-$(dpkg 
--print-architecture)
   - Reboot and observe that the system does not PXE boot.

  [Regression Risk]
   - The GRUB implementation does not change the defaults of the package. The 
user would need to opt-in to the "grub2/update_nvram=false". This option is 
also only presented to users who specifically request a low debconf priority 
(e.g. expert mode installs).
   - XXX curtin risk XXX

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1642298/+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 1710019] Re: support GICv3 ITS save/restore & migration

[dann frazier]

Here's a backport for zesty's QEMU, tested with the 4.13.0-7.8 kernel
from ppa:canonical-kernel-team/unstable w/ the patch from Comment #10
applied.

** Changed in: qemu (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/1710019

Title:
  support GICv3 ITS save/restore & migration

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

Bug description:
  [Impact]
  Virtual machines on GICv3-based ARM systems cannot be saved/restored or 
migrated.
  This feature was added in QEMU 2.10.

  [Test Case]
  ubuntu@grotrian:~$ sudo virsh save 7936-0 7936-0.sav

  Domain 7936-0 saved to 7936-0.sav

  ubuntu@grotrian:~$ sudo virsh restore 7396-0.sav
  error: Failed to restore domain from 7396-0.sav
  error: operation failed: job: unexpectedly failed

  ubuntu@grotrian:~$ sudo tail -3 /var/log/libvirt/qemu/7936-0.log 
  2017-08-10T21:26:38.217427Z qemu-system-aarch64: State blocked by 
non-migratable device 'arm_gicv3_its'
  2017-08-10T21:26:38.217565Z qemu-system-aarch64: load of migration failed: 
Invalid argument
  2017-08-10 21:26:38.217+: shutting down, reason=failed

  [Regression Risk]

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

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

[Group.of.nepali.translators] [Bug 1710019] Re: support GICv3 ITS save/restore & migration

[dann frazier]

@Vijaya: Yes, that patch does resolve the issue for me, thanks! Do you
plan to submit this upstream?

@Christian: Yep - I'll open one.

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

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

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

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

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

** Changed in: qemu (Ubuntu)
     Assignee: dann frazier (dannf) => (unassigned)

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

Title:
  support GICv3 ITS save/restore & migration

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

Bug description:
  [Impact]
  Virtual machines on GICv3-based ARM systems cannot be saved/restored or 
migrated.
  This feature was added in QEMU 2.10.

  [Test Case]
  ubuntu@grotrian:~$ sudo virsh save 7936-0 7936-0.sav

  Domain 7936-0 saved to 7936-0.sav

  ubuntu@grotrian:~$ sudo virsh restore 7396-0.sav
  error: Failed to restore domain from 7396-0.sav
  error: operation failed: job: unexpectedly failed

  ubuntu@grotrian:~$ sudo tail -3 /var/log/libvirt/qemu/7936-0.log 
  2017-08-10T21:26:38.217427Z qemu-system-aarch64: State blocked by 
non-migratable device 'arm_gicv3_its'
  2017-08-10T21:26:38.217565Z qemu-system-aarch64: load of migration failed: 
Invalid argument
  2017-08-10 21:26:38.217+: shutting down, reason=failed

  [Regression Risk]

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

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

[Group.of.nepali.translators] [Bug 1595242] Re: mongodb xenial s390x packages are needed (blocks ceilometer)

[dann frazier]

** Also affects: google-perftools (Ubuntu)
   Importance: Undecided
   Status: New

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

Title:
  mongodb xenial s390x packages are needed (blocks ceilometer)

Status in OpenStack ceilometer charm:
  Invalid
Status in OpenStack ceilometer-agent charm:
  Invalid
Status in MongoDB Charm:
  Confirmed
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in google-perftools package in Ubuntu:
  New
Status in mongodb package in Ubuntu:
  Confirmed
Status in google-perftools source package in Xenial:
  New
Status in mongodb source package in Xenial:
  Won't Fix
Status in google-perftools source package in Yakkety:
  New
Status in mongodb source package in Yakkety:
  Won't Fix
Status in ceilometer package in Juju Charms Collection:
  Invalid
Status in ceilometer-agent package in Juju Charms Collection:
  Invalid
Status in mongodb package in Juju Charms Collection:
  Invalid
Status in mongodb package in Debian:
  Fix Released

Bug description:
  The ceilometer and ceilometer-agent charms require the mongodb charm.

  s390x validation for ceilometer and ceilometer-agent is blocked on the
  absence of mongodb packages in s390x Xenial, and on the absence of a
  Xenial mongodb charm in general.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-ceilometer/+bug/1595242/+subscriptions

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

[Group.of.nepali.translators] [Bug 1709920] Re: criu is not built for arm64

[dann frazier]

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

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

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

Title:
  criu is not built for arm64

Status in criu package in Ubuntu:
  New
Status in criu source package in Xenial:
  New
Status in criu source package in Zesty:
  New
Status in criu package in Debian:
  Unknown

Bug description:
  The criu package has source code for arch/aarch64, but arm64 is not
  listed in the control file so LP does not attempt to build it.

  At least for artful, adding arm64 to the supported list in
  debian/control is sufficient for the build to succeed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/criu/+bug/1709920/+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 1709727] Re: asan causes hangs on arm64

[dann frazier]

** Changed in: gcc-6 (Ubuntu Xenial)
   Status: New => Invalid

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

Title:
  asan causes hangs on arm64

Status in gcc-5 package in Ubuntu:
  New
Status in gcc-6 package in Ubuntu:
  New
Status in gcc-5 source package in Xenial:
  New
Status in gcc-6 source package in Xenial:
  Invalid
Status in gcc-5 source package in Zesty:
  New
Status in gcc-6 source package in Zesty:
  New

Bug description:
  [Impact]
  Binaries built w/ asan support hang on arm64. This causes many timeouts 
during the test phase of a gcc build, causing builds to need ~24 hours to 
complete.

  [Test Case]
  $ cat test.c
  #include 

  void main() {
printf("hi.\n");
  }
  $ gcc test.c -g -fsanitize=address -fno-omit-frame-pointer test.c -o test
  $ ./test
  ==46644==AddressSanitizer CHECK failed: 
../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator.h:844 
"((res)) < ((kNumPossibleRegions))" (0xb4b, 0x800)
  [... HANG ...]

  [Regression Risk]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1709727/+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 1704817] Re: [Xenial] nvme-cli does not recognize version 1.0 NVME drives

[dann frazier]

@Manoj: While the code in the patch looks fine, I do see a couple issues
with the DEP-3 headers:

>Description: Remove version from list
> We can't reliably map controller registers due to kernel memory
> protections added in kernel commit 90a545e98, so we are removing its
> dependency for the 'list' command to run.
> Author: Keith Busch 

I'd suggest starting with the git commit, including all the metadata,
and adding the DEP-3 specific fields (Origin, Bug) to the end of the
header.

> Origin: upstream, https://github.com/linux-nvme/nvme-cli

Origin should be the URL of the commit, not the repository.

> Bug: https://launchpad.net/bugs/##

This isn't a valid URL, and it should be a pointer to the upstream bug,
if one exists. The "Bug-Ubuntu" field should be used to provide a
pointer to the Ubuntu bug in LP.

> Forwarded: not-needed

Well, technically it *is* needed since it was applied upstream. I'd
suggest just omitting this field though, it only really makes sense if
it is a vendor-specific patch.


** Changed in: nvme-cli (Ubuntu Xenial)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** No longer affects: nvme-cli (Ubuntu Zesty)

** Changed in: nvme-cli (Ubuntu Xenial)
   Status: New => Confirmed

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

Title:
  [Xenial] nvme-cli does not recognize version 1.0 NVME drives

Status in nvme-cli package in Ubuntu:
  Fix Released
Status in nvme-cli source package in Xenial:
  Confirmed

Bug description:
  [Impact]
  We've noticed that the nvme-cli package does not work on QDF2400 and gives 
the false impression that the hardware is broken. This prevents customers from 
running NVMe diagnostics. 

  [Test Case]
  Current version available -
  ubuntu@ubuntu:~$ sudo nvme version
  nvme version 0.5

  Current failure mode -
  root@ubuntu:/home/ubuntu# nvme list
  nvme0 did not find a pci resource

  Known issue: https://github.com/linux-nvme/nvme-cli/issues/81

  [Fix]
  Backport patch 
https://github.com/linux-nvme/nvme-cli/commit/6ab2e9ef204053d82c1eb40e514119286749cefe

  [Regression Potential]
  None. This was tested by QTI on Version 1.0 card and by Canonical on Version 
1.2 card.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1704817/+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 1704817] Re: [Xenial] nvme-cli does not recognize version 1.0 NVME drives

[dann frazier]

** Also affects: nvme-cli (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: nvme-cli (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: nvme-cli (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: nvme-cli (Ubuntu Zesty)
   Status: New => Fix Released

** Changed in: nvme-cli (Ubuntu)
 Assignee: dann frazier (dannf) => (unassigned)

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

Title:
  [Xenial] nvme-cli does not recognize version 1.0 NVME drives

Status in nvme-cli package in Ubuntu:
  Fix Released
Status in nvme-cli source package in Xenial:
  New
Status in nvme-cli source package in Zesty:
  Fix Released

Bug description:
  [Impact]
  We've noticed that the nvme-cli package does not work on QDF2400 and gives 
the false impression that the hardware is broken. This prevents customers from 
running NVMe diagnostics. 

  [Test Case]
  Current version available -
  ubuntu@ubuntu:~$ sudo nvme version
  nvme version 0.5

  Current failure mode -
  root@ubuntu:/home/ubuntu# nvme list
  nvme0 did not find a pci resource

  Known issue: https://github.com/linux-nvme/nvme-cli/issues/81

  [Fix]
  Backport patch 
https://github.com/linux-nvme/nvme-cli/commit/6ab2e9ef204053d82c1eb40e514119286749cefe

  [Regression Potential]
  None. This was tested by QTI on Version 1.0 card and by Canonical on Version 
1.2 card.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1704817/+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 1705137] Re: ACPI platform nics names change after install

[dann frazier]

** Changed in: debian-installer (Ubuntu)
   Status: New => Invalid

** Changed in: debian-installer (Ubuntu Xenial)
   Status: New => Fix Committed

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

Title:
  ACPI platform nics names change after install

Status in debian-installer package in Ubuntu:
  Invalid
Status in debian-installer source package in Xenial:
  Fix Committed

Bug description:
  systemd in xenial-proposed has support for predictable network
  interfaces names for ACPI-described platform devices. However, the
  latest d-i in xenial-proposed was built with the previous systemd
  upload. This has a nasty side-effect that the NICs will have one name
  during install (e.g. eth1) but, after reboot, will have a different
  name (e.g. enahisic1). Further, if you used one of these NICs as your
  install interface, the network will fail to come up post-install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1705137/+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 1705137] [NEW] ACPI platform nics names change after install

[dann frazier]

Public bug reported:

systemd in xenial-proposed has support for predictable network
interfaces names for ACPI-described platform devices. However, the
latest d-i in xenial-proposed was built with the previous systemd
upload. This has a nasty side-effect that the NICs will have one name
during install (e.g. eth1) but, after reboot, will have a different name
(e.g. enahisic1). Further, if you used one of these NICs as your install
interface, the network will fail to come up post-install.

** Affects: debian-installer (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: debian-installer (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Also affects: debian-installer (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Description changed:

  systemd in xenial-proposed has support for predictable network
  interfaces names for ACPI-described platform devices. However, the
  latest d-i in xenial-proposed was built with the previous systemd
- upload. This has a nasty side-effect that the NICs will have have
- different names during install (e.g. eth1) but after reboot, will have a
- different name (e.g. enahisic1). Further, if you used one of these NICs
- as your install interface, the network will fail to come up post-
- install.
+ upload. This has a nasty side-effect that the NICs will have one name
+ during install (e.g. eth1) but, after reboot, will have a different name
+ (e.g. enahisic1). Further, if you used one of these NICs as your install
+ interface, the network will fail to come up post-install.

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

Title:
  ACPI platform nics names change after install

Status in debian-installer package in Ubuntu:
  New
Status in debian-installer source package in Xenial:
  New

Bug description:
  systemd in xenial-proposed has support for predictable network
  interfaces names for ACPI-described platform devices. However, the
  latest d-i in xenial-proposed was built with the previous systemd
  upload. This has a nasty side-effect that the NICs will have one name
  during install (e.g. eth1) but, after reboot, will have a different
  name (e.g. enahisic1). Further, if you used one of these NICs as your
  install interface, the network will fail to come up post-install.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1705137/+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 1238110] Re: makedumpfile needs porting for AArch64

[dann frazier]

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

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

Title:
  makedumpfile needs porting for AArch64

Status in Linaro AArch64 cross-distro work:
  New
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  New

Bug description:
  $ ls arch/
  arm.c  ia64.c  ppc.c  ppc64.c  s390x.c  x86.c  x86_64.c

To manage notifications about this bug go to:
https://bugs.launchpad.net/linaro-aarch64/+bug/1238110/+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 1695093] Re: arm64: "unsupported RELA relocation: 275" loading certain modules

[dann frazier]

** Changed in: gcc-6 (Ubuntu Xenial)
   Status: Confirmed => Invalid

** Also affects: gcc-5 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: gcc-5 (Ubuntu Xenial)
   Status: New => Confirmed

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

Title:
  arm64: "unsupported RELA relocation: 275" loading certain modules

Status in Linux:
  In Progress
Status in gcc-5 package in Ubuntu:
  New
Status in gcc-6 package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed
Status in gcc-5 source package in Xenial:
  Confirmed
Status in gcc-6 source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  Confirmed
Status in gcc-5 source package in Yakkety:
  New
Status in gcc-6 source package in Yakkety:
  Confirmed
Status in linux source package in Yakkety:
  Confirmed
Status in gcc-5 source package in Zesty:
  New
Status in gcc-6 source package in Zesty:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

Bug description:
  With the hwe-z kernel:

  ubuntu@grotian:~$ sudo modprobe libceph
  modprobe: ERROR: could not insert 'libceph': Exec format error
  ubuntu@grotian:~$ dmesg
  [66988.470307] module libceph: unsupported RELA relocation: 275

  This symptom is similar to LP: #1533009 but, in that case it impacted
  all modules, and the fix for that appears to remain in place.

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1695093/+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 1699933] Re: ipmi-locate crash on arm64

[dann frazier]

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

** Also affects: freeipmi (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800038
   Importance: Unknown
   Status: Unknown

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

Title:
  ipmi-locate crash on arm64

Status in freeipmi package in Ubuntu:
  New
Status in freeipmi source package in Xenial:
  New
Status in freeipmi source package in Yakkety:
  New
Status in freeipmi source package in Zesty:
  New
Status in freeipmi source package in Artful:
  New
Status in freeipmi package in Debian:
  Unknown

Bug description:
  Similiar to bug 1499838 but not 100% same.

  ipmi-locate looks into /dev/mem for DMI tables and crash when DMI
  tables are not in accessible memory region. Kernel > v4.2 provides
  /sys/firmware/DMI/tables/DMI which is a much safer place to read.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1699933/+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 1700826] [NEW] please include numactl on the ubuntu-server iso

[dann frazier]

Public bug reported:

I've submitted an MIR for the numactl binary package at: LP: #1700824.
Assuming that is approved, please also include this on the server seed, which I 
believe is necessary for it to appear on the ubuntu-server ISOs.

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: ubuntu-meta (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Also affects: ubuntu-meta (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** No longer affects: ubuntu-meta (Ubuntu Yakkety)

** No longer affects: ubuntu-meta (Ubuntu Xenial)

** No longer affects: ubuntu-meta (Ubuntu Zesty)

** Also affects: ubuntu-meta (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

Title:
  please include numactl on the ubuntu-server iso

Status in ubuntu-meta package in Ubuntu:
  New
Status in ubuntu-meta source package in Xenial:
  New

Bug description:
  I've submitted an MIR for the numactl binary package at: LP: #1700824.
  Assuming that is approved, please also include this on the server seed, which 
I believe is necessary for it to appear on the ubuntu-server ISOs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1700826/+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 1699933] Re: ipmi-locate crash on arm64

[dann frazier]

** Also affects: freeipmi (Ubuntu Artful)
   Importance: Undecided
 Assignee: Ike Panhc (ikepanhc)
   Status: New

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

** Also affects: freeipmi (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

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

Title:
  ipmi-locate crash on arm64

Status in freeipmi package in Ubuntu:
  New
Status in freeipmi source package in Xenial:
  New
Status in freeipmi source package in Yakkety:
  New
Status in freeipmi source package in Zesty:
  New
Status in freeipmi source package in Artful:
  New

Bug description:
  Similiar to bug 1499838 but not 100% same.

  ipmi-locate looks into /dev/mem for DMI tables and crash when DMI
  tables are not in accessible memory region. Kernel > v4.2 provides
  /sys/firmware/DMI/tables/DMI which is a much safer place to read.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freeipmi/+bug/1699933/+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 1384955] Re: support compressed kernels on arm64

[dann frazier]

** Changed in: linux-hwe-edge (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: linux-hwe-edge (Ubuntu)
   Status: New => Fix Released

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

Title:
  support compressed kernels on arm64

Status in debian-installer package in Ubuntu:
  Fix Released
Status in flash-kernel package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux-hwe-edge package in Ubuntu:
  Fix Released
Status in debian-installer source package in Xenial:
  Fix Released
Status in flash-kernel source package in Xenial:
  Fix Released
Status in linux-hwe-edge source package in Xenial:
  Fix Released
Status in flash-kernel package in Debian:
  New

Bug description:
  [Impact]
  Ubuntu kernels >= hwe-y (4.8) will no longer boot on xgene/uboot systems. The 
image size appears to have outgrown the defined firmware region, and u-boot 
will error out with a checksum mismatch error. A solution for this is to start 
shipping a compressed kernel (Image.gz target). flash-kernel needs updating to 
detect a compressed kernel and set the appropriate uImage compression flag. 
Similarly, d-i needs updating because it does it's own uImage generation.

  [Test Case]
  Boot an hwe-y kernel on an xgene/uboot system (APM Mustang, HP ProLiant m400).

  [Regression Risk]
  The necessary code is in place and in-use for yakkety, and no issues have 
been discovered there. The SRU involves clean cherry-picks of that code for d-i 
& f-k. The kernel side needs to be modified to pull in the correct version of 
flash-kernel for xenial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1384955/+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 1694859] Re: arm64 kernel crashdump support

[dann frazier]

** No longer affects: kexec-tools (Ubuntu Yakkety)

** Also affects: kexec-tools (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

** Also affects: makedumpfile (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

** Changed in: kexec-tools (Ubuntu Yakkety)
   Status: New => Confirmed

** Changed in: kexec-tools (Ubuntu Yakkety)
 Assignee: (unassigned) => dann frazier (dannf)

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

** Changed in: makedumpfile (Ubuntu Yakkety)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Yakkety)
   Status: New => Won't Fix

** Changed in: linux (Ubuntu Zesty)
   Status: Confirmed => In Progress

** Changed in: linux (Ubuntu Zesty)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: linux (Ubuntu Xenial)
   Status: Incomplete => Won't Fix

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  In Progress
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in linux source package in Yakkety:
  Won't Fix
Status in makedumpfile source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  In Progress
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1694859/+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 1694859] Re: arm64 kernel crashdump support

[dann frazier]

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

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

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

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

** Changed in: kexec-tools (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: kexec-tools (Ubuntu Zesty)
   Status: Confirmed => In Progress

** Changed in: kexec-tools (Ubuntu Zesty)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in makedumpfile package in Ubuntu:
  Confirmed
Status in kexec-tools source package in Xenial:
  Confirmed
Status in linux source package in Xenial:
  Incomplete
Status in makedumpfile source package in Xenial:
  Confirmed
Status in kexec-tools source package in Yakkety:
  Confirmed
Status in kexec-tools source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  Confirmed
Status in makedumpfile source package in Zesty:
  Confirmed

Bug description:
  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  sudo apt install kdump-tools
  (reboot, so crashkernel= is added to the kernel commandline)
  echo c | sudo tee /proc/sysrq-trigger

  Crash dump should occur, with artifacts collected in /var/crash.

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1694859/+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 1694859] [NEW] arm64 kernel crashdump support

[dann frazier]

Public bug reported:

[Impact]
It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

[Test Case]
TBD

[Regression Risk]
TBD

** Affects: kexec-tools (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

** Affects: kexec-tools (Ubuntu Xenial)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Status: Incomplete

** Affects: kexec-tools (Ubuntu Yakkety)
 Importance: Undecided
 Status: New

** Affects: kexec-tools (Ubuntu Zesty)
 Importance: Undecided
 Status: New

** Affects: linux (Ubuntu Zesty)
 Importance: Undecided
 Status: Incomplete

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

** Also affects: kexec-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: kexec-tools (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

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

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

** No longer affects: linux (Ubuntu Yakkety)

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

Title:
  arm64 kernel crashdump support

Status in kexec-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in kexec-tools source package in Xenial:
  New
Status in linux source package in Xenial:
  Incomplete
Status in kexec-tools source package in Yakkety:
  New
Status in kexec-tools source package in Zesty:
  New
Status in linux source package in Zesty:
  Incomplete

Bug description:
  [Impact]
  It is not possible to collect a kernel crash dump from a crashed arm64 server 
for later debugging.

  [Test Case]
  TBD

  [Regression Risk]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1694859/+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 1691614] Re: please enable CONFIG_ARM64_LSE_ATOMICS

[dann frazier]

I'm unaware of any systems that support LSE that are also supported by
the hwe-{x,y,z} kernels. I'll therefore mark those as "Won't Fix" for
those releases. If someone is aware of such a system - and can take on
the testing of this change for those releases, we can reconsider.

** Changed in: linux (Ubuntu Xenial)
   Status: Triaged => Won't Fix

** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Yakkety)
   Status: Triaged => Won't Fix

** Changed in: linux (Ubuntu Zesty)
   Status: Triaged => Won't Fix

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

Title:
  please enable CONFIG_ARM64_LSE_ATOMICS

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  Won't Fix
Status in linux source package in Yakkety:
  Won't Fix
Status in linux source package in Zesty:
  Won't Fix

Bug description:
  [Impact]
  Performance is lowered for ARM >= v8.1 cpus by not taking advantage of the 
"Large System Extenstion" atomic instructions they provide.

  Note: This config was enabled during xenial development, but was
  disabled to workaround a FTBFS[*] due to us not having a new enough
  binutils to support it. binutils was later updated in xenial, and
  supports these instructions.

  [Test Case]
  grep CONFIG_ARM64_LSE_ATOMICS=y /boot/config-$(uname -r)

  [Regression Risk]
  There is a known small performance overhead for < ARMv8.1 arm64 systems 
(noted in the Kconfig). To mitigate the risk of runtime or build failures, this 
should be tested on both ARMv8 and >= ARMv8.1 systems, to exercise both code 
paths.

  [*] https://answers.launchpad.net/~canonical-kernel-
  team/+archive/ubuntu/unstable/+build/8438034

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1691614/+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 1691614] [NEW] please enable CONFIG_ARM64_LSE_ATOMICS

[dann frazier]

Public bug reported:

[Impact]
Performance is lowered for ARM >= v8.1 cpus by not taking advantage of the 
"Large System Extenstion" atomic instructions they provide.

Note: This config was enabled during xenial development, but was
disabled to workaround a FTBFS[*] due to us not having a new enough
binutils to support it. binutils was later updated in xenial, and
supports these instructions.

[Test Case]
TBD

[Regression Risk]
There is a known small performance overhead for <= ARMv8.1 arm64 systems (noted 
in the Kconfig).
[...TBD...]


[*] 
https://launchpadlibrarian.net/229977996/buildlog_ubuntu-xenial-arm64.linux_4.4.0-0.5_BUILDING.txt.gz

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Status: Incomplete

** Affects: linux (Ubuntu Yakkety)
 Importance: Undecided
 Status: Incomplete

** Affects: linux (Ubuntu Zesty)
 Importance: Undecided
 Status: Incomplete

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

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

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

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

Title:
  please enable CONFIG_ARM64_LSE_ATOMICS

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  Incomplete
Status in linux source package in Yakkety:
  Incomplete
Status in linux source package in Zesty:
  Incomplete

Bug description:
  [Impact]
  Performance is lowered for ARM >= v8.1 cpus by not taking advantage of the 
"Large System Extenstion" atomic instructions they provide.

  Note: This config was enabled during xenial development, but was
  disabled to workaround a FTBFS[*] due to us not having a new enough
  binutils to support it. binutils was later updated in xenial, and
  supports these instructions.

  [Test Case]
  TBD

  [Regression Risk]
  There is a known small performance overhead for <= ARMv8.1 arm64 systems 
(noted in the Kconfig).
  [...TBD...]

  
  [*] 
https://launchpadlibrarian.net/229977996/buildlog_ubuntu-xenial-arm64.linux_4.4.0-0.5_BUILDING.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1691614/+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 1673564] Re: ThunderX: soft lockup on 4.8+ kernels when running qemu-efi with vhost=on

[dann frazier]

Note that, while this symptom is seemingly only reproducible with >=
4.10 (hwe-y), there is another symptom of this problem that is
reproducible with 4.4 (hwe-x). That symptom is that VMs will hang during
teardown - easily reproducible using a parallel VM start/stop test. I'll
therefore mark this as impacting >= xenial.

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

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

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

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

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

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

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

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

** Changed in: linux (Ubuntu Yakkety)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Zesty)
   Importance: Undecided => High

** Description changed:

- This is a followup of an earlier thread/bug that we have narrowed down
- to an incompatibility/issue with vhost support in qemu-efi. Without
- vhost=on qemu seems to be working fine.
+ [Impact]
+ VMs can cause interrupts to be disabled on the host CPU, resulting in hangs.
  
- I have tested several edk2 firmwares:
- - xenial
- - zesty
- - Fedora: 
ftp://195.220.108.108/linux/fedora-secondary/development/rawhide/Everything/aarch64/os/Packages/e/edk2-aarch64-20170209git296153c5-2.fc26.noarch.rpm
+ [Test Case]
+ See Comment #1.
  
- I have also tested with different guests:
- - cirros: 
https://download.cirros-cloud.net/daily/20161201/cirros-d161201-aarch64-disk.img
- - ubuntu xenial: 
https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-arm64-uefi1.img
- 
- The test steps are simple enough. A tap device is needed, qemu-kvm,
- qemu-efi need to be installed. The UEFI iamge is run as shown in the
- launch.sh script, the tap device is used in vhost=on mode.
- 
- Also note that the QEMU_EFI.fd binary needs to be padded up to 64M:
- dd if=/dev/zero of=AAVMF_CODE.fd bs=1M count=64
- dd if=QEMU_EFI.fd of=AAVMF_CODE.fd conv=notrunc
- 
- 
- The result was always the same, the node crashing with soft-lockups when qemu 
was attempting to boot the kernel.
- 
- I will attach all the relevant information shortly.
+ [Regression Risk]
+ (TBD, once proposed patches are finalized)

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

Title:
  ThunderX: soft lockup on 4.8+ kernels when running qemu-efi with
  vhost=on

Status in linux package in Ubuntu:
  Confirmed
Status in linux source package in Xenial:
  Confirmed
Status in linux source package in Yakkety:
  Confirmed
Status in linux source package in Zesty:
  Confirmed

Bug description:
  [Impact]
  VMs can cause interrupts to be disabled on the host CPU, resulting in hangs.

  [Test Case]
  See Comment #1.

  [Regression Risk]
  (TBD, once proposed patches are finalized)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1673564/+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 1671246] Re: kexec-tools does not build for armhf

[dann frazier]

** Changed in: kexec-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu Yakkety)
 Assignee: (unassigned) => Manoj Iyer (manjo)

** Changed in: kexec-tools (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  kexec-tools does not build for armhf

Status in kexec-tools package in Ubuntu:
  Invalid
Status in kexec-tools source package in Xenial:
  In Progress
Status in kexec-tools source package in Yakkety:
  In Progress

Bug description:
  [Impact]
  On armhf system kexec build fails as follows:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 
-I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt 
-I./kexec/arch/arm/include  -c -MD -o kexec/arch/arm/phys_to_virt.o 
kexec/arch/arm/phys_to_virt.c
  make[1]: *** No rule to make target 'kexec/arch/arm/iomem.o', needed by 
'build/sbin/kexec'.  Stop.

  The fix for this issue is already upstream:

  From c901bae8683c59a7bc002bd6a1e3e4b6b7d9c5f1 Mon Sep 17 00:00:00 2001
  From: Simon Horman 
  Date: Fri, 9 Dec 2016 10:10:49 +0100
  Subject: [PATCH] arm: do not build iomem.o target with no soruce

  Header files should be added to the distribution but not
  used to derive targets for compilation. In this an attempt was
  made to build iomem.o, but iomem.c does not exist so this fails.

  Fixes: 1574ff1aae4f ("arm: include phys_to_virt.h and iomem.h in 
distribution")
  Signed-off-by: Simon Horman 
  Reviewed-by: Pratyush Anand 

  [Test Case]
  Build kexec-tools package from Xenial/Yakkety source in armhf system.

  [Regression Potential]
  Since patch is confined to arm there is a low overall risk of regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+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 1671246] Re: kexec-tools does not build for armhf

[dann frazier]

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

** Also affects: kexec-tools (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

Title:
  kexec-tools does not build for armhf

Status in kexec-tools package in Ubuntu:
  Incomplete
Status in kexec-tools source package in Xenial:
  New
Status in kexec-tools source package in Yakkety:
  New

Bug description:
  [Impact]
  On armhf system kexec build fails as follows:
  gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-fno-strict-aliasing -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 
-I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt 
-I./kexec/arch/arm/include  -c -MD -o kexec/arch/arm/phys_to_virt.o 
kexec/arch/arm/phys_to_virt.c
  make[1]: *** No rule to make target 'kexec/arch/arm/iomem.o', needed by 
'build/sbin/kexec'.  Stop.

  The fix for this issue is already upstream:

  From c901bae8683c59a7bc002bd6a1e3e4b6b7d9c5f1 Mon Sep 17 00:00:00 2001
  From: Simon Horman 
  Date: Fri, 9 Dec 2016 10:10:49 +0100
  Subject: [PATCH] arm: do not build iomem.o target with no soruce

  Header files should be added to the distribution but not
  used to derive targets for compilation. In this an attempt was
  made to build iomem.o, but iomem.c does not exist so this fails.

  Fixes: 1574ff1aae4f ("arm: include phys_to_virt.h and iomem.h in 
distribution")
  Signed-off-by: Simon Horman 
  Reviewed-by: Pratyush Anand 

  [Test Case]
  Build kexec-tools package from Xenial/Yakkety source in armhf system.

  [Regression Potential]
  Since patch is confined to arm there is a low overall risk of regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/1671246/+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 1642298] Re: UEFI Xenial install sets computer to boot from hard disk

[dann frazier]

The grub2 changes are in zesty as of 2.02~beta3-4ubuntu1. Could I ask
the curtin developers to take a look at implementing the necessary
changes there? Specifically, using the new grub2/update_nvram preseed
instead of manually passing --no-nvram to grub-install during install.

** Also affects: grub2 (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

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

Title:
  UEFI Xenial install sets computer to boot from hard disk

Status in curtin:
  Confirmed
Status in MAAS:
  Invalid
Status in grub2 package in Ubuntu:
  Fix Released
Status in grub2 source package in Trusty:
  Triaged
Status in grub2 source package in Xenial:
  Triaged
Status in grub2 source package in Yakkety:
  Triaged

Bug description:
  This bug is a regression of bug #1311827.

  On a current MAAS 2.0 installation, I've discovered that MAAS is now
  overriding the PXE-boot settings, causing the system to attempt to
  boot directly from the grubx64.efi on the hard disk's EFI System
  Partition (ESP). After installation, the result looks like this:

  ubuntu@oil-hatanaka:~$ sudo efibootmgr
  BootCurrent: 0005
  Timeout: 1 seconds
  BootOrder: 0005,0001,0002,0003,0004
  Boot0001* UEFI: IP4 ELX NIC Bus:Dev:Func 3:0:0 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0002* UEFI: IP6 ELX NIC Bus:Dev:Func 3:0:0 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0003* UEFI: IP4 ELX NIC Bus:Dev:Func 3:0:1 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0004* UEFI: IP6 ELX NIC Bus:Dev:Func 3:0:1 - Fujitsu DynamicLoM Emulex 
OCl14000-LOM
  Boot0005* ubuntu

  Note that BootOrder specifies Boot0005 as the first option, causing
  the computer to attempt to boot from the hard disk rather than PXE-
  boot (any of the other Boot options on this computer). This causes
  at least two problems:

  * If Secure Boot is enabled, the computer may fail to boot, because the 
"ubuntu" entry points
to grubx64.efi, not shimx64.efi. (If the computer silently falls past the 
SB failure, it
will boot; but on the Fujitsu system I tested, it displays a console 
message about the SB
failure that requires human interaction, and therefore hangs indefinitely 
in a MAAS
environment.)
  * Re-deploying the node is impossible without manual intervention, because 
the system
will try to boot from the hard disk rather than PXE-booting under MAAS 
control.

  This problem has occurred on a server running MAAS
  2.0.0+bzr5189-0ubuntu1~16.04.1 (see below for detailed version
  information). Another server running MAAS
  2.1.0+bzr5480-0ubuntu1~16.04.1 does NOT have the problem. I suspect
  the problem is with the ephemeral images, though, not the MAAS version
  per se. I'm attaching the log files from the MAAS 2.0 system as
  requested.

  I've tested this with three systems: A Fujitsu RX2530M2R2, a Fujitsu
  RX2540M2R1, and an IBM x3650 M2. (The MAAS 2.1 server controlled an
  Intel NUC DC53427HYE.) The Fujitsu systems are new (to us), but the
  IBM has been in our possession for an extended period and has never
  exhibited this problem (except perhaps when bug #1311827 was current),
  so I'm confident this is a regression.

  All tests involved deployments of Ubuntu 16.04. Most used the
  certification custom images (for 16.04.1), but I've verified the
  results on one system deploying the standard MAAS image for xenial.

  MAAS version information:

  rodsmith@weavile:~$ dpkg -l '*maas*'|cat
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ NameVersion
Architecture Description
  
+++-===-==--==
  ii  maas2.0.0+bzr5189-0ubuntu1~16.04.1 all
  "Metal as a Service" is a physical cloud and IPAM
  ii  maas-cert-server0.2.25-0~64~ubuntu16.04.1  all
  Ubuntu certification support files for MAAS server
  ii  maas-cli2.0.0+bzr5189-0ubuntu1~16.04.1 all
  MAAS client and command-line interface
  un  maas-cluster-controller   
  (no description available)
  ii  maas-common 

[Group.of.nepali.translators] [Bug 1384955] Re: support compressed kernels on arm64

[dann frazier]

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Also affects: linux-hwe-edge (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: linux (Ubuntu Xenial)

** Changed in: linux-hwe-edge (Ubuntu Xenial)
 Assignee: (unassigned) => Andy Whitcroft (apw)

** Changed in: flash-kernel (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: flash-kernel (Ubuntu Xenial)
   Status: Triaged => In Progress

** Description changed:

- When building an upstream kernel using "make deb-pkg" and not any of the
- Ubuntu-specific kernel build methods (such as debian/rules binary-
- headers binary-generic), the resulting linux-image deb package includes
- a gzip-compressed kernel image (copied from Image.gz, not Image). When
- such a deb package is installed on an arm64 system (such as McDivitt)
- and flash-kernel is run, it always calls "mkimage" with "-C none", which
- results in a uImage that can't boot.
+ [Impact]
+ Ubuntu kernels >= hwe-y (4.8) will no longer boot on xgene/uboot systems. The 
image size appears to have outgrown the defined firmware region, and u-boot 
will error out with a checksum mismatch error. A solution for this is to start 
shipping a compressed kernel (Image.gz target). flash-kernel needs updating to 
detect a compressed kernel and set the appropriate uImage compression flag. 
Similarly, d-i needs updating because it does it's own uImage generation.
  
- The attached patch adds a check to the mkimage_kernel() function in
- /usr/share/flash-kernel/functions to determine whether the kernel image
- is gzip-compressed or not, and calls "mkimage" with the appropriate "-C
- gzip" or "-C none" option. I have tested this patch on McDivitt, with
- both standard Ubuntu 3.13.0-37 and upstream 3.18-rc1 kernels, and it
- works for me.
+ [Test Case]
+ Boot an hwe-y kernel on an xgene/uboot system (APM Mustang, HP ProLiant m400).
+ 
+ [Regression Risk]
+ The necessary code is in place and in-use for yakkety, and no issues have 
been discovered there. The SRU involves clean cherry-picks of that code for d-i 
& f-k. The kernel side needs to be modified to pull in the correct version of 
flash-kernel for xenial.

** Changed in: debian-installer (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: debian-installer (Ubuntu Xenial)
   Status: Triaged => Fix Committed

** Changed in: debian-installer (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: debian-installer (Ubuntu)
   Importance: Undecided => High

** Changed in: flash-kernel (Ubuntu)
   Importance: Undecided => High

** Changed in: flash-kernel (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: flash-kernel (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

** Changed in: debian-installer (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

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

** Changed in: linux-hwe-edge (Ubuntu Xenial)
   Importance: Undecided => High

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

Title:
  support compressed kernels on arm64

Status in debian-installer package in Ubuntu:
  Fix Released
Status in flash-kernel package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in linux-hwe-edge package in Ubuntu:
  New
Status in debian-installer source package in Xenial:
  Fix Committed
Status in flash-kernel source package in Xenial:
  In Progress
Status in linux-hwe-edge source package in Xenial:
  New
Status in flash-kernel package in Debian:
  New

Bug description:
  [Impact]
  Ubuntu kernels >= hwe-y (4.8) will no longer boot on xgene/uboot systems. The 
image size appears to have outgrown the defined firmware region, and u-boot 
will error out with a checksum mismatch error. A solution for this is to start 
shipping a compressed kernel (Image.gz target). flash-kernel needs updating to 
detect a compressed kernel and set the appropriate uImage compression flag. 
Similarly, d-i needs updating because it does it's own uImage generation.

  [Test Case]
  Boot an hwe-y kernel on an xgene/uboot system (APM Mustang, HP ProLiant m400).

  [Regression Risk]
  The necessary code is in place and in-use for yakkety, and no issues have 
been discovered there. The SRU involves clean cherry-picks of that code for d-i 
& f-k. The kernel side needs to be modified to pull in the correct version of 
flash-kernel for xenial.

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

___
Mailing list: https://launchpa

[Group.of.nepali.translators] [Bug 1640519] Re: arm64 xenial maas images don't include u-boot-tools package

[dann frazier]

** Also affects: curtin (Ubuntu Yakkety)
   Importance: Undecided
   Status: New

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

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

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

Title:
  arm64 xenial maas images don't include u-boot-tools package

Status in curtin:
  Fix Released
Status in maas-images:
  Fix Released
Status in curtin package in Ubuntu:
  Fix Released
Status in curtin source package in Xenial:
  New
Status in curtin source package in Yakkety:
  New

Bug description:
  arm64 fails to install because it cannot install grub.

  Related bugs:
   * bug 1337538:  arm64/xgene-uboot lacks u-boot-tools
   * bug 1160360: flash-kernel failed in an armhf lxc container on ARM: 
/usr/sbin/flash-kernel: 214: /usr/sbin/flash-kernel: mkimage: not found

To manage notifications about this bug go to:
https://bugs.launchpad.net/curtin/+bug/1640519/+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 1649213] Re: Support rootfs on xhci-plat-hcd attached storage

[dann frazier]

** No longer affects: linux (Ubuntu Zesty)

** No longer affects: linux (Ubuntu Xenial)

** No longer affects: linux (Ubuntu Trusty)

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

Title:
  Support rootfs on xhci-plat-hcd attached storage

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Trusty:
  New
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Zesty:
  Invalid

Bug description:
  [Impact]
  If you install Ubuntu onto USB storage behind a Platform USB host controller, 
it will not be able to boot because the generated initramfs will not include 
the host controller driver.

  [Test Case]
  Install to a USB stick attached to platform USB controller and reboot. 
Booting will fail because it will be unable to find the root file system.

  [Regression Risk]
  Driver is only loaded when system requires xhci-plat-hcd, minimizing the 
impact to all other systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1649213/+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 1649213] Re: Support rootfs on xhci-plat-hcd attached storage

[dann frazier]

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

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

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

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

** Also affects: initramfs-tools (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Zesty)
   Importance: Undecided
   Status: Incomplete

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

Title:
  Support rootfs on xhci-plat-hcd attached storage

Status in initramfs-tools package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete
Status in initramfs-tools source package in Trusty:
  New
Status in linux source package in Trusty:
  New
Status in initramfs-tools source package in Xenial:
  New
Status in linux source package in Xenial:
  New
Status in initramfs-tools source package in Zesty:
  New
Status in linux source package in Zesty:
  Incomplete

Bug description:
  [Impact]
  If you install Ubuntu onto USB storage behind a Platform USB host controller, 
it will not be able to boot because the generated initramfs will not include 
the host controller driver.

  [Test Case]
  Install to a USB stick attached to platform USB controller and reboot. 
Booting will fail because it will be unable to find the root file system.

  [Regression Risk]
  Driver is only loaded when system requires xhci-plat-hcd, minimizing the 
impact to all other systems.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1649213/+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 1643084] [NEW] [REGRESSION] kill segfaults w/ single, negative PID

[dann frazier]

Public bug reported:

[Impact]
The kill binary will segfault when called w/ a single, negative PID. This 
breaks a use case where you maybe sending the default signal (SIGTERM) to all 
processes (-1) or all processes in a process group (-<PGID). This is regression 
introduced via an SRU to fix LP: #1637026.

[Test Case]
$ /bin/kill -9
Segmentation fault (core dumped)

[Regression Risk]
This fix will now make our optparsing almost identical to current yakkety, for 
which I see no obvious regressions filed.

** Affects: procps (Ubuntu)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: Fix Released

** Affects: procps (Ubuntu Xenial)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

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

** Changed in: procps (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

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

Title:
  [REGRESSION] kill segfaults w/ single, negative PID

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

Bug description:
  [Impact]
  The kill binary will segfault when called w/ a single, negative PID. This 
breaks a use case where you maybe sending the default signal (SIGTERM) to all 
processes (-1) or all processes in a process group (-<PGID). This is regression 
introduced via an SRU to fix LP: #1637026.

  [Test Case]
  $ /bin/kill -9
  Segmentation fault (core dumped)

  [Regression Risk]
  This fix will now make our optparsing almost identical to current yakkety, 
for which I see no obvious regressions filed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1643084/+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 1637300] Re: procps upgrades fail in a LXD container

[dann frazier]

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

** Also affects: procps (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827423
   Importance: Unknown
   Status: Unknown

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

Title:
  procps upgrades fail in a LXD container

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  In Progress
Status in procps package in Debian:
  Unknown

Bug description:
  [Impact]
  procps cannot be upgraded - or even reinstalled - in an LXD container. This 
means we cannot deliver updates (like the pending fix for LP: #1637026 in 
xenial-proposed) w/o putting container users in a bad state that requires a 
container restart to resolve.

  [Test Case]
  $ lxc launch ubuntu:xenial procpstest
  Creating procpstest
  Starting procpstest
  $ lxc exec procpstest -- /bin/bash
  root@procpstest:~# apt --reinstall install procps
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
  Need to get 209 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 procps arm64 
2:3.3.10-4ubuntu2 [209 kB]
  Fetched 209 kB in 1s (113 kB/s)  
  (Reading database ... 25398 files and directories currently installed.)
  Preparing to unpack .../procps_2%3a3.3.10-4ubuntu2_arm64.deb ...
  Unpacking procps (2:3.3.10-4ubuntu2) over (2:3.3.10-4ubuntu2) ...
  Processing triggers for man-db (2.7.5-1) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for systemd (229-4ubuntu11) ...
  Setting up procps (2:3.3.10-4ubuntu2) ...
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  Job for systemd-sysctl.service failed because the control process exited with 
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe" 
for details.
  invoke-rc.d: initscript procps, action "start" failed.
  dpkg: error processing package procps (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   procps
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  root@procpstest:~#

  [Regression Risk]
  The proposed fix is to disable invoking the procps initscript on 
install/upgrade. This fix is already in yakkety, and I didn't find any bugs 
related to it in LP.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1637300/+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 1637300] [NEW] procps upgrades fail in a LXD container

[dann frazier]

Public bug reported:

[Impact]
procps cannot be upgraded - or even reinstalled - in an LXD container. This 
means we cannot deliver updates (like the pending fix for LP: #1637026 in 
xenial-proposed) w/o putting container users in a bad state that requires a 
container restart to resolve.

[Test Case]
$ lxc launch ubuntu:xenial procpstest
Creating procpstest
Starting procpstest
$ lxc exec procpstest -- /bin/bash
root@procpstest:~# apt --reinstall install procps
Reading package lists... Done
Building dependency tree   
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 209 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 procps arm64 
2:3.3.10-4ubuntu2 [209 kB]
Fetched 209 kB in 1s (113 kB/s)  
(Reading database ... 25398 files and directories currently installed.)
Preparing to unpack .../procps_2%3a3.3.10-4ubuntu2_arm64.deb ...
Unpacking procps (2:3.3.10-4ubuntu2) over (2:3.3.10-4ubuntu2) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for ureadahead (0.100.0-19) ...
Processing triggers for systemd (229-4ubuntu11) ...
Setting up procps (2:3.3.10-4ubuntu2) ...
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
Job for systemd-sysctl.service failed because the control process exited with 
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe" 
for details.
invoke-rc.d: initscript procps, action "start" failed.
dpkg: error processing package procps (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 procps
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@procpstest:~#

[Regression Risk]
The proposed fix is to disable invoking the procps initscript on 
install/upgrade. This fix is already in yakkety, and I didn't find any bugs 
related to it in LP.

** Affects: procps (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: procps (Ubuntu Xenial)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

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

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

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

** Changed in: procps (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

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

Title:
  procps upgrades fail in a LXD container

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

Bug description:
  [Impact]
  procps cannot be upgraded - or even reinstalled - in an LXD container. This 
means we cannot deliver updates (like the pending fix for LP: #1637026 in 
xenial-proposed) w/o putting container users in a bad state that requires a 
container restart to resolve.

  [Test Case]
  $ lxc launch ubuntu:xenial procpstest
  Creating procpstest
  Starting procpstest
  $ lxc exec procpstest -- /bin/bash
  root@procpstest:~# apt --reinstall install procps
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
  Need to get 209 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial/main arm64 procps arm64 
2:3.3.10-4ubuntu2 [209 kB]
  Fetched 209 kB in 1s (113 kB/s)  
  (Reading database ... 25398 files and directories currently installed.)
  Preparing to unpack .../procps_2%3a3.3.10-4ubuntu2_arm64.deb ...
  Unpacking procps (2:3.3.10-4ubuntu2) over (2:3.3.10-4ubuntu2) ...
  Processing triggers for man-db (2.7.5-1) ...
  Processing triggers for ureadahead (0.100.0-19) ...
  Processing triggers for systemd (229-4ubuntu11) ...
  Setting up procps (2:3.3.10-4ubuntu2) ...
  update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
  Job for systemd-sysctl.service failed because the control process exited with 
error code. See "systemctl status systemd-sysctl.service" and "journalctl -xe" 
for details.
  invoke-rc.d: initscript procps, action "start" failed.
  dpkg: error processing package procps (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   procps
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  root@procpstest:~#

  [Regression Risk]
  T

[Group.of.nepali.translators] [Bug 1637026] [NEW] kill incorrectly parses negative PIDs

[dann frazier]

Public bug reported:

[Impact]
When kill is called with a negative argument, incorrect parsing can lead it to 
call sys_kill(-1), thus sending a signal to all permitted processes on the 
system. A couple of users have hit this while deploying Hadoop, which seems to 
tickle this - basically killing everything on the system.

[Test Case]
Though I don't know what Hadoop is calling, here's a couple of ways to trigger 
this:

One possibility is if kill were called w/ a numeric signal that
happened to start with a '1' and while omitting the required 
argument:

kill -12

Another would be to specify a numeric signal (that again happened to
start with a 1) multiple times:
kill -13 -13 12345

[Regression Risk]
This is a backport from upstream that is already available in 16.10, with no 
known regressions.

** Affects: procps (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: procps (Ubuntu Xenial)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

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

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

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

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

** Changed in: procps (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  kill incorrectly parses negative PIDs

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

Bug description:
  [Impact]
  When kill is called with a negative argument, incorrect parsing can lead it 
to call sys_kill(-1), thus sending a signal to all permitted processes on the 
system. A couple of users have hit this while deploying Hadoop, which seems to 
tickle this - basically killing everything on the system.

  [Test Case]
  Though I don't know what Hadoop is calling, here's a couple of ways to 
trigger this:

  One possibility is if kill were called w/ a numeric signal that
  happened to start with a '1' and while omitting the required 
  argument:

  kill -12

  Another would be to specify a numeric signal (that again happened to
  start with a 1) multiple times:
  kill -13 -13 12345

  [Regression Risk]
  This is a backport from upstream that is already available in 16.10, with no 
known regressions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1637026/+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 1630038] Re: thunder nic: avoid link delays due to RX_PACKET_DIS

[dann frazier]

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

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

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  thunder nic: avoid link delays due to RX_PACKET_DIS

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

Bug description:
  [Impact]
  Link establishment is delayed during initialization, possibly resulting in 
remote fault conditions that may cause the interface to fail to come up.

  [Test Case]
  Put the system in a reboot loop and watch for a remote fault condition, or a 
failure to bring up the link that can only be resolved by reloading the module.

  [Regression Risk]
  Patch is to a specific driver that is only used on Cavium ThunderX systems. 
The patch is upstream, so will have upstream support for regressions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630038/+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 1568086] Re: PPC64/hugepages is not supported by nova/libvirt driver.

[dann frazier]

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

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

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

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

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

Title:
  PPC64/hugepages is not supported by nova/libvirt driver.

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

Bug description:
  Currently nova on ppc64el does not enable huge pages and we would like
  to do so.

  I sent a patch to enable it upstream and I am waiting on reviews:

  https://review.openstack.org/#/c/303564/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1568086/+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 1623871] Re: Nova hugepage support does not include aarch64

[dann frazier]

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

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

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

Title:
  Nova hugepage support does not include aarch64

Status in OpenStack Compute (nova):
  In Progress
Status in nova package in Ubuntu:
  New
Status in nova source package in Xenial:
  New

Bug description:
  Although aarch64 supports spawning a vm with hugepages, in nova code,
  the libvirt driver considers only x86_64 and I686. Both for NUMA and
  Hugepage support, AARCH64 needs to be added. Due to this bug, vm can
  not be launched with hugepage using OpenStack on aarch64 servers.

  Steps to reproduce:
  On an openstack environment running on aarch64:
  1. Configure compute to use hugepages.
  2. Set mem_page_size="2048" for a flavor
  3. Launch a VM using the above flavor. 

  Expected result:
  VM should be launched with hugepages and the libvirt xml should have 



  



  Actual result:
  VM is launched without hugepages.

  There are no error logs in nova-scheduler.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1623871/+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 1627926] [NEW] Enable NUMA support in arm64 builds

[dann frazier]

Public bug reported:

[Impact]
The host capabilities for arm64 NUMA systems are incomplete - one effect of 
which is that nova is unable to make use of hugetlbfs for backing VMs with huge 
pages.

[Test Case]
Examine the output of 'virsh capabilities' on an arm64 NUMA system. The 
topology section for all but the first node are currently inaccurate and lacks 
page size entries. Sample output from a 2-node NUMA system is attached, both 
pre and post fix.

[Regression Risk]
Risk is minimized by the fact that this change is just enabling the same code 
for arm64 that is already enabled for the other NUMA-enabled Ubuntu 
architectures.

** Affects: libvirt (Ubuntu)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: Confirmed

** Affects: libvirt (Ubuntu Xenial)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: Confirmed

** Affects: libvirt (Debian)
 Importance: Unknown
 Status: Unknown

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

** Also affects: libvirt (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838494
   Importance: Unknown
   Status: Unknown

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

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

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

** Changed in: libvirt (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  Enable NUMA support in arm64 builds

Status in libvirt package in Ubuntu:
  Confirmed
Status in libvirt source package in Xenial:
  Confirmed
Status in libvirt package in Debian:
  Unknown

Bug description:
  [Impact]
  The host capabilities for arm64 NUMA systems are incomplete - one effect of 
which is that nova is unable to make use of hugetlbfs for backing VMs with huge 
pages.

  [Test Case]
  Examine the output of 'virsh capabilities' on an arm64 NUMA system. The 
topology section for all but the first node are currently inaccurate and lacks 
page size entries. Sample output from a 2-node NUMA system is attached, both 
pre and post fix.

  [Regression Risk]
  Risk is minimized by the fact that this change is just enabling the same code 
for arm64 that is already enabled for the other NUMA-enabled Ubuntu 
architectures.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1627926/+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 1624569] [NEW] thunder: chip errata w/ multiple CQEs for a TSO packet

[dann frazier]

Public bug reported:

[Impact]
With small segment sizes, it is possible for the driver to free an SKB before 
transmitting it, potentially resulting in a crash.

[Test Case]
The test case for this is to use a small MTU (200) and mount an NFS exported 
directory. Create several (~4) 1M files w/ dd, then copy them locally. However, 
I have not been able to trigger the crash myself.

[Regression Risk]
Fix is upstream, so regressions will have upstream support. Fix is limited to a 
driver that is only applicable to the Cavium Thunder-X SoC, so risk is 
negligible to other platforms.

** Affects: linux (Ubuntu)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

** Affects: linux (Ubuntu Xenial)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

** Summary changed:

- thunder: 
+ thunder: chip errata w/ multiple CQEs for a TSO packet

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

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

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  thunder: chip errata w/ multiple CQEs for a TSO packet

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

Bug description:
  [Impact]
  With small segment sizes, it is possible for the driver to free an SKB before 
transmitting it, potentially resulting in a crash.

  [Test Case]
  The test case for this is to use a small MTU (200) and mount an NFS exported 
directory. Create several (~4) 1M files w/ dd, then copy them locally. However, 
I have not been able to trigger the crash myself.

  [Regression Risk]
  Fix is upstream, so regressions will have upstream support. Fix is limited to 
a driver that is only applicable to the Cavium Thunder-X SoC, so risk is 
negligible to other platforms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1624569/+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 1623627] [NEW] thunder: faulty TSO padding

[dann frazier]

Public bug reported:

[Impact]
Certain packet sizes will trigger spurious TCP retransmissions on Cavium 
Thunder-X systems when TSO is enabled (the default). This can result in excess 
traffic and additional latency.

[Test Case]
Connect 2 systems to a 10G switch:
 - 1 ThunderX node (the client)
 - 1 "other" node - doesn't have to be ThunderX (the server)
On the server, run the "receiver" command from the attached tcptest tarball:
  $ ./receiver
Also on the server, run tcpdump to capture the traffic:
  $ sudo tcpdump -i  -w tcpdump.out
On the client, run the "sender" command from the tcptest tarball, with a 1461 
packet size:
  $ ./sender  1461 1461
Kill the tcpdump process, and open it in wireshark.

On failure, you'll see several "[TCP Spurious Retransmission]" packets -
on success you should see none.

[Regression Risk]
Fix is upstream, so regressions will have upstream support. Fix is limited to a 
driver that is only applicable to the Cavium Thunder-X SoC, so risk is 
negligible to other platforms.

** Affects: linux (Ubuntu)
 Importance: High
 Status: Fix Committed

** Affects: linux (Ubuntu Xenial)
     Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

** Attachment added: "tcptest.tar"
   
https://bugs.launchpad.net/bugs/1623627/+attachment/4741130/+files/tcptest.tar

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

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

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

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => dann frazier (dannf)

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

Title:
  thunder: faulty TSO padding

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Xenial:
  In Progress

Bug description:
  [Impact]
  Certain packet sizes will trigger spurious TCP retransmissions on Cavium 
Thunder-X systems when TSO is enabled (the default). This can result in excess 
traffic and additional latency.

  [Test Case]
  Connect 2 systems to a 10G switch:
   - 1 ThunderX node (the client)
   - 1 "other" node - doesn't have to be ThunderX (the server)
  On the server, run the "receiver" command from the attached tcptest tarball:
$ ./receiver
  Also on the server, run tcpdump to capture the traffic:
$ sudo tcpdump -i  -w tcpdump.out
  On the client, run the "sender" command from the tcptest tarball, with a 1461 
packet size:
$ ./sender  1461 1461
  Kill the tcpdump process, and open it in wireshark.

  On failure, you'll see several "[TCP Spurious Retransmission]" packets
  - on success you should see none.

  [Regression Risk]
  Fix is upstream, so regressions will have upstream support. Fix is limited to 
a driver that is only applicable to the Cavium Thunder-X SoC, so risk is 
negligible to other platforms.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1623627/+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 1623187] [NEW] initramfs includes qle driver, but not firmware

[dann frazier]

Public bug reported:

[Impact]
The qle driver for the Qlogic FastLinQ QL45000 Series 40GbE Adapter doesn't 
find devices. This is because the driver, by default, is loaded by the 
initramfs, and the initramfs does not contain the required firmware blob. The 
root cause is that the driver does not use implement the MODULE_FIRMWARE 
macro(), which is required for initramfs-tools to find and pre-load the 
required firmware.

[Test Case]
Install a system with a Qlogic FastLinQ QL45000 Series 40GbE Adapter. On 
failure, dmesg will show:

[ 5.934190] qede 0009:90:00.0: Direct firmware load for 
qed/qed_init_values_zipped-8.4.2.0.bin failed with error -2
[ 5.934208] [qed_slowpath_start:741()]Failed to find fw file - 
/lib/firmware/qed/qed_init_values_zipped-8.4.2.0.bin
[ 5.934280] qede: probe of 0009:90:00.0 failed with error -2
[ 5.934353] qede 0009:90:00.1: enabling device ( -> 0002)
[ 5.935115] qede 0009:90:00.1: Direct firmware load for 
qed/qed_init_values_zipped-8.4.2.0.bin failed with error -2
[ 5.935139] [qed_slowpath_start:741()]Failed to find fw file - 
/lib/firmware/qed/qed_init_values_zipped-8.4.2.0.bin
[ 5.935236] qede: probe of 0009:90:00.1 failed with error -2

[Regression Risk]
Fix is upstream and the macro usage is well defined.

** Affects: linux (Ubuntu)
 Importance: High
 Assignee: dann frazier (dannf)
 Status: In Progress

** Affects: linux (Ubuntu Xenial)
 Importance: Undecided
 Status: In Progress

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

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

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

Title:
  initramfs includes qle driver, but not firmware

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

Bug description:
  [Impact]
  The qle driver for the Qlogic FastLinQ QL45000 Series 40GbE Adapter doesn't 
find devices. This is because the driver, by default, is loaded by the 
initramfs, and the initramfs does not contain the required firmware blob. The 
root cause is that the driver does not use implement the MODULE_FIRMWARE 
macro(), which is required for initramfs-tools to find and pre-load the 
required firmware.

  [Test Case]
  Install a system with a Qlogic FastLinQ QL45000 Series 40GbE Adapter. On 
failure, dmesg will show:

  [ 5.934190] qede 0009:90:00.0: Direct firmware load for 
qed/qed_init_values_zipped-8.4.2.0.bin failed with error -2
  [ 5.934208] [qed_slowpath_start:741()]Failed to find fw file - 
/lib/firmware/qed/qed_init_values_zipped-8.4.2.0.bin
  [ 5.934280] qede: probe of 0009:90:00.0 failed with error -2
  [ 5.934353] qede 0009:90:00.1: enabling device ( -> 0002)
  [ 5.935115] qede 0009:90:00.1: Direct firmware load for 
qed/qed_init_values_zipped-8.4.2.0.bin failed with error -2
  [ 5.935139] [qed_slowpath_start:741()]Failed to find fw file - 
/lib/firmware/qed/qed_init_values_zipped-8.4.2.0.bin
  [ 5.935236] qede: probe of 0009:90:00.1 failed with error -2

  [Regression Risk]
  Fix is upstream and the macro usage is well defined.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1623187/+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 1384955] Re: support compressed kernels on arm64

[dann frazier]

** Summary changed:

- flash-kernel should support compressed kernels
+ support compressed kernels on arm64

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

** Also affects: debian-installer (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: debian-installer (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: flash-kernel (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Changed in: debian-installer (Ubuntu)
   Status: New => Fix Released

** Changed in: flash-kernel (Ubuntu Xenial)
   Status: New => Confirmed

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

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => dann frazier (dannf)

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

** Changed in: flash-kernel (Ubuntu Xenial)
   Status: Confirmed => Triaged

** Changed in: debian-installer (Ubuntu Xenial)
   Status: New => Triaged

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

Title:
  support compressed kernels on arm64

Status in debian-installer package in Ubuntu:
  Fix Released
Status in flash-kernel package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  In Progress
Status in debian-installer source package in Xenial:
  Triaged
Status in flash-kernel source package in Xenial:
  Triaged
Status in linux source package in Xenial:
  Triaged
Status in flash-kernel package in Debian:
  New

Bug description:
  When building an upstream kernel using "make deb-pkg" and not any of
  the Ubuntu-specific kernel build methods (such as debian/rules binary-
  headers binary-generic), the resulting linux-image deb package
  includes a gzip-compressed kernel image (copied from Image.gz, not
  Image). When such a deb package is installed on an arm64 system (such
  as McDivitt) and flash-kernel is run, it always calls "mkimage" with
  "-C none", which results in a uImage that can't boot.

  The attached patch adds a check to the mkimage_kernel() function in
  /usr/share/flash-kernel/functions to determine whether the kernel
  image is gzip-compressed or not, and calls "mkimage" with the
  appropriate "-C gzip" or "-C none" option. I have tested this patch on
  McDivitt, with both standard Ubuntu 3.13.0-37 and upstream 3.18-rc1
  kernels, and it works for me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1384955/+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 1608948] [NEW] support hw watchpoints/breakpoints on ARMv8.{1, 2}

[dann frazier]

Public bug reported:

[Impact]
gdb reports no hw watchpoint/breakpoint support on ARMv8.1

[Test Case]
Test.c:
int main(void)
{
  int a;
  a = 0;
  a++;
  return a!=1;
}
- CUT 
gcc -g test.c -o testprog
apinski@apinski-ss1:~/binutils-gdb$ ./tools/bin/gdb -q a.out
Reading symbols from a.out...done.
(gdb) start
Temporary breakpoint 1 at 0x40050c: file t.c, line 4.
Starting program: /home/apinski/binutils-gdb/a.out

Temporary breakpoint 1, main () at t.c:4
4 a = 0;
(gdb) hb 5
Hardware assisted breakpoint 2 at 0x400510: file t.c, line 5.
(gdb) c
Continuing.

Breakpoint 2, main () at t.c:5
5 a++;
(gdb)

This fails on ARMv8.1 platforms w/o the patch.

[Regression Risk]
Patch is a clean cherry pick from upstream that just adds code to detect 8.1 & 
8.2 chip debug types.

** Affects: gdb (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: gdb (Ubuntu Xenial)
 Importance: Undecided
 Status: New

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

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

Title:
  support hw watchpoints/breakpoints on ARMv8.{1,2}

Status in gdb package in Ubuntu:
  New
Status in gdb source package in Xenial:
  New

Bug description:
  [Impact]
  gdb reports no hw watchpoint/breakpoint support on ARMv8.1

  [Test Case]
  Test.c:
  int main(void)
  {
int a;
a = 0;
a++;
return a!=1;
  }
  - CUT 
  gcc -g test.c -o testprog
  apinski@apinski-ss1:~/binutils-gdb$ ./tools/bin/gdb -q a.out
  Reading symbols from a.out...done.
  (gdb) start
  Temporary breakpoint 1 at 0x40050c: file t.c, line 4.
  Starting program: /home/apinski/binutils-gdb/a.out

  Temporary breakpoint 1, main () at t.c:4
  4 a = 0;
  (gdb) hb 5
  Hardware assisted breakpoint 2 at 0x400510: file t.c, line 5.
  (gdb) c
  Continuing.

  Breakpoint 2, main () at t.c:5
  5 a++;
  (gdb)

  This fails on ARMv8.1 platforms w/o the patch.

  [Regression Risk]
  Patch is a clean cherry pick from upstream that just adds code to detect 8.1 
& 8.2 chip debug types.

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