sco)
Status: New => Invalid
** Changed in: linux (Ubuntu Disco)
Status: New => In Progress
** Changed in: linux (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Disco)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** No longer
sco)
Status: New => Invalid
** Changed in: linux (Ubuntu Disco)
Status: New => In Progress
** Changed in: linux (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Disco)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** No longer
Hi Frank,
I have been reading up on this particular bug for the last few days now, and I
think I understand what is going on.
Firstly, the commit you requested:
commit 7987b694ade8cc465ce10fb3dceaa614f13ceaf3
Author: Trond Myklebust
Date: Wed May 29 12:49:52 2019 -0400
Subject: SUNRPC: Fix
This was released in 4.15.0-59-generic and works as intended. Marking
Fix Released. Note, this still needs to land in linux-gcp for Bionic due
to some technical reasons.
** Changed in: linux (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification
This was released in 4.15.0-59-generic and works as intended. Marking
Fix Released. Note, this still needs to land in linux-gcp for Bionic due
to some technical reasons.
** Changed in: linux (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification
** Changed in: libvirt (Ubuntu Xenial)
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1829823
Title:
libvirt-bin: during shutdown libvirt-bin is stopped
** Changed in: libvirt (Ubuntu Xenial)
Status: Fix Released => 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/1829823
Matthew Ruffell has proposed merging ~mruffell/cloud-init:lp1842562 into
cloud-init:master.
Commit message:
AWS: Add udev rule to set Instance Store device IO timeouts
AWS are wishing to implement per-device IO timeouts in their cloud, and they
require Instance Store devices to use a timeout
ation.
When the udev rule is used with unpatched kernels, nothing happens since
the sysfs entry does not exist, and no errors or the like are reported.
[Other Info]
cloud-init appears to carry azure specific udev rules, which makes me think
that cloud-init is the right place for this
e part of the kernel, the changes are small and are focused on
the 0 condition.
In case of regression, simply revert all three offending commits.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee:
e part of the kernel, the changes are small and are focused on
the 0 condition.
In case of regression, simply revert all three offending commits.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee:
I have received confirmation from AWS that the fix for this issue has been
deployed to all commercial regions.
I have tested multiple VMs over the last few days and detaching EBS volumes are
working without problems.
This issue is now resolved.
** Changed in: linux (Ubuntu)
Status:
I have received confirmation from AWS that the fix for this issue has been
deployed to all commercial regions.
I have tested multiple VMs over the last few days and detaching EBS volumes are
working without problems.
This issue is now resolved.
** Changed in: linux (Ubuntu)
Status:
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1840619
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1840619
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1840619
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1840619
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
The customer installed 4.15.0-59 from -proposed to a machine with
Mellanox Ethernet CX4LX cards, using the mlx5_core kernel module.
Checksums are now calculated correctly and the kernel spat does not
occur when the devices are brought up.
Marking this as verified.
** Tags added:
The customer installed 4.15.0-59 from -proposed to a machine with
Mellanox Ethernet CX4LX cards, using the mlx5_core kernel module.
Checksums are now calculated correctly and the kernel spat does not
occur when the devices are brought up.
Marking this as verified.
** Tags added:
decided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: Fix Committed
** Tags: sts verification-done-bionic
** Description changed:
- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs
decided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: Fix Committed
** Tags: sts verification-done-bionic
** Description changed:
- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Description changed:
- BugLi
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Description changed:
- BugLi
Public bug reported:
BugLink: https://bugs.launchpad.net/bugs/
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
Public bug reported:
BugLink: https://bugs.launchpad.net/bugs/
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
Public bug reported:
BugLink: https://bugs.launchpad.net/bugs/
[Impact]
In environments which have CHECKSUM iptables rules set, the following
kernel call trace will be created when a GSO skb is processed by the
CHECKSUM target:
WARNING: CPU: 34 PID: 806048 at
Hello @johannes-wuerbach
Thanks for the suggestion. I had a look at the patch you suggested:
commit 2181e455612a8db2761eabbf126640552a451e96
Author: Anton Eidelman
Date: Thu Jun 20 08:48:10 2019 +0200
subject: nvme: fix possible io failures when removing multipathed ns
The patch was
Hello @johannes-wuerbach
Thanks for the suggestion. I had a look at the patch you suggested:
commit 2181e455612a8db2761eabbf126640552a451e96
Author: Anton Eidelman
Date: Thu Jun 20 08:48:10 2019 +0200
subject: nvme: fix possible io failures when removing multipathed ns
The patch was
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838555
Title:
nvme-cli 1.5 in Bionic does not support Micron NVME drives
To manage notifications about this bug go to:
I have submitted the patch upstream to dri-devel and CC'd the hibmc
maintainers.
We will see where the discussion goes.
https://lists.freedesktop.org/archives/dri-devel/2019-August/231284.html
https://lists.freedesktop.org/archives/dri-devel/2019-August/231285.html
--
You received this bug
I have submitted the patch upstream to dri-devel and CC'd the hibmc
maintainers.
We will see where the discussion goes.
https://lists.freedesktop.org/archives/dri-devel/2019-August/231284.html
https://lists.freedesktop.org/archives/dri-devel/2019-August/231285.html
--
You received this bug
command line to use the d-i server installer or any
graphical sessions.
Make CONFIG_DRM_HISI_HIBMC firmly depend on ARM64 to ensure it is not
built for other architectures.
Signed-off-by: Matthew Ruffell
---
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion
sked us to remove hibmc_drm from all architectures except arm64,
and this aligns with advice from Hisilicon.
Hibmc maintainers, can you please review the status of hibmc_drm on amd64 and
confirm that these issues exist, and consider merging the patch to update
Kconfig to set CONFIG_DRM_HISI_HIBMC arm64
I enabled bionic-proposed and installed ibus, ibus-gtk, ibus-gtk3
versions 1.5.17-3ubuntu5.
I ran the test in a bionic VM which had VMware Horizon Agent for Linux
installed, version 7.9.0-13916467.
Running firefox with no environment variables caused long input delays
and small lockups with the
I enabled bionic-proposed and installed ibus, ibus-gtk, ibus-gtk3
versions 1.5.17-3ubuntu5.
I ran the test in a bionic VM which had VMware Horizon Agent for Linux
installed, version 7.9.0-13916467.
Running firefox with no environment variables caused long input delays
and small lockups with the
I enabled bionic-proposed and installed ibus, ibus-gtk, ibus-gtk3
versions 1.5.17-3ubuntu5.
I ran the test in a bionic VM which had VMware Horizon Agent for Linux
installed, version 7.9.0-13916467.
Running firefox with no environment variables caused long input delays
and small lockups with the
d in: nvme-cli (Ubuntu Bionic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838555
Title:
nvme-cli 1.5 in Bionic does not suppo
I installed linux-hwe 4.15.0-57 #63~16.04.1-Ubuntu on xenial.
I have run the reproducers on both bionic and xenial, and both have
positive results. This has been tested in the kubernetes environment
which had issues, and is performing well.
I am happy to mark this as verified for xenial.
**
I installed linux-hwe 4.15.0-57 #63~16.04.1-Ubuntu on xenial.
I have run the reproducers on both bionic and xenial, and both have
positive results. This has been tested in the kubernetes environment
which had issues, and is performing well.
I am happy to mark this as verified for xenial.
**
I installed linux-hwe 4.15.0-57 #63~16.04.1-Ubuntu on xenial, and
ensured the -modules and -modules-extra package was installed.
I went into /var/lib/modules/4.15.0-56/ and did a search for hibmc_drm.
There was no mention apart from a header Makefile. The module was not
built and not present on
I installed linux-hwe 4.15.0-57 #63~16.04.1-Ubuntu on xenial, placed a
heavy load on the system.
Everything seemed stable and no lockups occurred. Due to the successful
tests in the hadoop environment under bionic and the nature of this
patch being from upstream stable, I am happy to mark this as
I installed linux-hwe 4.15.0-57 #63~16.04.1-Ubuntu on xenial, and
ensured the -modules and -modules-extra package was installed.
I went into /var/lib/modules/4.15.0-56/ and did a search for hibmc_drm.
There was no mention apart from a header Makefile. The module was not
built and not present on
I installed linux-hwe 4.15.0-57 #63~16.04.1-Ubuntu on xenial, placed a
heavy load on the system.
Everything seemed stable and no lockups occurred. Due to the successful
tests in the hadoop environment under bionic and the nature of this
patch being from upstream stable, I am happy to mark this as
Hi Lukasz,
We are in luck, after some very helpful debugging done by the customer, I have
been able to reliably reproduce this issue myself.
Firstly, this issue only affects users of Ubuntu inside a VMware Horizon VDI,
and only occurs after you install the VMware Horizon Agent for Linux.
The
Hi Lukasz,
We are in luck, after some very helpful debugging done by the customer, I have
been able to reliably reproduce this issue myself.
Firstly, this issue only affects users of Ubuntu inside a VMware Horizon VDI,
and only occurs after you install the VMware Horizon Agent for Linux.
The
Hi Lukasz,
We are in luck, after some very helpful debugging done by the customer, I have
been able to reliably reproduce this issue myself.
Firstly, this issue only affects users of Ubuntu inside a VMware Horizon VDI,
and only occurs after you install the VMware Horizon Agent for Linux.
The
Revised debdiff for bionic which enables the environment variables
IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS
** Patch added: "revised debdiff for bionic"
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5280261/+files/lp1838358_bionic_revised.debdiff
--
You
Hi Oliver,
Full details from the environment which has the problem:
Affected machines are all running Bionic and are fully patched.
firefox: 68.0.1+build1-0ubuntu0.18.04.1
gnome-shell: 3.28.4-0ubuntu18.04.1
ibus: 1.5.17-3ubuntu4
Machines are accessed as a VDI through VMware Horizon 7.9.0, and
Revised debdiff for bionic which enables the environment variables
IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS
** Patch added: "revised debdiff for bionic"
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5280261/+files/lp1838358_bionic_revised.debdiff
--
You
Revised debdiff for bionic which enables the environment variables
IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS
** Patch added: "revised debdiff for bionic"
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5280261/+files/lp1838358_bionic_revised.debdiff
--
You
Hi Oliver,
Full details from the environment which has the problem:
Affected machines are all running Bionic and are fully patched.
firefox: 68.0.1+build1-0ubuntu0.18.04.1
gnome-shell: 3.28.4-0ubuntu18.04.1
ibus: 1.5.17-3ubuntu4
Machines are accessed as a VDI through VMware Horizon 7.9.0, and
Hi Oliver,
Full details from the environment which has the problem:
Affected machines are all running Bionic and are fully patched.
firefox: 68.0.1+build1-0ubuntu0.18.04.1
gnome-shell: 3.28.4-0ubuntu18.04.1
ibus: 1.5.17-3ubuntu4
Machines are accessed as a VDI through VMware Horizon 7.9.0, and
** Description changed:
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell
and Firefox both freeze and the system becomes unusable. If you ssh into
the system
** Description changed:
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell
and Firefox both freeze and the system becomes unusable. If you ssh into
the system
** Description changed:
[Impact]
The following has been seen in a VMware Horizon VDI. I cannot reproduce this
issue myself.
When a user interacts with any password field in Firefox, gnome-shell
and Firefox both freeze and the system becomes unusable. If you ssh into
the system
I installed 4.15.0-56-generic #62~16.04.1-Ubuntu xenial HWE kernel, and
I followed the reproducer instructions at https://github.com/brb/conntrack-race,
specifically loading in the NAT iptables rules, enabling debug output of the
conntrack file and running the programs server and client.
Looking
I installed 4.15.0-56-generic #62~16.04.1-Ubuntu xenial HWE kernel, and
I followed the reproducer instructions at https://github.com/brb/conntrack-race,
specifically loading in the NAT iptables rules, enabling debug output of the
conntrack file and running the programs server and client.
Looking
I installed 4.15.0-56 from -proposed and ran some CPU stress tests and
everything was stable and no problems detected.
The kernel was also installed onto a few machines from the production hadoop
cluster which experienced extremely high cpu load, and the kernel is stable,
with
no CPU lockups in
I installed 4.15.0-56 from -proposed and ran some CPU stress tests and
everything was stable and no problems detected.
The kernel was also installed onto a few machines from the production hadoop
cluster which experienced extremely high cpu load, and the kernel is stable,
with
no CPU lockups in
Attached is the debdiff for bionic which restores ibus-
xx-f19-password.patch
** Patch added: "ibus debdiff for bionic"
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5279953/+files/lp1838358_bionic.debdiff
** Tags added: sts-sponsor
--
You received this bug
Attached is the debdiff for bionic which restores ibus-
xx-f19-password.patch
** Patch added: "ibus debdiff for bionic"
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5279953/+files/lp1838358_bionic.debdiff
** Tags added: sts-sponsor
--
You received this bug
Attached is the debdiff for bionic which restores ibus-
xx-f19-password.patch
** Patch added: "ibus debdiff for bionic"
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1838358/+attachment/5279953/+files/lp1838358_bionic.debdiff
** Tags added: sts-sponsor
--
You received this bug
D_PASSWORD=1 firefox
or
export IBUS_DISCARD_PASSWORD_APPS='firefox,.*chrome.*'
** Affects: ibus (Ubuntu)
Importance: Undecided
Status: New
** Affects: ibus (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
D_PASSWORD=1 firefox
or
export IBUS_DISCARD_PASSWORD_APPS='firefox,.*chrome.*'
** Affects: ibus (Ubuntu)
Importance: Undecided
Status: New
** Affects: ibus (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
D_PASSWORD=1 firefox
or
export IBUS_DISCARD_PASSWORD_APPS='firefox,.*chrome.*'
** Affects: ibus (Ubuntu)
Importance: Undecided
Status: New
** Affects: ibus (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
I installed 4.15.0-56-generic to a bionic VM, with the -modules and
-modules-extra packages. I went into /var/lib/modules/4.15.0-56/ and did a
search for
hibmc_drm. There was no mention apart from a header Makefile. The module was not
built and not present on amd64.
I did the same for
I installed 4.15.0-56-generic to a bionic VM, with the -modules and
-modules-extra packages. I went into /var/lib/modules/4.15.0-56/ and did a
search for
hibmc_drm. There was no mention apart from a header Makefile. The module was not
built and not present on amd64.
I did the same for
On xenial, I installed libvirt-bin 1.3.1-1ubuntu10.27 from -updates,
as well as virt-manager and qemu-system. I installed a bionic desktop VM and
issued "sudo shutdown -h now". libvirt-guests then connected to the VM and shut
it down gracefully before the system was shut down.
I then upgraded
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
--
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/1837833
Title:
EBS Volumes get stuck detach
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1837833
Title:
EBS Volumes get stuck detaching from
Public bug reported:
On AWS, it is possible to get a EBS volume stuck in the detaching state,
where it is not present in lsblk or lspci, but the cloud console says
the volume is detaching, and pci / nvme errors are output to dmesg every
180 seconds.
To reproduce reliably:
1) Start a AWS
Public bug reported:
On AWS, it is possible to get a EBS volume stuck in the detaching state,
where it is not present in lsblk or lspci, but the cloud console says
the volume is detaching, and pci / nvme errors are output to dmesg every
180 seconds.
To reproduce reliably:
1) Start a AWS
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1836971
[Impact]
On machines with extremely high CPU usage, parent task groups which have
a large number of children can make the for loop in
sched_cfs_period_timer() run until the watchdog fires when the
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1836971
[Impact]
On machines with extremely high CPU usage, parent task groups which have
a large number of children can make the for loop in
sched_cfs_period_timer() run until the watchdog fires when the
been proven in production
environments, so the overall risk is low.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also
been proven in production
environments, so the overall risk is low.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also
: 4e35c1cb9460240e983a01745b5f29fe3a4d8e39
Note the difference, old commit must be reverted first.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Affects
: 4e35c1cb9460240e983a01745b5f29fe3a4d8e39
Note the difference, old commit must be reverted first.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Affects: linux (Ubuntu Bionic)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Affects
** Changed in: linux (Ubuntu Bionic)
Status: Triaged => In Progress
** Changed in: linux (Ubuntu Disco)
Status: Triaged => In Progress
** Changed in: linux (Ubuntu Eoan)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
** Changed in: linux (Ubuntu Bionic)
Status: Triaged => In Progress
** Changed in: linux (Ubuntu Disco)
Status: Triaged => In Progress
** Changed in: linux (Ubuntu Eoan)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Kernel
ded => High
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Disco)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Eoan)
Assignee: (unassigned) => Matthew Ru
ded => High
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Disco)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Eoan)
Assignee: (unassigned) => Matthew Ru
Hi Po-Hsu Lin,
Sorry for not updating this bug earlier.
Upstream 4.4 and 4.9 are also effected by this bug, so I went and posted the
patches to be considered for upstream -stable.
Upstream 4.4 thread: [1]
Upstream 4.9 thread: [2]
Now, I got some feedback from the original author of the
Hi Po-Hsu Lin,
Sorry for not updating this bug earlier.
Upstream 4.4 and 4.9 are also effected by this bug, so I went and posted the
patches to be considered for upstream -stable.
Upstream 4.4 thread: [1]
Upstream 4.9 thread: [2]
Now, I got some feedback from the original author of the
I enabled -proposed and installed 4.4.0-1088-aws #99-Ubuntu, and again
went through the test case on a c5.large instance on aws.
The problem is solved and performance is restored, and performs the same
as a non-snapshot mounted disk.
Again, we can see merging has been enabled with:
$ cat
I enabled -proposed and installed 4.4.0-1088-aws #99-Ubuntu, and again
went through the test case on a c5.large instance on aws.
The problem is solved and performance is restored, and performs the same
as a non-snapshot mounted disk.
Again, we can see merging has been enabled with:
$ cat
I enabled enabled -proposed and installed 4.4.0-155.182, and went through the
test case on a c5.large instance on aws. Note, I used the -generic kernel since
-aws doesn't seem to be ready yet.
The problem is solved and performance is the same as non-snapshot
mounted disks.
We can see that
I enabled enabled -proposed and installed 4.4.0-155.182, and went through the
test case on a c5.large instance on aws. Note, I used the -generic kernel since
-aws doesn't seem to be ready yet.
The problem is solved and performance is the same as non-snapshot
mounted disks.
We can see that
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1833319
[Impact]
When copying files from a mounted LVM snapshot which resides on NVMe storage
devices, there is a massive performance degradation in the rate sectors are
read from the disk.
The kernel is not merging
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1833319
[Impact]
When copying files from a mounted LVM snapshot which resides on NVMe storage
devices, there is a massive performance degradation in the rate sectors are
read from the disk.
The kernel is not merging
e will be no regressions.
If you are interested in testing, I have prepared two ppas with
ef2d4615c59efb312e531a5e949970f37ca1c841 patched:
linux-image-generic:
https://launchpad.net/~mruffell/+archive/ubuntu/sf228435-test-generic
linux-image-aws: https://launchpad.net/~mruffell/+a
e will be no regressions.
If you are interested in testing, I have prepared two ppas with
ef2d4615c59efb312e531a5e949970f37ca1c841 patched:
linux-image-generic:
https://launchpad.net/~mruffell/+archive/ubuntu/sf228435-test-generic
linux-image-aws: https://launchpad.net/~mruffell/+a
aunchpad.net/~mruffell/+archive/ubuntu/sf228435-test-generic
linux-image-aws: https://launchpad.net/~mruffell/+archive/ubuntu/sf228435-test
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Xenial)
Importance: Undecided
Assignee: Mat
aunchpad.net/~mruffell/+archive/ubuntu/sf228435-test-generic
linux-image-aws: https://launchpad.net/~mruffell/+archive/ubuntu/sf228435-test
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Xenial)
Importance: Undecided
Assignee: Mat
aunchpad.net/~mruffell/+archive/ubuntu/sf228435-test-generic
linux-image-aws: https://launchpad.net/~mruffell/+archive/ubuntu/sf228435-test
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Affects: linux (Ubuntu Xenial)
Importance: Undecided
Assignee: Mat
Attached is the final debdiff for release, mostly for having a record of
it.
I have built it in a personal ppa, tested it and verified it works.
** Patch added: "sysvinit debdiff for trusty esm"
Attached is the final debdiff for release, mostly for having a record of
it.
I have built it in a personal ppa, tested it and verified it works.
** Patch added: "sysvinit debdiff for trusty esm"
Attached is the debdiff for xenial, in the case the SRU to xenial
happens to keep libvirt in sync between xenial and trusty-mitaka.
I have done some additional testing in xenial, and I can confirm that
the upstart script is not even called, and the sysvinit script is used
instead. This means that
Hi Corey,
I have attached the debdiff for trusty-mitaka. I am from SEG, and have
sent a test package to the customer for validation, so it can be
included in Trusty ESM.
I'll let you know when the patch is verified.
Thanks,
Matthew.
** Patch added: "libvirt debdiff for trusty-mitaka"
** Description changed:
+ subject: libvirt-bin: during shutdown libvirt-bin is stopped before
+ libvirt-guests causing hang
+
[Impact]
* libvirt-bin, in: libvirt-1.3.1-1ubuntu10.24~cloud0 in trusty mitaka uca
and the parent package in xenial, libvirt-1.3.1-1ubuntu10.24 are effected.
1501 - 1600 of 2053 matches
Mail list logo
