Attached is a revised debdiff for sssd for Bionic.
** Patch added: "sssd debdiff for Bionic v2"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432867/+files/lp1868703_sssd_bionic_v2.debdiff
--
You received this bug notification because you are a member of STS
Attached is a revised debdiff for sssd for Focal.
** Patch added: "sssd debdiff for Focal v2"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432866/+files/lp1868703_sssd_focal_v2.debdiff
--
You received this bug notification because you are a member of STS
Attached is a revised debdiff for sssd for Focal.
** Patch added: "sssd debdiff for Focal v2"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432866/+files/lp1868703_sssd_focal_v2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs,
** Patch removed: "adcli debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432450/+files/lp1868703_adcli_focal.debdiff
** Patch removed: "sssd debdiff for Focal"
** Patch removed: "adcli debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432450/+files/lp1868703_adcli_focal.debdiff
** Patch removed: "sssd debdiff for Focal"
** Description changed:
[Impact]
Microsoft has released a new security advisory for Active Directory (AD)
which outlines that man-in-the-middle attacks can be performed on a LDAP
server, such as AD DS, that works by an attacker forwarding an
authentication request to a Windows LDAP
** Description changed:
[Impact]
Microsoft has released a new security advisory for Active Directory (AD)
which outlines that man-in-the-middle attacks can be performed on a LDAP
server, such as AD DS, that works by an attacker forwarding an
authentication request to a Windows LDAP
** Tags added: sts-sponsor
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868703
Title:
Support "ad_use_ldaps" flag for new AD requirements (ADV190023)
To manage notifications about this bug go
Hello Dan, Eric and Mauricio,
Can you please review and consider sponsoring LP1868703 [1]?
[1] https://bugs.launchpad.net/bugs/1868703
Debdiffs for adcli and sssd are attached to the bug, and are for
Bionic and Focal. Groovy has all the fixes already.
Myself, the customer and the bug reporter
Attached is a sssd debdiff for Focal
** Patch added: "sssd debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432451/+files/lp1868703_sssd_focal.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Attached is a sssd debdiff for Bionic
** Patch added: "sssd debdiff for Bionic"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432453/+files/lp1868703_sssd_bionic.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Attached is a debdiff for adcli on Focal.
** Patch added: "adcli debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432450/+files/lp1868703_adcli_focal.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Attached is a adcli debdiff for Bionic
** Patch added: "adcli debdiff for Bionic"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1868703/+attachment/5432452/+files/lp1868703_adcli_bionic.debdiff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Summary changed:
- Support new AD requirements (ADV190023)
+ Support "ad_use_ldaps" flag for new AD requirements (ADV190023)
** Description changed:
- Please backport the following patch to add the option ad_use_ldaps.
+ [Impact]
- With this new boolean option the AD provider should only
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
Hi Tobias, Thorstein, and anyone who is after a backport of these
patches,
I have completed backporting the below patches to the Bionic and Focal
adcli and sssd packages, and I am looking for some help with testing. If
you have some spare time, a Windows Active Directory server available,
and
** Changed in: adcli (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: adcli (Ubuntu Bionic)
Status: Confirmed => In Progress
** Changed in: adcli (Ubuntu Bionic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: adcli (Ubuntu Focal)
I
Patches have been submitted to the Ubuntu kernel mailing list:
Patchset for Bionic:
https://lists.ubuntu.com/archives/kernel-team/2020-October/114166.html
https://lists.ubuntu.com/archives/kernel-team/2020-October/114167.html
https://lists.ubuntu.com/archives/kernel-team/2020-October/114168.html
Patches have been submitted to the Ubuntu kernel mailing list:
Patchset for Bionic:
https://lists.ubuntu.com/archives/kernel-team/2020-October/114166.html
https://lists.ubuntu.com/archives/kernel-team/2020-October/114167.html
https://lists.ubuntu.com/archives/kernel-team/2020-October/114168.html
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1898786
[Impact]
Systems that utilise bcache can experience extremely high IO wait times
when under constant IO pressure. The IO wait times seem to stay at a
consistent 1 second, and never drop as long as the bcache
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1898786
[Impact]
Systems that utilise bcache can experience extremely high IO wait times
when under constant IO pressure. The IO wait times seem to stay at a
consistent 1 second, and never drop as long as the bcache
ed => Medium
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Description changed:
- Hello,
+ BugLink: https://bugs.launchpad.net/bugs/1898786
ed => Medium
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Matthew Ruffell (mruffell)
** Description changed:
- Hello,
+ BugLink: https://bugs.launchpad.net/bugs/1898786
Attached is a debdiff for Bionic which implements support for VMware
Horizon SSO in gnome-shell.
** Patch added: "gnome-shell debdiff for Bionic"
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1886592/+attachment/5423915/+files/lp1886592_bionic.debdiff
--
You received this bug
Attached is a debdiff for gnome-shell for Focal with the required
patches to implement VMware Horizon SSO support.
** Patch added: "gnome-shell debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1886592/+attachment/5423914/+files/lp1886592_focal.debdiff
--
You
Attached is a debdiff for gnome-shell for Focal with the required
patches to implement VMware Horizon SSO support.
** Patch added: "gnome-shell debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1886592/+attachment/5423914/+files/lp1886592_focal.debdiff
--
You
Attached is a debdiff for gnome-shell for Focal with the required
patches to implement VMware Horizon SSO support.
** Patch added: "gnome-shell debdiff for Focal"
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1886592/+attachment/5423914/+files/lp1886592_focal.debdiff
--
You
Attached is a debdiff for Bionic which implements support for VMware
Horizon SSO in gnome-shell.
** Patch added: "gnome-shell debdiff for Bionic"
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1886592/+attachment/5423915/+files/lp1886592_bionic.debdiff
--
You received this bug
Attached is a debdiff for Bionic which implements support for VMware
Horizon SSO in gnome-shell.
** Patch added: "gnome-shell debdiff for Bionic"
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1886592/+attachment/5423915/+files/lp1886592_bionic.debdiff
--
You received this bug
** Description changed:
[Impact]
VMware Horizon is a VDI product that runs atop of VMware's normal
virtualisation stack, and it supports SSO authentication for login.
In the past, the VMware Horizon agent has been pretty buggy, and
requires SSO patches to be present to function,
** Description changed:
[Impact]
VMware Horizon is a VDI product that runs atop of VMware's normal
virtualisation stack, and it supports SSO authentication for login.
In the past, the VMware Horizon agent has been pretty buggy, and
requires SSO patches to be present to function,
** Description changed:
[Impact]
VMware Horizon is a VDI product that runs atop of VMware's normal
virtualisation stack, and it supports SSO authentication for login.
In the past, the VMware Horizon agent has been pretty buggy, and
requires SSO patches to be present to function,
Hi Benjamin,
Great to hear that the early results look promising.
Yes, let's give it a week, so we can ensure that these patches do their
job under the high loads the git server faces each day over the week.
If things still look good early next week, I will go ahead and prepare
the patches for
Hi Benjamin,
Great to hear that the early results look promising.
Yes, let's give it a week, so we can ensure that these patches do their
job under the high loads the git server faces each day over the week.
If things still look good early next week, I will go ahead and prepare
the patches for
Hi Benjamin,
I think Dan is onto something.
The following commit was merged in upstream 5.5-rc1, but was backported
to 4.15.0-87-generic through upstream stable:
commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b
Author: Coly Li
Date: Wed Nov 13 16:03:24 2019 +0800
Subject: bcache: at least try
Hi Benjamin,
I think Dan is onto something.
The following commit was merged in upstream 5.5-rc1, but was backported
to 4.15.0-87-generic through upstream stable:
commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b
Author: Coly Li
Date: Wed Nov 13 16:03:24 2019 +0800
Subject: bcache: at least try
Verifying for xenial:
I enabled -proposed, and installed 4.4.0-1116-aws:
$ uname -rv
4.4.0-1116-aws #129-Ubuntu SMP Tue Sep 29 18:17:22 UTC 2020
I rebooted, and was able to ssh in, and dmesg was clean.
I then installed 4.4.0-192-generic:
$ uname -rv
4.4.0-192-generic #222-Ubuntu SMP Tue Sep
Verifying for xenial:
I enabled -proposed, and installed 4.4.0-1116-aws:
$ uname -rv
4.4.0-1116-aws #129-Ubuntu SMP Tue Sep 29 18:17:22 UTC 2020
I rebooted, and was able to ssh in, and dmesg was clean.
I then installed 4.4.0-192-generic:
$ uname -rv
4.4.0-192-generic #222-Ubuntu SMP Tue Sep
Hello @shaynagar, thank you very much for reporting! We will look into
this asap.
More details: 4.4.0-190-generic is fine, 4.4.0-191-generic contains the
regression.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
Hello @shaynagar, thank you very much for reporting! We will look into
this asap.
More details: 4.4.0-190-generic is fine, 4.4.0-191-generic contains the
regression.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => High
** Description changed:
- This is a POTENTIAL REGRESSION.
+ [Impact]
- This issue occurs on one of the AWS instance "t2.medium"
+ The new
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => High
** Description changed:
- This is a POTENTIAL REGRESSION.
+ [Impact]
- This issue occurs on one of the AWS instance "t2.medium"
+ The new
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => High
** Description changed:
- This is a POTENTIAL REGRESSION.
+ [Impact]
- This issue occurs on one of the AWS instance "t2.medium"
+ The new
Performing verification:
First, reproducing on older kernel:
$ uname -rv
4.4.0-190-generic #220-Ubuntu SMP Fri Aug 28 23:02:15 UTC 2020
$ grep "clocksource" /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="clocksource=tsc"
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-190-generic
Performing verification:
First, reproducing on older kernel:
$ uname -rv
4.4.0-190-generic #220-Ubuntu SMP Fri Aug 28 23:02:15 UTC 2020
$ grep "clocksource" /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="clocksource=tsc"
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.4.0-190-generic
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1896578
[Impact]
Block discard is very slow on Raid10, which causes common use cases
which invoke block discard, such as mkfs and fstrim operations, to take
a very long time.
For example, on a i3.8xlarge
be affected.
Traditional hard disks, or SSD devices which do not support block
discard would not be affected.
If a regression were to occur, users could work around the issue by
running "mkfs.xfs -K " which would skip block discard entirely.
** Affects: linux (Ubuntu)
Impor
be affected.
Traditional hard disks, or SSD devices which do not support block
discard would not be affected.
If a regression were to occur, users could work around the issue by
running "mkfs.xfs -K " which would skip block discard entirely.
** Affects: linux (Ubuntu)
Impor
eam stable, and are trusted by
the community.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Focal)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also affects: linux (Ub
eam stable, and are trusted by
the community.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Focal)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also affects: linux (Ub
*** This bug is a duplicate of bug 1756315 ***
https://bugs.launchpad.net/bugs/1756315
** This bug has been marked a duplicate of bug 1756315
fstrim and discard operations take too long to complete - Ubuntu 16.04
--
You received this bug notification because you are a member of Kernel
*** This bug is a duplicate of bug 1756315 ***
https://bugs.launchpad.net/bugs/1756315
** This bug has been marked a duplicate of bug 1756315
fstrim and discard operations take too long to complete - Ubuntu 16.04
--
You received this bug notification because you are a member of Ubuntu
Hello Alexandre,
I tried to reproduce this bug, and I believe it has been fixed.
I started a i3.4xlarge instance on AWS, with Xenial as the distro:
$ uname -rv
4.4.0-1112-aws #124-Ubuntu SMP Fri Jul 24 11:10:25 UTC 2020
>From there, I checked the NVMe disks:
$ lsblk
NAMEMAJ:MIN RM SIZE
Hello Alexandre,
I tried to reproduce this bug, and I believe it has been fixed.
I started a i3.4xlarge instance on AWS, with Xenial as the distro:
$ uname -rv
4.4.0-1112-aws #124-Ubuntu SMP Fri Jul 24 11:10:25 UTC 2020
>From there, I checked the NVMe disks:
$ lsblk
NAMEMAJ:MIN RM SIZE
Hello Alexandre,
I tried to reproduce this bug, and I believe it has been fixed.
I started a i3.4xlarge instance on AWS, with Xenial as the distro:
$ uname -rv
4.4.0-1112-aws #124-Ubuntu SMP Fri Jul 24 11:10:25 UTC 2020
>From there, I checked the NVMe disks:
$ lsblk
NAMEMAJ:MIN RM SIZE
As promised, I have an update on the lab machine I left running
ksm_refcnt_overflow.sh for a week straight.
The machine was running 4.15.0-116-generic from -proposed:
$ uname -rv
4.15.0-116-generic #117-Ubuntu SMP Fri Aug 28 16:04:22 UTC 2020
$ uptime
04:36:14 up 7 days, 1 min, 1 user, load
As promised, I have an update on the lab machine I left running
ksm_refcnt_overflow.sh for a week straight.
The machine was running 4.15.0-116-generic from -proposed:
$ uname -rv
4.15.0-116-generic #117-Ubuntu SMP Fri Aug 28 16:04:22 UTC 2020
$ uptime
04:36:14 up 7 days, 1 min, 1 user, load
How about you try a slightly older kernel then:
To install 5.4.0-31-generic:
$ sudo apt install linux-image-5.4.0-31-generic linux-
modules-5.4.0-31-generic linux-modules-extra-5.4.0-31-generic linux-
headers-5.4.0-31-generic linux-headers-5.4.0-31
Then reboot your computer. Do the same as you
How about you try a slightly older kernel then:
To install 5.4.0-31-generic:
$ sudo apt install linux-image-5.4.0-31-generic linux-
modules-5.4.0-31-generic linux-modules-extra-5.4.0-31-generic linux-
headers-5.4.0-31-generic linux-headers-5.4.0-31
Then reboot your computer. Do the same as you
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1894591
[Impact]
The default clocksource for a KVM VM is kvm-clock, and I happen to need
tsc.
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
If I edit /etc/default/grub and
** Description changed:
BugLink: https://bugs.launchpad.net/bugs/1894591
[Impact]
The default clocksource for a KVM VM is kvm-clock, and I happen to need
tsc.
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
If I edit /etc/default/grub and
Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Xenial)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
S
Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Xenial)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
S
Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Xenial)
Importance: Medium
Assignee: Matthew Ruffell (mruffell)
Status: In Progress
** Tags: sts
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
S
@braingateway
Can you please try booting into the 5.4.0-42-generic kernel and see if
that works?
When you turn your computer on, press and hold the shift key to access the GRUB
boot menu.
Select "Advanced Options" and then "Ubuntu, with Linux 5.4.0-42-generic"
If 5.4.0-42-generic works and
@braingateway
Can you please try booting into the 5.4.0-42-generic kernel and see if
that works?
When you turn your computer on, press and hold the shift key to access the GRUB
boot menu.
Select "Advanced Options" and then "Ubuntu, with Linux 5.4.0-42-generic"
If 5.4.0-42-generic works and
As requested by the kernel team (in https://lists.ubuntu.com/archives
/kernel-team/2020-August/112775.html), I will do some additional testing
for this SRU to really make sure it won't cause any regressions.
I provisioned a lab machine on segmaas, running Bionic. I installed the
As requested by the kernel team (in https://lists.ubuntu.com/archives
/kernel-team/2020-August/112775.html), I will do some additional testing
for this SRU to really make sure it won't cause any regressions.
I provisioned a lab machine on segmaas, running Bionic. I installed the
Verification steps for focal:
Again, I made sure I can reproduce on the existing 5.4.0-42-generic
kernel.
I copied ksm_refcnt_overflow.sh and zero_page_refcount.c to the VM, and
built the kernel module, and inserted it into the kernel:
$ sudo insmod zero_page_refcount.ko
$ cat
Verification steps for focal:
Again, I made sure I can reproduce on the existing 5.4.0-42-generic
kernel.
I copied ksm_refcnt_overflow.sh and zero_page_refcount.c to the VM, and
built the kernel module, and inserted it into the kernel:
$ sudo insmod zero_page_refcount.ko
$ cat
Verification steps for Bionic:
First, I made sure I could reproduce the problem on 4.15.0-115-generic.
I made a fresh Bionic VM, and copied over the ksm_refcnt_overflow.sh and
zero_page_refcound.c files.
I built the kernel module, and inserted it into the kernel.
>From there, I checked the
Verification steps for Bionic:
First, I made sure I could reproduce the problem on 4.15.0-115-generic.
I made a fresh Bionic VM, and copied over the ksm_refcnt_overflow.sh and
zero_page_refcound.c files.
I built the kernel module, and inserted it into the kernel.
>From there, I checked the
Hi Chris, Steve,
>> I'm sure you have seen Ansgar's reply here:
>> https://lists.debian.org/debian-devel/2020/08/msg00121.html
>
>> > That grants additional rights to the `adm` group that it did not have
>> > before, for example to clear the dmesg buffer:
>> >
>> > $ dmesg --clear
>>
As 5.8.0-16-generic has now been released to the -release pocket,
CONFIG_SECURITY_DMESG_RESTRICT is now enabled in Groovy. Marking the
changes to the kernel as Fix Released.
** Changed in: linux (Ubuntu Groovy)
Status: Fix Committed => Fix Released
--
You received this bug notification
As per my most recent email to ubuntu-devel, I am marking the changes to
util-linux as Won't Fix.
Relevant mailing list discussion (for future reference):
Ansgar responded on debian-devel mentioning that adding cap_syslog to
dmesg enables the user to clear the kernel log buffer:
As per my most recent email to ubuntu-devel, I am marking the changes to
util-linux as Won't Fix.
Relevant mailing list discussion (for future reference):
Ansgar responded on debian-devel mentioning that adding cap_syslog to
dmesg enables the user to clear the kernel log buffer:
As 5.8.0-16-generic has now been released to the -release pocket,
CONFIG_SECURITY_DMESG_RESTRICT is now enabled in Groovy. Marking the
changes to the kernel as Fix Released.
** Changed in: linux (Ubuntu Groovy)
Status: Fix Committed => Fix Released
--
You received this bug notification
As per my most recent email to ubuntu-devel, I am marking the changes to
util-linux as Won't Fix.
Relevant mailing list discussion (for future reference):
Ansgar responded on debian-devel mentioning that adding cap_syslog to
dmesg enables the user to clear the kernel log buffer:
As 5.8.0-16-generic has now been released to the -release pocket,
CONFIG_SECURITY_DMESG_RESTRICT is now enabled in Groovy. Marking the
changes to the kernel as Fix Released.
** Changed in: linux (Ubuntu Groovy)
Status: Fix Committed => Fix Released
--
You received this bug notification
I asked the customer to test 4.15.0-114-generic on Xenial HWE from
-proposed on their HP DL360 Gen10 machines with the Intel Xeon Gold 5120
CPU. The machine has Sub-NUMA Clustering enabled and it is active.
The machine boots successfully, and there are no call traces or kernel
oops present:
#
I asked the customer to test 4.15.0-114-generic on Xenial HWE from
-proposed on their HP DL360 Gen10 machines with the Intel Xeon Gold 5120
CPU. The machine has Sub-NUMA Clustering enabled and it is active.
The machine boots successfully, and there are no call traces or kernel
oops present:
#
I installed 4.15.0-114-generic from -proposed to my test client machine,
which is a Ubuntu 18.04 Desktop VM.
I mounted two NFS shares, one with sec=sys, and the other with
sec=krb5p. I then opened each share up in separate tabs in Nautilus.
I then CUT a file from the sec=sys share, and PASTED it
I installed 4.15.0-114-generic from -proposed to my test client machine,
which is a Ubuntu 18.04 Desktop VM.
I mounted two NFS shares, one with sec=sys, and the other with
sec=krb5p. I then opened each share up in separate tabs in Nautilus.
I then CUT a file from the sec=sys share, and PASTED it
** Changed in: cloud-init (Ubuntu)
Status: In Progress => Won't Fix
** Changed in: cloud-init (Ubuntu Xenial)
Status: In Progress => Won't Fix
** Changed in: cloud-init (Ubuntu Bionic)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a
** Changed in: cloud-init (Ubuntu)
Status: In Progress => Won't Fix
** Changed in: cloud-init (Ubuntu Xenial)
Status: In Progress => Won't Fix
** Changed in: cloud-init (Ubuntu Bionic)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a
Hi @pau-capdevila
Your USB problem is unrelated to the issue in this bug, since your USB
device fails to do the initial handshake and enumeration.
> usb 1-1.2.1: device descriptor read/64, error -32
>From /usr/include/asm-generic/errno-base.h, Error -32 is:
#define EPIPE 32 /*
Hi @pau-capdevila
Your USB problem is unrelated to the issue in this bug, since your USB
device fails to do the initial handshake and enumeration.
> usb 1-1.2.1: device descriptor read/64, error -32
>From /usr/include/asm-generic/errno-base.h, Error -32 is:
#define EPIPE 32 /*
Hi @jeremyn54
> the error can be consistently reproduced on both signed and testing
kernels.
Reproduced on the test kernel? The one that I built in the ppa? If
that's the case, then "usb: handle warm-reset port requests on hub
resume" might not be to blame after all.
I had a look at your kernel
1001 - 1100 of 2042 matches
Mail list logo
