Public bug reported:
This bug is for tracking the 3.2.0-109.150 upload package. This bug will
contain status and testing results related to that upload.
For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
** Affects:
*** This bug is a duplicate of bug 1612732 ***
https://bugs.launchpad.net/bugs/1612732
** This bug has been marked a duplicate of bug 1612732
linux: 3.2.0-109.150 -proposed tracker
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
*** This bug is a duplicate of bug 1612715 ***
https://bugs.launchpad.net/bugs/1612715
** This bug has been marked a duplicate of bug 1612715
linux: 3.13.0-95.142 -proposed tracker
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
*** This bug is a duplicate of bug 1612718 ***
https://bugs.launchpad.net/bugs/1612718
** This bug has been marked a duplicate of bug 1612718
linux-lts-trusty: 3.13.0-95.142~precise1 -proposed tracker
--
You received this bug notification because you are a member of Kernel
Packages,
** Summary changed:
- linux-ti-omap4: -proposed tracker
+ linux-ti-omap4: 3.2.0-1487.114 -proposed tracker
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-ti-omap4 in Ubuntu.
https://bugs.launchpad.net/bugs/1612738
Title:
That sounds more like, despite dmraid using ddf in the name, the BIOS
uses some different format which mdadm does not recognize. So that would
mean you cannot switch from dmraid to mdadm.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
** Attachment added: "libdmraid1.0.0.rc16_1.0.0.rc16-4.2ubuntu3_amd64.deb"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1611277/+attachment/4718232/+files/libdmraid1.0.0.rc16_1.0.0.rc16-4.2ubuntu3_amd64.deb
--
You received this bug notification because you are a member of Kernel
I got some time and did a rebuild of dmraid in Xenial, which completed.
So I am not really understanding why running dmraid in 16.04 does claim
to find nothing while it does succeed in 14.04. I am attaching the two
debs here just in case an actual rebuild produces something different
than before.
ged in: linux (Ubuntu Xenial)
Assignee: Tim Gardner (timg-tpi) => Stefan Bader (smb)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1568729
Title:
divide error: [#
While I have not found out where exactly things go wrong, I could
confirm that this is related to ppc64el builds using a 64k page size. I
build a test kernel with 4k page size and installed it inside the VM.
With that bcache-super-show will will reflect the correct status after
activation and also
So I believe the problem is the hackish way to acquire buffer pages for
internal biovec structures. This is done by taking a reference on the page
which is returned by __bread() in read_super(). With 4k pages and reading 4k
from sector 1 bh->b_data will always be the start of a page.
But with
This should be fixed in Xenial/Yakkety by now. Unfortunately as part of
the backport for bug #1567602 (fixed in 4.4.0-31.50 and later).
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which
Not sure. That talks about the location of the super block. It does not
seem to change the size. But then it could be that this papers over
things if the offset of data in the page returned by __bread depends on
the relative location of a disk section within a page size area. So
reading block one
Recreated on a test system. The fact that the superblock gets written to
is expected. Though for ppc64el this seems to go wrong at early stages.
I am comparing the results on a ppc64el vm and a x86 vm. After setting
up bcache and attaching the cache to the backing dev, the output of
Or better it should be 4.6+ at some point. I realized it still is a copy
of Xenial (4.4). But I would not worry about the fix there.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567602
Set main task back to fix released as that is then devel release which
is 4.6+ and that is claimed to work.
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
Added a new attempt. This time the pick-list is rather excessive.
Unfortunately the more likely changes come later. So while there might
be some patches which probably can be dropped, I fear the overall set
still will be big. (Download again:
http://people.canonical.com/~smb/lp1567602/)
5da8bf5
Thanks Thorsten. So I have to go back and see what else might be
relevant. Just for reference the one patch I used (forgot to mention
this earlier) was the one below:
Author: Hannes Reinecke
Date: Tue Dec 1 10:16:44 2015 +0100
scsi_dh_alua: Use vpd_pg83 information
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567602
Title:
FCP devices are not detected correctly
Public bug reported:
This bug is for tracking the 3.2.0-108.149 upload package. This bug will
contain status and testing results related to that upload.
For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
** Affects:
Public bug reported:
This bug is for tracking the 4.4.0-35.54 upload package. This bug will
contain status and testing results related to that upload.
For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
** Affects:
Public bug reported:
This bug is for tracking the 3.19.0-67.75 upload package. This bug will
contain status and testing results related to that upload.
For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
** Affects:
Public bug reported:
This bug is for tracking the 3.13.0-94.141 upload package. This bug will
contain status and testing results related to that upload.
For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
** Affects:
** Changed in: linux (Ubuntu Vivid)
Status: Fix Released => Fix Committed
** Changed in: linux (Ubuntu Xenial)
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Package changed: kernel-package (Ubuntu) => linux (Ubuntu)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1603449
Title:
[LTCTest][Opal][OP820] Machine crashed with Oops: Kernel
For reference, this is the one patch picked from upstream stable queue
for 4.4.
** Patch added: "sched-fair-fix-cfs_rq-avg-tracking-underflow.patch"
The whole discussion seems to be going back and forth and is rather confusing.
On one side there is the ceph discussion where Stefan Priebe indeed mentions
that he has many more patches in his tree. On the other side there is the LKML
discussion which ends in GregKH getting exactly one patch
Moving to a Xenial kernel seemed to cure some affected systems, so we
would assume it being fixed released from there.
** Changed in: linux (Ubuntu)
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
There also was some case of a different panic which looked like below:
[ 16.191583] BUG: unable to handle kernel NULL pointer dereference at
0148
[ 16.201096] IP: [] check_preempt_wakeup+0x137/0x270
[ 16.208349] PGD 0
[ 16.211201] Oops: [#1] SMP
[ 16.214877] Modules
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
precise' to 'verification-done-precise'.
If verification is not done by 5 working days
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'.
If verification is not done by 5 working days from
: Stefan Bader (smb) => (unassigned)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1602755
Title:
Tunnel offload indications not stripped from encapsulated packets,
causing performa
** Also affects: linux-meta-lts-xenial (Ubuntu)
Importance: Undecided
Status: New
** Also affects: linux-meta (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: linux-signed (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects:
** Changed in: ubuntu-fan (Ubuntu Yakkety)
Importance: Undecided => Medium
** Changed in: ubuntu-fan (Ubuntu Yakkety)
Status: New => Fix Committed
** Changed in: ubuntu-fan (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: ubuntu-fan (Ubuntu Xenial)
Status: New
** Also affects: linux (Ubuntu Trusty)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1662186
Title:
linux: 3.13.0-109.156 -proposed tracker
** Description changed:
The way docker handles networks changed when moving to newer docker
versions. Networks are now created/deleted by "docker network" commands
(similar to LXD). This needs to be handled by fanatic when doing docker
related tasks.
+
+ SRU Justification:
+
+ Impact:
Zesty is not affected as the fixup was in v4.9-rc2.
** Changed in: linux (Ubuntu)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1659654
Title:
Yakkety)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Yakkety)
Importance: Undecided => High
** Changed in: linux (Ubuntu Yakkety)
Status: New => In Progress
** Changed in: linux (Ubuntu Yakkety)
Assignee: (unassigned) => Stefan Bader (smb)
On Yakkety:
ii ubuntu-fan 0.12.0.1
ii docker.io 1.12.3-0ubuntu4~16.10.2
fanctl show
Bridge Underlay Overlay Flags
fan-250 10.1.203.53/16 250.0.0.0/8 enable dhcp
Local docker test successful and bridge still configured after
On Xenial:
ii ubuntu-fan 0.9.2
ii docker.io 1.12.3-0ubuntu4~16.04.2
fanctl show
Bridge Underlay Overlay Flags
fan-250 10.1.245.52/16 250.0.0.0/8 enable dhcp
Local docker test successful and bridge still configured after disabling
Importance: Medium
Assignee: Stefan Bader (smb)
Status: Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1656875
Title:
fanatic enable/disable docker broken with
Would we want to upload to yakkety and forward copy to zesty or upload
two versions with the same code? In the end we want to switch zesty from
0.12 to 0.13 anyway.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
** Attachment added: "dmraid_1.0.0.rc16-4.2ubuntu4_amd64.deb"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1611277/+attachment/4723889/+files/dmraid_1.0.0.rc16-4.2ubuntu4_amd64.deb
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
** Attachment added: "libdmraid1.0.0.rc16_1.0.0.rc16-4.2ubuntu4_amd64.deb"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1611277/+attachment/4723890/+files/libdmraid1.0.0.rc16_1.0.0.rc16-4.2ubuntu4_amd64.deb
--
You received this bug notification because you are a member of Kernel
Sorry, I was distracted by other things. So I will be attaching a
proposed update to dmraid and some pre-built package to test. I just
cannot promise that change will be accepted.
About converting to mdadm: That would be an option that might be more
future proof but only if you do not want to use
Those packages are compiled against 14.04 user-space and should need no
update for libdevmapper.
** Attachment added: "dmraid_1.0.0.rc16-4.2ubuntu4~14.04.1_amd64.deb"
** Attachment added:
"libdmraid1.0.0.rc16_1.0.0.rc16-4.2ubuntu4~14.04.1_amd64.deb"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1611277/+attachment/4723896/+files/libdmraid1.0.0.rc16_1.0.0.rc16-4.2ubuntu4~14.04.1_amd64.deb
--
You received this bug notification because you are a
Oh, sorry, wait a second. I think I made a mistake and compiled the
package against 16.04 user-space.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1611277
Title:
Kernel Shipped With
About your question about maximum RAID size: I cannot answer that. There
possibly are different limits on what dmraid can construct via device-
mapper (those are likely higher than 4TB). But then there might be
limits that the meta-data which the BIOS uses impose. And I have no clue
there.
--
The required change will be in the 4.4.0-36 (includes the 4.4.0-35
updates) which is currently in -proposed and waiting for verification
and regression testing to finish. If there are no problems found this is
supposed to get released by Aug-29th.
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'.
If verification is not done by 5 working days from
The partitioning support is a 4.10 change, so changes are high they did
not yet see the implications. The change might move into the right
direction but certainly should not use a hard-coded shift. The number of
minors is a define so more something like (minor / BCACHE_MINORS).
--
You received
I created a modified patch and verified that
- bcache base devices again are numbered 0,1,...
- partioning a bcache device creates the expected bcacheXpY devices
Will submit this change upstream (and for pre-stable zesty).
** Patch added: "0001-bcache-Fix-bcache-device-names.patch"
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Stefan Bader (smb)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1667078
Title:
bcache device numbers increase by
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1609415
Title:
s390/cio: fix reset of channel
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1605405
Title:
Backport cxlflash shutdown patch to
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1597974
Title:
Part of the fix was in the current update. Marking the verification done
to proceed with the current cycle. This bug needs to be reset to fix-
committed for tracking the remaining patch after it gets closed by
automatic processes.
** Tags removed: verification-needed-xenial
** Tags added:
Taking the test kernel results from comment #8 and #9 as verification.
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Looking at a test VM the problematic files seem to be present in the
read-only base but then have been at some point deleted. So when the
rename/move is attempted there are whiteout softlinks present in the
overlay.
E.g.:
/media/root-ro/var/lib/cloud/data/status.json
Adding a script which can reproduce the problem without the need of
having an active overlayfs-root. Not elegant but does the job.
** Attachment added: "test-ovlmv.sh"
https://bugs.launchpad.net/cloud-init/+bug/1618572/+attachment/4735399/+files/test-ovlmv.sh
--
You received this bug
The new Xenail/16.04 kernel should now be in updates.
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Looking further into it, this is somehow caused by changes to the nbd
module. Before 4.8 it was actually not creating any uevents on its own.
Still there were events to be seen. With 4.8 they code changed to
generate a change event, but also will delay the capacity change until
the moment the
CONFIG_FAT_DEFAULT_IOCHARSET somehow got changed to utf8 instead of
iso8859-1.
** Tags added: kernel-4.8
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1626158
Title:
image won't boot
** Tags added: kernel-4.8
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
https://bugs.launchpad.net/bugs/1626269
Title:
Ubuntu 16.10: kdump is not working in 4.8 kernel.
Status in makedumpfile package in
The commit is a legit stable fix and part of the Ubuntu 16.04 kernel since
version 4.4.0-18 (your dmesg shows you a re running 4.4.0-34). So unfortunately
not helping in your case. I extracted the relevant syslog data below. >From
that info, the two disks are connected to a Marvell controller
Somehow looks like the creation of the nbd device does not reliably
trigger the partition scanning in kernel. The following work-around
would at least here get past the problem:
--- /usr/bin/mount-image-callback 2016-09-01 22:07:51.0 +0200
+++ mount-image-callback2016-09-28
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Stefan Bader (smb)
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchp
I can recreate the issue following the steps in the initial description.
Interestingly there are some (rare) cases where things works on 4.8 as
well. There is a difference in udev messages:
Not working:
KERNEL[3512.687794] change /devices/virtual/block/loop0 (block)
KERNEL[3512.704230] change
Public bug reported:
This bug is for tracking the 4.4.0-44.64 upload package. This bug will
contain status and testing results related to that upload.
For an explanation of the tasks and the associated workflow see:
https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
** Changed in: linux (Ubuntu Xenial)
Status: Fix Committed => In Progress
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1633321
Title:
Fix alps driver for multitouch function.
** Changed in: linux (Ubuntu Xenial)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1611078
Title:
Support snaps inside of lxd containers
Status in
Marking as fixed, based on the latest comment.
** Changed in: ubuntu-fan (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to ubuntu-fan in Ubuntu.
https://bugs.launchpad.net/bugs/1599822
** Also affects: linux (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
401 - 500 of 5873 matches
Mail list logo