from:"Ruffell"

** Summary changed:

- superblock checksum mismatch in resize2fs
+ Resizing cloud-images occasionally fails due to superblock checksum mismatch 
in resize2fs

** Description changed:

- Hi,
- We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:
+ [Impact]
+ 
+ This is a long running bug plaguing cloud-images, where on a rare
+ occasion resize2fs would fail and the image would not resize to fit the
+ entire disk.
+ 
+ Online resizes would fail due to a superblock checksum mismatch, where
+ the superblock in memory differs from what is currently on disk due to
+ changes made to the image.
+ 
+ Changing the read of the superblock to Direct I/O solves the issue.
+ 
+ [Testcase]
+ 
+ Start an c5.large instance on AWS, and attach a 60gb gp3 volume for use
+ as a scratch disk.
+ 
+ Run the following script, courtesy of Krister Johansen and his team:
  
 #!/usr/bin/bash
 set -euxo pipefail
  
 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done
  
- (This was on a 60gb gp3 volume attached to a c5.4xlarge)
+ Test packages are available in the following ppa:
  
- We were able to find a fix that works and get the patch accepted
- upstream.  The short explanation is that by switching the superblock
- read to direct io, we no longer see the problem.
+ https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test
  
- The patch is available here, but hasn't been published in a released
- version of e2fsprogs:
+ If you install the test packages, the race no longer occurs.
  
- 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84
+ [Where problems could occur]
  
- A longer thread with the maintainer is available here:
+ We are changing how resize2fs reads the superblock from underlying
+ disks.
  
+ If a regression were to occur, resize2fs could fail to resize offline or
+ online volumes. As all cloud-images are online resized during their
+ initial boot, this could have a large impact to public and private
+ clouds should a regression occur.
+ 
+ [Other info]
+ 
+ Upstream mailing list discussion: 
+ https://lore.kernel.org/linux-ext4/20230605225221.ga5...@templeofstupid.com/
  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/
  
- This bug report is to request that Ubuntu backport this patch to the
- versions of e2fsprogs that are in releases that are available in images
- on AWS, preferably Focal and Jammy.
+ This was fixed in the below commit upstream:
+ 
+ commit 43a498e938887956f393b5e45ea6ac79cc5f4b84
+ Author: Theodore Ts'o 
+ Date: Thu, 15 Jun 2023 00:17:01 -0400
+ Subject: resize2fs: use Direct I/O when reading the superblock for
+  online resizes
+ Link: 
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84
+ 
+ The commit has not been tagged to any release. All supported Ubuntu
+ releases require this fix, and need to be published in standard non-ESM
+ archives to be picked up in cloud images.

** Tags added: sts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  Resizing cloud-images occasionally fails due to superblock checksum
  mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  [Impact]

  This is a long running bug plaguing cloud-images, where on a rare
  occasion resize2fs would fail and the image would not resize to fit
  the entire disk.

  Online resizes would fail due to a superblock checksum mismatch, where
  the superblock in memory differs from what is currently on disk due to
  changes made to the image.

  Changing the read of the superblock to Direct I/O solves the issue.

  [Testcase]

  Start an c5.large instance on AWS, and attach a 60gb gp3 volume for
  use as a

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on trusty which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on trusty"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707900/+files/lp2036467_trusty.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on xenial which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on xenial"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707899/+files/lp2036467_xenial.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on bionic which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on bionic"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707898/+files/lp2036467_bionic.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on focal which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on focal"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707896/+files/lp2036467_focal.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on jammy which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on jammy"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707895/+files/lp2036467_jammy.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on lunar which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on lunar"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707894/+files/lp2036467_lunar.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

Attached is a debdiff for e2fsprogs on mantic which fixes this issue.

** Patch added: "Debdiff for e2fsprogs on mantic"
   
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707893/+files/lp2036467_mantic.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 2036467] Re: superblock checksum mismatch in resize2fs

** Also affects: e2fsprogs (Ubuntu Lunar)
   Importance: Undecided
   Status: New

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

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

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

** Changed in: e2fsprogs (Ubuntu Mantic)
   Status: Confirmed => In Progress

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

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

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

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

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

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

** Changed in: e2fsprogs (Ubuntu Mantic)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Lunar)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Jammy)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Focal)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Bionic)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Xenial)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Trusty)
   Importance: Undecided => Critical

** Changed in: e2fsprogs (Ubuntu Mantic)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: e2fsprogs (Ubuntu Lunar)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: e2fsprogs (Ubuntu Jammy)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: e2fsprogs (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: e2fsprogs (Ubuntu Bionic)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: e2fsprogs (Ubuntu Xenial)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: e2fsprogs (Ubuntu Trusty)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2036467

Title:
  superblock checksum mismatch in resize2fs

Status in cloud-images:
  New
Status in e2fsprogs package in Ubuntu:
  In Progress
Status in e2fsprogs source package in Trusty:
  In Progress
Status in e2fsprogs source package in Xenial:
  In Progress
Status in e2fsprogs source package in Bionic:
  In Progress
Status in e2fsprogs source package in Focal:
  In Progress
Status in e2fsprogs source package in Jammy:
  In Progress
Status in e2fsprogs source package in Lunar:
  In Progress
Status in e2fsprogs source package in Mantic:
  In Progress

Bug description:
  Hi,
  We run ext4 on EBS volumes on EC2.  During provisioning, cloud-init will 
occasionally report that resize2fs has failed due to a superblock checksum 
mismatch.  We debugged this internally, and were able to come up with the 
following reproducer:

 #!/usr/bin/bash
 set -euxo pipefail

 while true
 do
 parted /dev/nvme1n1 mklabel gpt mkpart primary 2048s 2099200s
 sleep .5
 mkfs.ext4 /dev/nvme1n1p1
 mount -t ext4 /dev/nvme1n1p1 /mnt
 stress-ng --temp-path /mnt -D 4 &
 STRESS_PID=$!
 sleep 1
 growpart /dev/nvme1n1 1
 resize2fs /dev/nvme1n1p1
 kill $STRESS_PID
 wait $STRESS_PID
 umount /mnt
 wipefs -a /dev/nvme1n1p1
 wipefs -a /dev/nvme1n1
 done

  (This was on a 60gb gp3 volume attached to a c5.4xlarge)

  We were able to find a fix that works and get the patch accepted
  upstream.  The short explanation is that by switching the superblock
  read to direct io, we no longer see the problem.

  The patch is available here, but hasn't been published in a released
  version of e2fsprogs:

  
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=43a498e938887956f393b5e45ea6ac79cc5f4b84

  A longer thread with the maintainer is available here:

  https://lore.kernel.org/linux-ext4/20230609042239.ga1436...@mit.edu/

  This bug report is to request that Ubuntu backport this patch to the
  versions of e2fsprogs that are in releases that are available in
  images on AWS, preferably Focal and Jammy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036467/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2035123] Re: scripts/pahole-flags.sh change return to exit 0

2023-09-27 Thread Matthew Ruffell

Patches have been submitted to the kernel team mailing list:

https://lists.ubuntu.com/archives/kernel-team/2023-September/144570.html
https://lists.ubuntu.com/archives/kernel-team/2023-September/144571.html

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

Title:
  scripts/pahole-flags.sh change return to exit 0

Status in linux package in Ubuntu:
  Fix Released
Status in linux-bluefield package in Ubuntu:
  Triaged
Status in linux source package in Jammy:
  In Progress
Status in linux-bluefield source package in Jammy:
  In Progress

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2035123

  [Impact]

  When building the Jammy linux-bluefield kernel tree on a system
  without pahole installed, the following warning is emitted:

  ./scripts/pahole-flags.sh: line 7: return: can only `return' from a
  function or sourced script

  scripts/pahole-flags.sh attempts to return from an if statement that
  is not within a function, and generates a warning.

  The fix is straightforward, changing return to an exit 0.

  --- a/scripts/pahole-flags.sh
  +++ b/scripts/pahole-flags.sh
  @@ -4,7 +4,7 @@
   extra_paholeopt=

   if ! [ -x "$(command -v ${PAHOLE})" ]; then
  -   return
  +   exit 0
   fi

  [Testcase]

  Clone the linux-bluefield kernel tree and build it on a arm64 system without
  pahole installed.

  A test kernel is available with the fix applied in:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf368560-test

  Both linux-bluefield and ubuntu-jammy build correctly.

  [Fix]

  This was fixed by Linus Torvalds in the following merge commit:

  commit fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4
  Merge: bfc484fe6abb 84882cf72cd7
  Author: Linus Torvalds 
  Date:   Tue Nov 2 06:20:58 2021 -0700
  Subject: Merge tag 'net-next-for-5.16' of 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
  Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4

  Note, the original commit does not have the fix included:

  commit 9741e07ece7c247dd65e1aa01e16b683f01c05a8
  Author: Jiri Olsa 
  Date:   Fri Oct 29 14:57:29 2021 +0200
  Subject: kbuild: Unify options for BTF generation for vmlinux and modules
  Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9741e07ece7c247dd65e1aa01e16b683f01c05a8

  The Ubuntu kernel cherry-picked the original commit and did not pick up the
  silent fix made in the merge commit. Submitting the silent fix as a SAUCE 
patch
  with changelog describing the change.

  Note: I know SAUCE patches are bad, but in this scenario, to revert
  the initial commit and re-apply the fixed version would require us to
  revert two additional dependency commits, making six patches to
  review, vs, a one line change in a SAUCE commit that has a real
  changelog entry.

  [Where problems could occur]

  The Ubuntu kernel is built with pahole enabled, and requires pahole to
  be installed as a build dependency. It is extremely unlikely that any
  users are disabling pahole at build time, apart from linux-bluefield
  engineers.

  If a regression were to occur, engineers would see errors during build
  time about scripts/pahole-flags.sh not executing properly.

  [Other info]

  Linus remarked about the issue in the following lkml discussion:

  
https://lore.kernel.org/lkml/CAHk-=wgdE6=ob5nf60gvryag24mkajbgjf3jpufme1k_upb...@mail.gmail.com/
  
https://lore.kernel.org/lkml/CAHk-=wgPZM4bN=LUCrMkG3FX808QSLm6Uv6ixm5P350_7c=x...@mail.gmail.com/

  This was silently Incorporated into the linux-stable commit:

  commit 0baced0e0938f2895ceba54038eaf15ed91032e7 5.15.y
  From: Jiri Olsa 
  Date: Sun, 4 Sep 2022 15:19:00 +0200
  Subject: kbuild: Unify options for BTF generation for vmlinux and modules
  Link: 
https://github.com/gregkh/linux/commit/0baced0e0938f2895ceba54038eaf15ed91032e7

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2035123] Re: scripts/pahole-flags.sh change return to exit 0

2023-09-27 Thread Matthew Ruffell

** Summary changed:

- scripts/pahole-flags.sh needs upstream fix
+ scripts/pahole-flags.sh change return to exit 0

** Description changed:

- When doing a kernel make in our Jammy repo we notice the follow error
- being emitted:
+ BugLink: https://bugs.launchpad.net/bugs/2035123
+ 
+ [Impact]
+ 
+ When building the Jammy linux-bluefield kernel tree on a system without
+ pahole installed, the following warning is emitted:
  
  ./scripts/pahole-flags.sh: line 7: return: can only `return' from a
  function or sourced script
  
- It appears that while the Jammy baseline is 5.15.99 (as per the top-level 
Makefile)
- the file scripts/pahole-flags.sh is out of date with upstream 5.15.99
+ scripts/pahole-flags.sh attempts to return from an if statement that is
+ not within a function, and generates a warning.
  
- The upstream 5.15.99 version of scripts/pahole-flags.sh fixes this issue by 
making this change:
- 7c7
- <   return
- ---
- >   exit 0
+ The fix is straightforward, changing return to an exit 0.
  
- This seems like a simple fix, but not sure who should be fixing this.
+ --- a/scripts/pahole-flags.sh
+ +++ b/scripts/pahole-flags.sh
+ @@ -4,7 +4,7 @@
+  extra_paholeopt=
+  
+  if ! [ -x "$(command -v ${PAHOLE})" ]; then
+ -   return
+ +   exit 0
+  fi
+ 
+ [Testcase]
+ 
+ Clone the linux-bluefield kernel tree and build it on a arm64 system without
+ pahole installed.
+ 
+ A test kernel is available with the fix applied in:
+ 
+ https://launchpad.net/~mruffell/+archive/ubuntu/sf368560-test
+ 
+ Both linux-bluefield and ubuntu-jammy build correctly.
+ 
+ [Fix]
+ 
+ This was fixed by Linus Torvalds in the following merge commit:
+ 
+ commit fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4
+ Merge: bfc484fe6abb 84882cf72cd7
+ Author: Linus Torvalds 
+ Date:   Tue Nov 2 06:20:58 2021 -0700
+ Subject: Merge tag 'net-next-for-5.16' of 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
+ Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4
+ 
+ Note, the original commit does not have the fix included:
+ 
+ commit 9741e07ece7c247dd65e1aa01e16b683f01c05a8
+ Author: Jiri Olsa 
+ Date:   Fri Oct 29 14:57:29 2021 +0200
+ Subject: kbuild: Unify options for BTF generation for vmlinux and modules
+ Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9741e07ece7c247dd65e1aa01e16b683f01c05a8
+ 
+ The Ubuntu kernel cherry-picked the original commit and did not pick up the 
+ silent fix made in the merge commit. Submitting the silent fix as a SAUCE 
patch 
+ with changelog describing the change.
+ 
+ [Where problems could occur]
+ 
+ The Ubuntu kernel is built with pahole enabled, and requires pahole to
+ be installed as a build dependency. It is extremely unlikely that any
+ users are disabling pahole at build time, apart from linux-bluefield
+ engineers.
+ 
+ If a regression were to occur, engineers would see errors during build
+ time about scripts/pahole-flags.sh not executing properly.
+ 
+ [Other info]
+ 
+ Linus remarked about the issue in the following lkml discussion:
+ 
+ 
https://lore.kernel.org/lkml/CAHk-=wgdE6=ob5nf60gvryag24mkajbgjf3jpufme1k_upb...@mail.gmail.com/
+ 
https://lore.kernel.org/lkml/CAHk-=wgPZM4bN=LUCrMkG3FX808QSLm6Uv6ixm5P350_7c=x...@mail.gmail.com/
+ 
+ This was silently Incorporated into the linux-stable commit:
+ 
+ commit 0baced0e0938f2895ceba54038eaf15ed91032e7 5.15.y
+ From: Jiri Olsa 
+ Date: Sun, 4 Sep 2022 15:19:00 +0200
+ Subject: kbuild: Unify options for BTF generation for vmlinux and modules
+ Link: 
https://github.com/gregkh/linux/commit/0baced0e0938f2895ceba54038eaf15ed91032e7

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

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

** Changed in: linux-bluefield (Ubuntu Jammy)
   Status: Triaged => In Progress

** Changed in: linux (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux-bluefield (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Jammy)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: linux-bluefield (Ubuntu Jammy)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Description changed:

  BugLink: https://bugs.launchpad.net/bugs/2035123
  
  [Impact]
  
  When building the Jammy linux-bluefield kernel tree on a system without
  pahole installed, the following warning is emitted:
  
  ./scripts/pahole-flags.sh: line 7: return: can only `return' from a
  function or sourced script
  
  scripts/pahole-flags.sh attempts to return from an if statement that is
  not within a function, and generates a warning.
  
  The fix is straightforward, changing return to an exit 0.
  
  --- a/scripts/pahole-flags.sh
  +++ b/scripts/pahole-flags.sh
  @@ -4,7 +4,7 @@
-  extra_paholeopt=
-  
-  if ! [ -x "$(command -v ${PAHOLE})" ]; then

Re: Retention period for autopkgtest test logs

2023-09-27 Thread Matthew Ruffell

On Wed, 27 Sept 2023 at 06:11, John Chittum  wrote:
>
> Could we add "Keeping the last run"

Yes please! Can we add keeping the last successful run, as well as the
last current run? If the current run fails, its nice to be able to
compare to a previous successful run.

>
> That way you delete, but aren't just time constrained. Keeping the last test 
> run can be useful to do a comparison, if needed.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Apache2 Vulnerability

2023-09-15 Thread Matthew Ruffell

Hi Daniel,

The two CVEs you mention, CVE-2023-27522 and CVE-2023-25690, have already
been
addressed in Ubuntu, and have been since March.

https://ubuntu.com/security/CVE-2023-27522
https://ubuntu.com/security/CVE-2023-25690

For 22.04, these were both fixed in apache2 2.4.52-1ubuntu4.4:

https://bugs.launchpad.net/ubuntu/+source/apache2/2.4.52-1ubuntu4.4

For 20.04, these were both fixed in apache2 2.4.41-4ubuntu3.14:

https://bugs.launchpad.net/ubuntu/+source/apache2/2.4.41-4ubuntu3.14

Packages in the Ubuntu archive don't typically receive wholesale point
releases
unless that package has a microrelease exception. This is intended to keep
regressions and changes in functionality to a minimum. Instead, we simply
take
the CVE fix itself, and place it ontop of the version in the Ubuntu archive,
and make a new build. The CVE is fixed without having to take sometimes
hundreds of additional changes at the same time.

See:

https://wiki.ubuntu.com/SecurityTeam/FAQ
https://wiki.ubuntu.com/StableReleaseUpdates#Why

In the future, see the Ubuntu CVE tracker to see if a particular CVE has
been
fixed.

Thanks,
Matthew

On Fri, 15 Sept 2023 at 11:00, Daniel Johnston 
wrote:

> Hello,
>
>
>
> I was wondering on when you plan to upgrade Apache from 2.4.55 to at least
> 2.4.56 to address the vulnerabilities with Apache?
>
> We have been checking weekly for a number of months now.
>
> Changes with Apache 2.4.56
>
>
>
>   *) SECURITY: CVE-2023-27522: Apache HTTP Server: mod_proxy_uwsgi
>
>  HTTP response splitting (cve.mitre.org)
>
>  HTTP Response Smuggling vulnerability in Apache HTTP Server via
>
>  mod_proxy_uwsgi. This issue affects Apache HTTP Server: from
>
>  2.4.30 through 2.4.55.
>
>  Special characters in the origin response header can
>
>  truncate/split the response forwarded to the client.
>
>  Credits: Dimas Fariski Setyawan Putra (nyxsorcerer)
>
>
>
>   *) SECURITY: CVE-2023-25690: HTTP request splitting with
>
>  mod_rewrite and mod_proxy (cve.mitre.org)
>
>  Some mod_proxy configurations on Apache HTTP Server versions
>
>  2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack.
>
>  Configurations are affected when mod_proxy is enabled along with
>
>  some form of RewriteRule or ProxyPassMatch in which a non-specific
>
>  pattern matches some portion of the user-supplied request-target (URL)
>
>  data and is then re-inserted into the proxied request-target
>
>  using variable substitution. For example, something like:
>
> RewriteEngine on
>
> RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1;;
> [P]
>
> ProxyPassReverse /here/  http://example.com:8080/
>
>  Request splitting/smuggling could result in bypass of access
>
>  controls in the proxy server, proxying unintended URLs to
>
>  existing origin servers, and cache poisoning.
>
>  Credits: Lars Krapf of Adobe
>
>
>
> *Daniel Johnston*********
>
> *IT Systems Administrator*
>
>  |
>
> *Premier Credit Union*
>
> 515-245-3541
>
>  |
>
> dani...@premiercu.org
>
> www.PremierCU.org 
>
> 
>
> 
>
> 800 9th St
>
> ,
>
> Des Moines
>
> ,
>
> Iowa
>
>
>
> 50309
>
> *Leave us a Review on Google!
> *
>
> 
>
> *This e-mail, including attachments, is covered by the Electronic
> Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential, and may
> be legally privileged. If you are not the intended recipient, you are
> hereby notified that any retention, dissemination, distribution, or copying
> of this communication is strictly prohibited. Please reply to the sender if
> you received this message in error, and then please delete it. Thank you.*
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-08-27 Thread Matthew Ruffell

** Also affects: gvfs (Ubuntu Mantic)
   Importance: Unknown
   Status: New

** Also affects: tracker-miners (Ubuntu Mantic)
   Importance: High
 Assignee: Denison Barbosa (justdenis)
   Status: Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 2020834] Re: Properly convert DNS names with '-' characters to valid dbus object paths

2023-07-26 Thread Matthew Ruffell

Hi everyone,

The term "regression" is a slight overstatement for Kinetic, as login
fails with the version in -updates as well, due to it not supporting the
"-" in the domain name.

With 0.9.2 in kinetic -updates:

ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from
server: error while updating policy: can't get policies for "ec2amaz-
hg2r0q8.fabio-rg.com": failed to retrieve offline state from SSSD: dbus:
invalid message: invalid path name

and then login also fails. So, the package in -proposed does not break
anything further, but it doesn't fix everything either.

Now, here is what I found with the package in -proposed:

Jul 20 05:21:35 ip-172-31-55-219 adsysctl[2564546]: level=error msg="Error from 
server: error while updating policy: can't get policies for 
\"ip-172-31-55-219\": failed to retrieve the list of GPO (exited with 1): exit 
status 1
Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldap://ec2amaz-hg2r0q8.fabio-rg.com' with backend 'ldap': 
LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to open session: (1, 'LDAP client internal error: 
NT_STATUS_INVALID_PARAMETER')
"

> Failed to connect to 'ldap://ec2amaz-hg2r0q8.fabio-rg.com'
> ith backend 'ldap': LDAP client internal error: NT_STATUS_INVALID_PARAMETER

So this is a ldap based error, but we know this already.

I then tried to use other ldap based tools, like ldbsearch:

$ sudo apt install ldb-tools samba-dsdb-modules
$ cd /tmp
$ ll
krb5cc_193080_Xu8aKP
$ sudo ldbsearch -H ldap://ec2amaz-hg2r0q8.fabio-rg.com 
--use-krb5-ccache=/tmp/krb5cc_193080_Xu8aKP --debug-stdout --debuglevel 20
...
resolve_lmhosts: Attempting lmhosts lookup for name 
ec2amaz-hg2r0q8.fabio-rg.com<0x20>
startlmhosts: Can't open lmhosts file /etc/samba/lmhosts. Error was No such 
file or directory
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gssapi_krb5
cli_credentials(WORKGROUP/root) without realm, cannot use kerberos for this 
connection ldap/ec2amaz-hg2r0q8.fabio-rg.com
Failed to start GENSEC client mech gssapi_krb5: NT_STATUS_INVALID_PARAMETER
gensec_spnego_create_negTokenInit_step: Failed to setup SPNEGO negTokenInit 
request
gensec_update_send: spnego[0x5556c039ff10]: subreq: 0x5556c03a0450
gensec_update_done: spnego[0x5556c039ff10]: NT_STATUS_INVALID_PARAMETER 
tevent_req[0x5556c03a0450/../../auth/gensec/spnego.c:1631]: state[3] 
error[-7963671676338569203 (0x917B5ACDC00D)]  state[struct 
gensec_spnego_update_state (0x5556c03a0610)] timer[(nil)] 
finish[../../auth/gensec/spnego.c:1947]
Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldap://ec2amaz-hg2r0q8.fabio-rg.com' with backend 'ldap': 
LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldap://ec2amaz-hg2r0q8.fabio-rg.com - LDAP client internal 
error: NT_STATUS_INVALID_PARAMETER

Now, if we do this on Jammy, it works fine.

I was trying out different parameters to ldbsearch on kinetic, as you
can see the user is incorrect:

WORKGROUP/root

The clue came from:

cannot use kerberos for this connection ldap/ec2amaz-hg2r0q8.fabio-
rg.com

I started looking at kerberos credential caches.

I found that if I did a fresh kinit:

$ sudo kinit fabiomir...@fabio-rg.com
Password for fabiomir...@fabio-rg.com: 

$ ll
krb5cc_0
krb5cc_193080_Xu8aKP

Now, if we use this fresh one:

$ sudo ldbsearch -H ldap://ec2amaz-hg2r0q8.fabio-rg.com --use-
krb5-ccache=/tmp/krb5cc_0 --debug-stdout --debuglevel 20

Everything works fine on Kinetic.

So, maybe the kerberos keytab / credential cache is broken.

If we compare:

$ sudo klist /tmp/krb5cc_0
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: fabiomir...@fabio-rg.com

Valid starting ExpiresService principal
07/20/23 05:28:49  07/20/23 15:28:49  krbtgt/fabio-rg@fabio-rg.com
renew until 07/21/23 05:28:38
07/20/23 05:30:18  07/20/23 15:28:49  
ldap/ec2amaz-hg2r0q8.fabio-rg@fabio-rg.com
renew until 07/21/23 05:28:38

$ sudo klist /tmp/krb5cc_193080_Xu8aKP 
Ticket cache: FILE:/tmp/krb5cc_193080_Xu8aKP
Default principal: fabiomir...@fabio-rg.com

Valid starting ExpiresService principal
07/20/23 03:19:25  07/20/23 13:19:25  krbtgt/fabio-rg@fabio-rg.com
renew until 07/21/23 03:19:25

If we compare to Jammy:

$ sudo klist /tmp/krb5cc_193080_5HVmi5
Ticket cache: FILE:/tmp/krb5cc_193080_5HVmi5
Default principal: fabiomir...@fabio-rg.com

Valid starting ExpiresService principal
07/20/23 01:19:29  07/20/23 11:19:29  krbtgt/fabio-rg@fabio-rg.com
renew until 07/21/23 01:19:29
07/20/23 01:19:30  07/20/23 11:19:29  
ldap/ec2amaz-hg2r0q8.fabio-rg@fabio-rg.com
07/20/23 01:19:30  07/20/23 11:19:29  
cifs/ec2amaz-hg2r0q8.fabio-rg@fabio-rg.com

The kerberos credential cache obtained by sssd is missing the service
principal for ldap/ec2amaz-hg2r0q8.fabio-rg@fabio-rg.com.

I haven't

Re: adsys SRU

2023-07-03 Thread Matthew Ruffell

Hi JB,

I too would like to go forward with the entire backport too, but time
is running short. This user has a SLA deadline of 2023-07-09. I
submitted patches to the LP bug one month ago on 2023-05-26 and was
subsequently blocked by the 0.12.0 upload in -unapproved on
2023-06-06. The impact for the user isn't too bad, they would like to
consume the fixed adsys so they can run their testsuites internally,
and they see the bug as a blocker to onboard other new users to the
platform as it breaks a widely deployed use case of '-' in domain
names. So low priority, apart from SLA deadlines.

Thanks,
Matthew

On Mon, 3 Jul 2023 at 19:29, Jean-Baptiste Lallement
 wrote:
>
> Hey Matthew,
>
> We are still waiting for a go/no-go from the SRU team, but the discussion 
> seems to have stalled. I'd rather move forward with the entire backport since 
> it fixes much more than just this bug.
> What is the priority for this customer, any deadline?
>
> Thanks.
>
> JB
>
> On Mon, Jul 3, 2023 at 9:03 AM Matthew Ruffell 
>  wrote:
>>
>> Hi,
>>
>> I know discussions are still ongoing about the adsys 0.12.0 SRU, but I
>> have a user who wishes to have LP #2020834 [1] fixed, which high
>> priority.
>>
>> [1] https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834
>>
>> Would it be possible to potentially reject 0.12.0 from jammy
>> -unapproved, we get LP #2020834 sponsored and uploaded, verified and
>> released, before we start discussing 0.12.0 again for Jammy and Lunar?
>>
>> I was planning on just letting 0.12.0 happen since the fix is present
>> in 0.10.0, but my user has time restrictions and would like to be able
>> to use dashes '-' in their domain names.
>>
>> Thanks,
>> Matthew

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

Re: adsys SRU

2023-07-03 Thread Matthew Ruffell

Hi,

I know discussions are still ongoing about the adsys 0.12.0 SRU, but I
have a user who wishes to have LP #2020834 [1] fixed, which high
priority.

[1] https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834

Would it be possible to potentially reject 0.12.0 from jammy
-unapproved, we get LP #2020834 sponsored and uploaded, verified and
released, before we start discussing 0.12.0 again for Jammy and Lunar?

I was planning on just letting 0.12.0 happen since the fix is present
in 0.10.0, but my user has time restrictions and would like to be able
to use dashes '-' in their domain names.

Thanks,
Matthew

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release

[Desktop-packages] [Bug 2020834] Re: Properly convert DNS names with '-' characters to valid dbus object paths

2023-06-27 Thread Matthew Ruffell

** Description changed:

  [Impact]
  
  It is common that domain names contain the '-' character, as in "test-
  example.com", and adsys versions 0.9.2 and below cannot parse these
  correctly, leading to the error:
  
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from
  server: error while updating policy: can't get policies for "test-
  example.com": failed to retrieve offline state from SSSD: dbus: invalid
  message: invalid path name
  
  when attempting to run adsys on a system attached to "test-example.com"
  Active Directory.
  
  Currently, 0.9.2 only changes '.' into '_2e', and this would change all
  special characters to use their hexadecimal representations, notably '-'
  becomes '_2d'.
  
- There is plans from Foundations + Desktop to SRU 0.11.0 back to at least
+ There is plans from Foundations + Desktop to SRU 0.12.0 back to at least
  Jammy, documented in bug 2020682 which depends on golang 1.20 to be
  included in the jammy archive, documented in bug 2020658. However, this
- fixup is required with high priority while the 0.11.0 release is being
+ fixup is required with high priority while the 0.12.0 release is being
  prepared, and the SRU will hopefully bridge a few weeks between SRU
- release to release of 0.11.0.
+ release to release of 0.12.0.
  
  [Testcase]
  
  Start a Windows Server VM, 2022 will be fine, and create an Active
  Directory with the domain "test-example.com".
  
  Launch a Focal, or Jammy, or Kinetic VM, and use SSSD to join the
  domain.
  
  Try to enable adsys:
  
  $ sudo apt install adsys
  $ adsysctl update
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from 
server: error while updating policy: can't get policies for "test-example.com": 
failed to retrieve offline state from SSSD: dbus: invalid message: invalid path 
name
  
  There are test packages in the below ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf360012-test
  
  If you install the test package and retry to join the domain, it will
  succeed.
  
  [Where problems could occur]
  
  We are changing how domain names are being parsed and converted to valid
  dbus object path names. Domain names can only contain [0-9], [A-Z],
  [a-z], [.], and [-], so by adding '-' to being processed to its
  hexadecimal representation of '_2d', there should be limited scope of
  regressions.
  
  However, if a regression were to occur, then users may not be able to
  use adsys to apply group policy restrictions, and could run into issues
  accessing files, shares and networks.
  
  As mentioned in the impact section, this will be a temporary fix to
  0.9.2 while 0.11.0 is being prepared to be released into the archive,
  which contains the full fix and testsuite coverage. This SRU should
  hopefully be short lived.
  
  [Other Info]
  
  The upstream merge request is:
  
  https://github.com/ubuntu/adsys/pull/498
  
  This was fixed in 0.10.0 by the commit:
  
  commit 5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
  Author: Didier Roche 
  Date:   Tue Nov 15 11:10:51 2022 +0100
  Subject: Fix special characters in domain conversion to dbus object path
  Link: 
https://github.com/ubuntu/adsys/commit/5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
  
  Now, there were some additional commits that added testsuite coverage:
  
  commit cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
  Author: Didier Roche 
  Date:   Tue Nov 15 11:13:03 2022 +0100
  Subject: Refresh golden file now that we properly handle the path.
  Link: 
https://github.com/ubuntu/adsys/commit/cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
  
  commit 4571e39cd724a973270a586d2b18f653f0007de9
  Author: Didier Roche 
  Date:   Tue Nov 15 11:14:35 2022 +0100
  Subject: Use a better case to assert on ServerURL() failure being ignored.
  Link: 
https://github.com/ubuntu/adsys/commit/4571e39cd724a973270a586d2b18f653f0007de9
  
  commit fdca6e462c26e1cbecdb8386f43515c1947d423d
  Author: Didier Roche 
  Date:   Tue Nov 15 11:16:21 2022 +0100
  Subject: Add a separate case for special characters in domain name.
  Link: 
https://github.com/ubuntu/adsys/commit/fdca6e462c26e1cbecdb8386f43515c1947d423d
  
  These commits are not compatible with 0.9.2 due to testsuite harnesses
  and frameworks and test data files not being added until 0.10.0, and
  adding such commits is numerous, and contains too many changes for a
  SRU. Regrettably, the testsuite commits must be omitted.

** Description changed:

  [Impact]
  
  It is common that domain names contain the '-' character, as in "test-
  example.com", and adsys versions 0.9.2 and below cannot parse these
  correctly, leading to the error:
  
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from
  server: error while updating policy: can't get policies for "test-
  example.com": failed to retrieve offline state from SSSD: dbus: invalid
  message: invalid path name
  
  when attempting to run adsys on a system attached to "test-example.com"
  Active Directory.

[Kernel-packages] [Bug 2023955] Re: e1000e: Add support for Tiger Lake and Alder Lake Devices

2023-06-15 Thread Matthew Ruffell

** Description changed:

  BugLink: https://bugs.launchpad.net/bugs/2023955
  
  [Impact]
  
  Due to fips for jammy not being available yet, users with requirements
  to be fips certified or fips compliant have to use focal, and many are
  finding certain hardware devices do not work on their brand new laptops.
  
  I know of several users who use the following laptops who are missing
  Ethernet NIC support. In Sustaining Engineering we started a spreadsheet
  to track them all, and their hardware.
  
  Laptops:
  Dell Precision 7670
  Dell Precision 5560
  
  Ideally we try and get the Ethernet NIC working by enabling PCI IDs for
  the Intel e1000e driver, so users can run focal until jammy-fips is
  available.
  
  [Fix]
  
  commit fb776f5d57ee0f54924fec977657795cb82186dd
  Author: Sasha Neftin 
- Date:   Wed Oct 16 11:08:38 2019 +0300
+ Date: Wed Oct 16 11:08:38 2019 +0300
  Subject: e1000e: Add support for Tiger Lake
+ Link: 
https://github.com/torvalds/linux/commit/fb776f5d57ee0f54924fec977657795cb82186dd
  
  commit 59e466888038dcb84a402b4632c9ffa9dc48f533
  Author: Sasha Neftin 
- Date:   Sun Jan 19 13:57:13 2020 +0200
+ Date: Sun Jan 19 13:57:13 2020 +0200
  Subject: e1000e: Add support for Alder Lake
+ Link: 
https://github.com/torvalds/linux/commit/59e466888038dcb84a402b4632c9ffa9dc48f533
  
  commit 563212224b7e7b7da9a6903dc1a7a41f7e48ac51
  Author: Vitaly Lifshits 
- Date:   Tue Jan 21 15:46:28 2020 -0800
+ Date: Tue Jan 21 15:46:28 2020 -0800
  Subject: e1000e: Add support for Tiger Lake device
+ Link: 
https://github.com/torvalds/linux/commit/563212224b7e7b7da9a6903dc1a7a41f7e48ac51
  
  commit 639e298f432fb058a9496ea16863f53b1ce935fe
  Author: Sasha Neftin 
- Date:   Wed Sep 22 09:55:42 2021 +0300
+ Date: Wed Sep 22 09:55:42 2021 +0300
  Subject: e1000e: Fix packet loss on Tiger Lake and later
+ Link: 
https://github.com/torvalds/linux/commit/639e298f432fb058a9496ea16863f53b1ce935fe
  
  commit ffd24fa2fcc76ecb2e61e7a4ef8588177bcb42a6
  Author: Sasha Neftin 
- Date:   Thu Feb 3 14:21:49 2022 +0200
+ Date: Thu Feb 3 14:21:49 2022 +0200
  Subject: e1000e: Correct NVM checksum verification flow
+ Link: 
https://github.com/torvalds/linux/commit/ffd24fa2fcc76ecb2e61e7a4ef8588177bcb42a6
  
  [Testcase]
  
  Use a laptop with a Intel Tiger Lake or Intel Alder Lake architecture,
  for example:
  
  Dell Precision 7670
  Dell Precision 5560
  
  Start the machine up and see if Ethernet comes up and functions.
  
  There is a test kernel available in the following ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/lp2023955-test
  
  If you install the test kernel and reboot, ethernet should work
  properly.
  
  [Where Problems could occur]
  
  We are enabling hardware support on an older kernel by enabling PCI IDs.
  There will be users out there with currently broken hardware, and by
  enabling the NIC to function, will find that their ethernet will
  suddenly start working. This might be bad if they use wifi or usb
  ethernet and are not expecting network changes. Users can solve this by
  unplugging the ethernet cable.
  
  There is also a chance that in some hardware combinations, there might
  be missing driver support, which causes ethernet to misbehave.
  
  If a regression were to occur, users would need to use the ip command to
  disable their interfaces while a fix is investigated.

** Description changed:

  BugLink: https://bugs.launchpad.net/bugs/2023955
  
  [Impact]
  
  Due to fips for jammy not being available yet, users with requirements
  to be fips certified or fips compliant have to use focal, and many are
  finding certain hardware devices do not work on their brand new laptops.
  
  I know of several users who use the following laptops who are missing
  Ethernet NIC support. In Sustaining Engineering we started a spreadsheet
  to track them all, and their hardware.
  
  Laptops:
  Dell Precision 7670
  Dell Precision 5560
+ Dell Latitude 7230 Rugged Extreme
  
  Ideally we try and get the Ethernet NIC working by enabling PCI IDs for
  the Intel e1000e driver, so users can run focal until jammy-fips is
  available.
  
  [Fix]
  
  commit fb776f5d57ee0f54924fec977657795cb82186dd
  Author: Sasha Neftin 
  Date: Wed Oct 16 11:08:38 2019 +0300
  Subject: e1000e: Add support for Tiger Lake
  Link: 
https://github.com/torvalds/linux/commit/fb776f5d57ee0f54924fec977657795cb82186dd
  
  commit 59e466888038dcb84a402b4632c9ffa9dc48f533
  Author: Sasha Neftin 
  Date: Sun Jan 19 13:57:13 2020 +0200
  Subject: e1000e: Add support for Alder Lake
  Link: 
https://github.com/torvalds/linux/commit/59e466888038dcb84a402b4632c9ffa9dc48f533
  
  commit 563212224b7e7b7da9a6903dc1a7a41f7e48ac51
  Author: Vitaly Lifshits 
  Date: Tue Jan 21 15:46:28 2020 -0800
  Subject: e1000e: Add support for Tiger Lake device
  Link: 
https://github.com/torvalds/linux/commit/563212224b7e7b7da9a6903dc1a7a41f7e48ac51
  
  commit 639e298f432fb058a9496ea16863f53b1ce935fe
  Author: Sasha Neftin 
  Date: Wed

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-06-15 Thread Matthew Ruffell

Attached is a v4 for Jammy that updates the version to ubuntu0.1 in both
d/changelog and d/tracker-extract.postinst

** Patch added: "Debdiff for tracker-miners on Jammy V4"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5680090/+files/lp1779890_jammy_v4.debdiff

** Patch removed: "Debdiff for tracker-miners on Jammy V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679385/+files/lp1779890_jammy_v3.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  Invalid
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  Invalid
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  Invalid
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  Invalid
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  Invalid
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-06-15 Thread Matthew Ruffell

Attached is a v4 for Jammy that updates the version to ubuntu0.1 in both
d/changelog and d/tracker-extract.postinst

** Patch added: "Debdiff for tracker-miners on Jammy V4"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5680090/+files/lp1779890_jammy_v4.debdiff

** Patch removed: "Debdiff for tracker-miners on Jammy V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679385/+files/lp1779890_jammy_v3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Kernel-packages] [Bug 2023955] [NEW] e1000e: Add support for Tiger Lake and Alder Lake Devices

2023-06-14 Thread Matthew Ruffell

Public bug reported:

BugLink: https://bugs.launchpad.net/bugs/2023955

[Impact]

Due to fips for jammy not being available yet, users with requirements
to be fips certified or fips compliant have to use focal, and many are
finding certain hardware devices do not work on their brand new laptops.

I know of several users who use the following laptops who are missing
Ethernet NIC support. In Sustaining Engineering we started a spreadsheet
to track them all, and their hardware.

Laptops:
Dell Precision 7670
Dell Precision 5560

Ideally we try and get the Ethernet NIC working by enabling PCI IDs for
the Intel e1000e driver, so users can run focal until jammy-fips is
available.

[Fix]

commit fb776f5d57ee0f54924fec977657795cb82186dd
Author: Sasha Neftin 
Date:   Wed Oct 16 11:08:38 2019 +0300
Subject: e1000e: Add support for Tiger Lake

commit 59e466888038dcb84a402b4632c9ffa9dc48f533
Author: Sasha Neftin 
Date:   Sun Jan 19 13:57:13 2020 +0200
Subject: e1000e: Add support for Alder Lake

commit 563212224b7e7b7da9a6903dc1a7a41f7e48ac51
Author: Vitaly Lifshits 
Date:   Tue Jan 21 15:46:28 2020 -0800
Subject: e1000e: Add support for Tiger Lake device

commit 639e298f432fb058a9496ea16863f53b1ce935fe
Author: Sasha Neftin 
Date:   Wed Sep 22 09:55:42 2021 +0300
Subject: e1000e: Fix packet loss on Tiger Lake and later

commit ffd24fa2fcc76ecb2e61e7a4ef8588177bcb42a6
Author: Sasha Neftin 
Date:   Thu Feb 3 14:21:49 2022 +0200
Subject: e1000e: Correct NVM checksum verification flow

[Testcase]

Use a laptop with a Intel Tiger Lake or Intel Alder Lake architecture,
for example:

Dell Precision 7670
Dell Precision 5560

Start the machine up and see if Ethernet comes up and functions.

There is a test kernel available in the following ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/lp2023955-test

If you install the test kernel and reboot, ethernet should work
properly.

[Where Problems could occur]

We are enabling hardware support on an older kernel by enabling PCI IDs.
There will be users out there with currently broken hardware, and by
enabling the NIC to function, will find that their ethernet will
suddenly start working. This might be bad if they use wifi or usb
ethernet and are not expecting network changes. Users can solve this by
unplugging the ethernet cable.

There is also a chance that in some hardware combinations, there might
be missing driver support, which causes ethernet to misbehave.

If a regression were to occur, users would need to use the ip command to
disable their interfaces while a fix is investigated.

** 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 (Ubuntu Focal)
   Importance: Undecided
   Status: New

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

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

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Tags added: sts

** Description changed:

- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs.launchpad.net/bugs/2023955
  
  [Impact]
  
  Due to fips for jammy not being available yet, users with requirements
  to be fips certified or fips compliant have to use focal, and many are
  finding certain hardware devices do not work on their brand new laptops.
  
  I know of several users who use the following laptops who are missing
  Ethernet NIC support. In Sustaining Engineering we started a spreadsheet
  to track them all, and their hardware.
  
  Laptops:
  Dell Precision 7670
  Dell Precision 5560
  
  Ideally we try and get the Ethernet NIC working by enabling PCI IDs for
  the Intel e1000e driver, so users can run focal until jammy-fips is
  available.
  
  [Fix]
  
  commit fb776f5d57ee0f54924fec977657795cb82186dd
  Author: Sasha Neftin 
  Date:   Wed Oct 16 11:08:38 2019 +0300
  Subject: e1000e: Add support for Tiger Lake
- 
+ 
  commit 59e466888038dcb84a402b4632c9ffa9dc48f533
  Author: Sasha Neftin 
  Date:   Sun Jan 19 13:57:13 2020 +0200
  Subject: e1000e: Add support for Alder Lake
- 
+ 
  commit 563212224b7e7b7da9a6903dc1a7a41f7e48ac51
  Author: Vitaly Lifshits 
  Date:   Tue Jan 21 15:46:28 2020 -0800
  Subject: e1000e: Add support for Tiger Lake device
- 
+ 
  commit 639e298f432fb058a9496ea16863f53b1ce935fe
  Author: Sasha Neftin 
  Date:   Wed Sep 22 09:55:42 2021 +0300
  Subject: e1000e: Fix packet loss on Tiger Lake and later
  
  commit ffd24fa2fcc76ecb2e61e7a4ef8588177bcb42a6
  Author: Sasha Neftin 
  Date:   Thu Feb 3 14:21:49 2022 +0200
  Subject: e1000e: Correct NVM checksum verification flow
  
  [Testcase]
  
  Use a laptop with a Intel Tiger Lake or Intel Alder Lake architecture,
  for example:
  
  Dell Precision

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Mantic that fixes this issue

** Patch added: "Debdiff for tracker-miners on Mantic V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679388/+files/lp1779890_mantic_v3.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  Invalid
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  Invalid
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  Invalid
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  Invalid
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  Invalid
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link:

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Lunar that fixes this issue

** Patch added: "Debdiff for tracker-miners on Lunar V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679387/+files/lp1779890_lunar_v3.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  Invalid
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  Invalid
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  Invalid
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  Invalid
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  Invalid
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link:

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Mantic that fixes this issue

** Patch added: "Debdiff for tracker-miners on Mantic V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679388/+files/lp1779890_mantic_v3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Kinetic that fixes this issue

** Patch added: "Debdiff for tracker-miners on Kinetic V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679386/+files/lp1779890_kinetic_v3.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  Invalid
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  Invalid
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  Invalid
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  Invalid
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  Invalid
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link:

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Lunar that fixes this issue

** Patch added: "Debdiff for tracker-miners on Lunar V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679387/+files/lp1779890_lunar_v3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Jammy that fixes this issue

** Patch added: "Debdiff for tracker-miners on Jammy V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679385/+files/lp1779890_jammy_v3.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  Invalid
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  Invalid
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  Invalid
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  Invalid
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  Invalid
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link:

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Kinetic that fixes this issue

** Patch added: "Debdiff for tracker-miners on Kinetic V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679386/+files/lp1779890_kinetic_v3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Focal that fixes this issue

** Patch removed: "debdiff for tracker-miners on jammy"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663488/+files/lp1779890_jammy_v2.debdiff

** Patch removed: "debdiff for tracker-miners on kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663489/+files/lp1779890_kinetic_v2.debdiff

** Patch removed: "debdiff for tracker-miners on Focal V2"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5665098/+files/lp1779890_focal_v2.debdiff

** Patch added: "Debdiff for tracker-miners on Focal V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679384/+files/lp1779890_focal_v3.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  Invalid
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  Invalid
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  Invalid
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  Invalid
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  Invalid
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Jammy that fixes this issue

** Patch added: "Debdiff for tracker-miners on Jammy V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679385/+files/lp1779890_jammy_v3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a V3 debdiff for Focal that fixes this issue

** Patch removed: "debdiff for tracker-miners on jammy"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663488/+files/lp1779890_jammy_v2.debdiff

** Patch removed: "debdiff for tracker-miners on kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663489/+files/lp1779890_kinetic_v2.debdiff

** Patch removed: "debdiff for tracker-miners on Focal V2"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5665098/+files/lp1779890_focal_v2.debdiff

** Patch added: "Debdiff for tracker-miners on Focal V3"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5679384/+files/lp1779890_focal_v3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

2023-06-07 Thread Matthew Ruffell

Hi Paul,

Yes, if we look at https://kernel.ubuntu.com/sru/dashboards/web/kernel-
stable-board.html under 2023.05.15 SRU cycle, under Jammy it has linux-
hwe-5.19 5.19.0-44.45~22.04.1 sitting in -proposed, so yes, this fix
will be made available to kinetic and jammy-hwe.

Saying that, the dashboard also lists 5.19.0-45 for both, but still in
the preparation stage and not pushed to -proposed yet. I looked up the
code, and 5.19.0-45 only has one patch ontop of 5.19.0-44, which is a
fix to https://bugs.launchpad.net/bugs/2020599, fixing a regression in
WPA offload.

commit 3358af2b077f8e90461a9a8941e8292b995db63b
Author: Hector Martin 
Date:   Sat Mar 11 23:19:14 2023 +0900
wifi: cfg80211: Partial revert "wifi: cfg80211: Fix use after free for wext"
BugLink: https://bugs.launchpad.net/bugs/2020599

I think the kernel team will probably get 5.19.0-45 into -proposed as
soon as they can, and this will likely be the kernel that will be
released next week.

You won't need to re-verify, since its the same as 5.19.0-44 with a
single patch ontop.

Thanks,
Matthew

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

Title:
  vmwgfx fails to reserve graphics buffer on aarch64 leading to blank
  display

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007001

  [Impact]

  Numerous VMWare users have reported that vmwgfx cannot reserve the
  memory region for the graphics framebuffer, leading their VMs to have
  blank screens.

  They see the following in dmesg:

  [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
  [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16

  And a cat /proc/iomem shows this:

  5000-7fff : PCI Bus :00
7000-77ff : :00:0f.0
  7000-702f : BOOTFB

  The kernel has failed to release this memory region for vmwgfx to
  occupy.

  Most affected users are on aarch64, with the host being Apple silicon
  systems.

  [Fix]

  The regression was introduced by the below commit in
  5.19.0-30-generic:

  commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
  Author: Thomas Zimmermann 
  Date: Mon Jul 18 09:23:18 2022 +0200
  Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
  Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

  This commit was part of a larger refactoring of the video subsystem,
  and requires the entire series to function correctly. You can review
  the whole series below:

  https://patchwork.freedesktop.org/series/106040/

  The patch series also requires quite a few additional fixups to fix
  bugs introduced by the series, making the size about 15 commits in
  total. The contents of the series don't really fix any bugs, and their
  purpose is to refactor the code for future changes to the fbdev
  subsystem, and really aren't appropriate to be backported to a stable
  kernel series.

  "video/aperture: Disable and unregister sysfb devices via aperture
  helpers" seems to have been selected for -stable by mistake by its
  fixes: tag, and was pulled into upstream stable by a robot with little
  human review.

  The best course of action is to revert. No action needed for Lunar, as
  the entire series is present in that release.

  [Testcase]

  This bug affects users running Ubuntu in VMWare VMs, notably on
  aarch64 devices, like modern Apple computers.

  Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
  Apple silicon, and see if the display comes up or not.

  Affected users will see a blank screen.

  There is a test kernel available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2007001-test

  If you install the test kernel and reboot, you will be able to see the
  screen on your VM like normal.

  [Where problems could occur]

  This commit changes when the sysfb is disabled and memory region for
  the graphics framebuffer is released to the proper device driver.

  If a regression were to occur, then graphics drivers may fail to
  reserve the framebuffer memory, and fail to start, leaving users with
  a blank screen.

  There are no workarounds, other than booting a previous kernel.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

2023-06-07 Thread Matthew Ruffell

Hi Paul,

Thanks for verifying that linux-nvidia kernel, but for the future, you
don't need to worry about verifying each and every kernel series. These
days, the kernel team maintains over 100 kernel variants, and it is
simply impossible to check them all.

We just check the primary ones, e.g. 5.19 in kinetic, and then when they
are made into their specific derivative kernels, e.g. 5.19 linux-nvidia,
they contain all the patches from the primary kernel, plus some specific
patches to enable whatever hardware the derivative kernel is for.

So, don't worry if there are any more from other odd kernel
combinations, I will let you know if we need to do any more testing.

In other news, looking at https://kernel.ubuntu.com/, we should be on
track for a release to -updates early next week, so look forward to that
and getting this bug fixed for everyone.

Thanks,
Matthew

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

Title:
  vmwgfx fails to reserve graphics buffer on aarch64 leading to blank
  display

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007001

  [Impact]

  Numerous VMWare users have reported that vmwgfx cannot reserve the
  memory region for the graphics framebuffer, leading their VMs to have
  blank screens.

  They see the following in dmesg:

  [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
  [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16

  And a cat /proc/iomem shows this:

  5000-7fff : PCI Bus :00
7000-77ff : :00:0f.0
  7000-702f : BOOTFB

  The kernel has failed to release this memory region for vmwgfx to
  occupy.

  Most affected users are on aarch64, with the host being Apple silicon
  systems.

  [Fix]

  The regression was introduced by the below commit in
  5.19.0-30-generic:

  commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
  Author: Thomas Zimmermann 
  Date: Mon Jul 18 09:23:18 2022 +0200
  Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
  Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

  This commit was part of a larger refactoring of the video subsystem,
  and requires the entire series to function correctly. You can review
  the whole series below:

  https://patchwork.freedesktop.org/series/106040/

  The patch series also requires quite a few additional fixups to fix
  bugs introduced by the series, making the size about 15 commits in
  total. The contents of the series don't really fix any bugs, and their
  purpose is to refactor the code for future changes to the fbdev
  subsystem, and really aren't appropriate to be backported to a stable
  kernel series.

  "video/aperture: Disable and unregister sysfb devices via aperture
  helpers" seems to have been selected for -stable by mistake by its
  fixes: tag, and was pulled into upstream stable by a robot with little
  human review.

  The best course of action is to revert. No action needed for Lunar, as
  the entire series is present in that release.

  [Testcase]

  This bug affects users running Ubuntu in VMWare VMs, notably on
  aarch64 devices, like modern Apple computers.

  Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
  Apple silicon, and see if the display comes up or not.

  Affected users will see a blank screen.

  There is a test kernel available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2007001-test

  If you install the test kernel and reboot, you will be able to see the
  screen on your VM like normal.

  [Where problems could occur]

  This commit changes when the sysfb is disabled and memory region for
  the graphics framebuffer is released to the proper device driver.

  If a regression were to occur, then graphics drivers may fail to
  reserve the framebuffer memory, and fail to start, leaving users with
  a blank screen.

  There are no workarounds, other than booting a previous kernel.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Sts-sponsors] Please review and sponsor adsys for LP#2020834

2023-06-02 Thread Matthew Ruffell

Hi Heitor,

Denison Barbosa is the one who is coordinating the release of not
0.11.0, this literally this morning got changed to 0.12.0. Current
plans are to only go back to Jammy, leaving Focal behind. This is
going to -updates.

I have written to Denison for some more clarification on how long it
is going to take to get things released.

How about we put this one on hold, at least until next week. I also
don't want to block Denison from landing 0.12.0 in -proposed. AWS can
wait a few more days.

Thanks,
Matthew

On Fri, 2 Jun 2023 at 06:01, Heitor Alves de Siqueira
 wrote:
>
> Hey Matthew,
>
> I've taken a look at this, and overall your patches look good. I've added an 
> author attribution for Didier Roche to d/changelog as he's the original 
> author of the patch, but kept your changes as-is otherwise.
> I'd like to clear out a few points on the "0.11.0 being backported" 
> situation, just so we don't risk trampling over a future upload for adsys:
>
> - do you know who's doing the 0.11 backport to F/J/K? is this being 
> coordinated with SEG/you?
> - is it going to land as a regular package in -updates, or is it going to be 
> available through -backports?
> - is there any timeframe on when 0.11.0 would be made available? (i.e. would 
> waiting for that release with a hotfix be an appropriate alternative in this 
> case, or not because AWS is being AWS)
>
> If those aren't an issue, I have the package sources ready to go and will 
> upload them tomorrow. Thanks again for the help!
>
> Cheers,
> Heitor
>
> On Tue, May 30, 2023 at 2:16 AM Matthew Ruffell 
>  wrote:
>>
>> Hi everyone,
>>
>> Can you please review and sponsor adsys in LP #2020834?
>>
>> https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834
>>
>> The package unfortunately uses d/source/format of "3.0 (native)" over
>> "3.0 (quilt)", so the debdiffs are created in native form not using
>> quilt.
>>
>> If this is incorrect, let me know, I have properly dep3 tagged
>> patches, but just need to know how to apply them since I can't use
>> quilt.
>>
>> There is 0.11.0 being backported to F/J/K, but AWS are in a real hurry
>> to get this fixed, so here we are.
>>
>> Thanks,
>> Matthew
>>
>> --
>> Mailing list: https://launchpad.net/~sts-sponsors
>> Post to : sts-sponsors@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~sts-sponsors
>> More help   : https://help.launchpad.net/ListHelp

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2020834] Re: Properly convert DNS names with '-' characters to valid dbus object paths

2023-05-29 Thread Matthew Ruffell

** Tags added: sts-sponsor

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad.net/bugs/2020834

Title:
  Properly convert DNS names with '-' characters to valid dbus object
  paths

Status in adsys package in Ubuntu:
  Fix Released
Status in adsys source package in Focal:
  In Progress
Status in adsys source package in Jammy:
  In Progress
Status in adsys source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  It is common that domain names contain the '-' character, as in "test-
  example.com", and adsys versions 0.9.2 and below cannot parse these
  correctly, leading to the error:

  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error
  from server: error while updating policy: can't get policies for
  "test-example.com": failed to retrieve offline state from SSSD: dbus:
  invalid message: invalid path name

  when attempting to run adsys on a system attached to "test-
  example.com" Active Directory.

  Currently, 0.9.2 only changes '.' into '_2e', and this would change
  all special characters to use their hexadecimal representations,
  notably '-' becomes '_2d'.

  There is plans from Foundations + Desktop to SRU 0.11.0 back to at
  least Jammy, documented in bug 2020682 which depends on golang 1.20 to
  be included in the jammy archive, documented in bug 2020658. However,
  this fixup is required with high priority while the 0.11.0 release is
  being prepared, and the SRU will hopefully bridge a few weeks between
  SRU release to release of 0.11.0.

  [Testcase]

  Start a Windows Server VM, 2022 will be fine, and create an Active
  Directory with the domain "test-example.com".

  Launch a Focal, or Jammy, or Kinetic VM, and use SSSD to join the
  domain.

  Try to enable adsys:

  $ sudo apt install adsys
  $ adsysctl update
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from 
server: error while updating policy: can't get policies for "test-example.com": 
failed to retrieve offline state from SSSD: dbus: invalid message: invalid path 
name

  There are test packages in the below ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf360012-test

  If you install the test package and retry to join the domain, it will
  succeed.

  [Where problems could occur]

  We are changing how domain names are being parsed and converted to
  valid dbus object path names. Domain names can only contain [0-9],
  [A-Z], [a-z], [.], and [-], so by adding '-' to being processed to its
  hexadecimal representation of '_2d', there should be limited scope of
  regressions.

  However, if a regression were to occur, then users may not be able to
  use adsys to apply group policy restrictions, and could run into
  issues accessing files, shares and networks.

  As mentioned in the impact section, this will be a temporary fix to
  0.9.2 while 0.11.0 is being prepared to be released into the archive,
  which contains the full fix and testsuite coverage. This SRU should
  hopefully be short lived.

  [Other Info]

  The upstream merge request is:

  https://github.com/ubuntu/adsys/pull/498

  This was fixed in 0.10.0 by the commit:

  commit 5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
  Author: Didier Roche 
  Date:   Tue Nov 15 11:10:51 2022 +0100
  Subject: Fix special characters in domain conversion to dbus object path
  Link: 
https://github.com/ubuntu/adsys/commit/5752ba87347d7813dd56bc6a9ec6369ec56e5dc4

  Now, there were some additional commits that added testsuite coverage:

  commit cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
  Author: Didier Roche 
  Date:   Tue Nov 15 11:13:03 2022 +0100
  Subject: Refresh golden file now that we properly handle the path.
  Link: 
https://github.com/ubuntu/adsys/commit/cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540

  commit 4571e39cd724a973270a586d2b18f653f0007de9
  Author: Didier Roche 
  Date:   Tue Nov 15 11:14:35 2022 +0100
  Subject: Use a better case to assert on ServerURL() failure being ignored.
  Link: 
https://github.com/ubuntu/adsys/commit/4571e39cd724a973270a586d2b18f653f0007de9

  commit fdca6e462c26e1cbecdb8386f43515c1947d423d
  Author: Didier Roche 
  Date:   Tue Nov 15 11:16:21 2022 +0100
  Subject: Add a separate case for special characters in domain name.
  Link: 
https://github.com/ubuntu/adsys/commit/fdca6e462c26e1cbecdb8386f43515c1947d423d

  These commits are not compatible with 0.9.2 due to testsuite harnesses
  and frameworks and test data files not being added until 0.10.0, and
  adding such commits is numerous, and contains too many changes for a
  SRU. Regrettably, the testsuite commits must be omitted.

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


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   :

[Sts-sponsors] Please review and sponsor adsys for LP#2020834

2023-05-29 Thread Matthew Ruffell

Hi everyone,

Can you please review and sponsor adsys in LP #2020834?

https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834

The package unfortunately uses d/source/format of "3.0 (native)" over
"3.0 (quilt)", so the debdiffs are created in native form not using
quilt.

If this is incorrect, let me know, I have properly dep3 tagged
patches, but just need to know how to apply them since I can't use
quilt.

There is 0.11.0 being backported to F/J/K, but AWS are in a real hurry
to get this fixed, so here we are.

Thanks,
Matthew

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] Please review needrestart for LP #2020826

2023-05-28 Thread Matthew Ruffell

Hi everyone,

Can you please review and sponsor needrestart for LP2020826?

https://bugs.launchpad.net/ubuntu/+source/needrestart/+bug/2020826

Its pretty self explanatory. Test packages work great.

Thanks!
Matthew

ps, I will start my sru-developer application soon...

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2020834] Re: Properly convert DNS names with '-' characters to valid dbus object paths

Attached is a debdiff for Jammy. Note the package uses a
debian/source/format of "3.0 (native)", and I did not use quilt to
prepare the patch.

** Patch added: "Debdiff for adsys on Jammy"
   
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834/+attachment/5675740/+files/lp2020834_jammy.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad.net/bugs/2020834

Title:
  Properly convert DNS names with '-' characters to valid dbus object
  paths

Status in adsys package in Ubuntu:
  Fix Released
Status in adsys source package in Focal:
  In Progress
Status in adsys source package in Jammy:
  In Progress
Status in adsys source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  It is common that domain names contain the '-' character, as in "test-
  example.com", and adsys versions 0.9.2 and below cannot parse these
  correctly, leading to the error:

  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error
  from server: error while updating policy: can't get policies for
  "test-example.com": failed to retrieve offline state from SSSD: dbus:
  invalid message: invalid path name

  when attempting to run adsys on a system attached to "test-
  example.com" Active Directory.

  Currently, 0.9.2 only changes '.' into '_2e', and this would change
  all special characters to use their hexadecimal representations,
  notably '-' becomes '_2d'.

  There is plans from Foundations + Desktop to SRU 0.11.0 back to at
  least Jammy, documented in bug 2020682 which depends on golang 1.20 to
  be included in the jammy archive, documented in bug 2020658. However,
  this fixup is required with high priority while the 0.11.0 release is
  being prepared, and the SRU will hopefully bridge a few weeks between
  SRU release to release of 0.11.0.

  [Testcase]

  Start a Windows Server VM, 2022 will be fine, and create an Active
  Directory with the domain "test-example.com".

  Launch a Focal, or Jammy, or Kinetic VM, and use SSSD to join the
  domain.

  Try to enable adsys:

  $ sudo apt install adsys
  $ adsysctl update
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from 
server: error while updating policy: can't get policies for "test-example.com": 
failed to retrieve offline state from SSSD: dbus: invalid message: invalid path 
name

  There are test packages in the below ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf360012-test

  If you install the test package and retry to join the domain, it will
  succeed.

  [Where problems could occur]

  We are changing how domain names are being parsed and converted to
  valid dbus object path names. Domain names can only contain [0-9],
  [A-Z], [a-z], [.], and [-], so by adding '-' to being processed to its
  hexadecimal representation of '_2d', there should be limited scope of
  regressions.

  However, if a regression were to occur, then users may not be able to
  use adsys to apply group policy restrictions, and could run into
  issues accessing files, shares and networks.

  As mentioned in the impact section, this will be a temporary fix to
  0.9.2 while 0.11.0 is being prepared to be released into the archive,
  which contains the full fix and testsuite coverage. This SRU should
  hopefully be short lived.

  [Other Info]

  The upstream merge request is:

  https://github.com/ubuntu/adsys/pull/498

  This was fixed in 0.10.0 by the commit:

  commit 5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
  Author: Didier Roche 
  Date:   Tue Nov 15 11:10:51 2022 +0100
  Subject: Fix special characters in domain conversion to dbus object path
  Link: 
https://github.com/ubuntu/adsys/commit/5752ba87347d7813dd56bc6a9ec6369ec56e5dc4

  Now, there were some additional commits that added testsuite coverage:

  commit cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
  Author: Didier Roche 
  Date:   Tue Nov 15 11:13:03 2022 +0100
  Subject: Refresh golden file now that we properly handle the path.
  Link: 
https://github.com/ubuntu/adsys/commit/cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540

  commit 4571e39cd724a973270a586d2b18f653f0007de9
  Author: Didier Roche 
  Date:   Tue Nov 15 11:14:35 2022 +0100
  Subject: Use a better case to assert on ServerURL() failure being ignored.
  Link: 
https://github.com/ubuntu/adsys/commit/4571e39cd724a973270a586d2b18f653f0007de9

  commit fdca6e462c26e1cbecdb8386f43515c1947d423d
  Author: Didier Roche 
  Date:   Tue Nov 15 11:16:21 2022 +0100
  Subject: Add a separate case for special characters in domain name.
  Link: 
https://github.com/ubuntu/adsys/commit/fdca6e462c26e1cbecdb8386f43515c1947d423d

  These commits are not compatible with 0.9.2 due to testsuite harnesses
  and frameworks and test data files not being added until 0.10.0, and
  adding such commits is numerous, and contains too many changes for a
  SRU. Regrettably, the testsuite commits must be omitted.

To manage notifications about

[Desktop-packages] [Bug 2020834] Re: Properly convert DNS names with '-' characters to valid dbus object paths

Attached is a debdiff for Focal. Note the package uses a
debian/source/format of "3.0 (native)", and I did not use quilt to
prepare the patch.

** Patch added: "Debdiff for adsys on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834/+attachment/5675741/+files/lp2020834_focal.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad.net/bugs/2020834

Title:
  Properly convert DNS names with '-' characters to valid dbus object
  paths

Status in adsys package in Ubuntu:
  Fix Released
Status in adsys source package in Focal:
  In Progress
Status in adsys source package in Jammy:
  In Progress
Status in adsys source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  It is common that domain names contain the '-' character, as in "test-
  example.com", and adsys versions 0.9.2 and below cannot parse these
  correctly, leading to the error:

  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error
  from server: error while updating policy: can't get policies for
  "test-example.com": failed to retrieve offline state from SSSD: dbus:
  invalid message: invalid path name

  when attempting to run adsys on a system attached to "test-
  example.com" Active Directory.

  Currently, 0.9.2 only changes '.' into '_2e', and this would change
  all special characters to use their hexadecimal representations,
  notably '-' becomes '_2d'.

  There is plans from Foundations + Desktop to SRU 0.11.0 back to at
  least Jammy, documented in bug 2020682 which depends on golang 1.20 to
  be included in the jammy archive, documented in bug 2020658. However,
  this fixup is required with high priority while the 0.11.0 release is
  being prepared, and the SRU will hopefully bridge a few weeks between
  SRU release to release of 0.11.0.

  [Testcase]

  Start a Windows Server VM, 2022 will be fine, and create an Active
  Directory with the domain "test-example.com".

  Launch a Focal, or Jammy, or Kinetic VM, and use SSSD to join the
  domain.

  Try to enable adsys:

  $ sudo apt install adsys
  $ adsysctl update
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from 
server: error while updating policy: can't get policies for "test-example.com": 
failed to retrieve offline state from SSSD: dbus: invalid message: invalid path 
name

  There are test packages in the below ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf360012-test

  If you install the test package and retry to join the domain, it will
  succeed.

  [Where problems could occur]

  We are changing how domain names are being parsed and converted to
  valid dbus object path names. Domain names can only contain [0-9],
  [A-Z], [a-z], [.], and [-], so by adding '-' to being processed to its
  hexadecimal representation of '_2d', there should be limited scope of
  regressions.

  However, if a regression were to occur, then users may not be able to
  use adsys to apply group policy restrictions, and could run into
  issues accessing files, shares and networks.

  As mentioned in the impact section, this will be a temporary fix to
  0.9.2 while 0.11.0 is being prepared to be released into the archive,
  which contains the full fix and testsuite coverage. This SRU should
  hopefully be short lived.

  [Other Info]

  The upstream merge request is:

  https://github.com/ubuntu/adsys/pull/498

  This was fixed in 0.10.0 by the commit:

  commit 5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
  Author: Didier Roche 
  Date:   Tue Nov 15 11:10:51 2022 +0100
  Subject: Fix special characters in domain conversion to dbus object path
  Link: 
https://github.com/ubuntu/adsys/commit/5752ba87347d7813dd56bc6a9ec6369ec56e5dc4

  Now, there were some additional commits that added testsuite coverage:

  commit cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
  Author: Didier Roche 
  Date:   Tue Nov 15 11:13:03 2022 +0100
  Subject: Refresh golden file now that we properly handle the path.
  Link: 
https://github.com/ubuntu/adsys/commit/cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540

  commit 4571e39cd724a973270a586d2b18f653f0007de9
  Author: Didier Roche 
  Date:   Tue Nov 15 11:14:35 2022 +0100
  Subject: Use a better case to assert on ServerURL() failure being ignored.
  Link: 
https://github.com/ubuntu/adsys/commit/4571e39cd724a973270a586d2b18f653f0007de9

  commit fdca6e462c26e1cbecdb8386f43515c1947d423d
  Author: Didier Roche 
  Date:   Tue Nov 15 11:16:21 2022 +0100
  Subject: Add a separate case for special characters in domain name.
  Link: 
https://github.com/ubuntu/adsys/commit/fdca6e462c26e1cbecdb8386f43515c1947d423d

  These commits are not compatible with 0.9.2 due to testsuite harnesses
  and frameworks and test data files not being added until 0.10.0, and
  adding such commits is numerous, and contains too many changes for a
  SRU. Regrettably, the testsuite commits must be omitted.

To manage notifications about

[Desktop-packages] [Bug 2020834] Re: Properly convert DNS names with '-' characters to valid dbus object paths

Attached is a debdiff for Kinetic. Note the package uses a
debian/source/format of "3.0 (native)", and I did not use quilt to
prepare the patch.

** Patch added: "Debdiff for adsys on Kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/adsys/+bug/2020834/+attachment/5675739/+files/lp2020834_kinetic.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to adsys in Ubuntu.
https://bugs.launchpad.net/bugs/2020834

Title:
  Properly convert DNS names with '-' characters to valid dbus object
  paths

Status in adsys package in Ubuntu:
  Fix Released
Status in adsys source package in Focal:
  In Progress
Status in adsys source package in Jammy:
  In Progress
Status in adsys source package in Kinetic:
  In Progress

Bug description:
  [Impact]

  It is common that domain names contain the '-' character, as in "test-
  example.com", and adsys versions 0.9.2 and below cannot parse these
  correctly, leading to the error:

  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error
  from server: error while updating policy: can't get policies for
  "test-example.com": failed to retrieve offline state from SSSD: dbus:
  invalid message: invalid path name

  when attempting to run adsys on a system attached to "test-
  example.com" Active Directory.

  Currently, 0.9.2 only changes '.' into '_2e', and this would change
  all special characters to use their hexadecimal representations,
  notably '-' becomes '_2d'.

  There is plans from Foundations + Desktop to SRU 0.11.0 back to at
  least Jammy, documented in bug 2020682 which depends on golang 1.20 to
  be included in the jammy archive, documented in bug 2020658. However,
  this fixup is required with high priority while the 0.11.0 release is
  being prepared, and the SRU will hopefully bridge a few weeks between
  SRU release to release of 0.11.0.

  [Testcase]

  Start a Windows Server VM, 2022 will be fine, and create an Active
  Directory with the domain "test-example.com".

  Launch a Focal, or Jammy, or Kinetic VM, and use SSSD to join the
  domain.

  Try to enable adsys:

  $ sudo apt install adsys
  $ adsysctl update
  ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from 
server: error while updating policy: can't get policies for "test-example.com": 
failed to retrieve offline state from SSSD: dbus: invalid message: invalid path 
name

  There are test packages in the below ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf360012-test

  If you install the test package and retry to join the domain, it will
  succeed.

  [Where problems could occur]

  We are changing how domain names are being parsed and converted to
  valid dbus object path names. Domain names can only contain [0-9],
  [A-Z], [a-z], [.], and [-], so by adding '-' to being processed to its
  hexadecimal representation of '_2d', there should be limited scope of
  regressions.

  However, if a regression were to occur, then users may not be able to
  use adsys to apply group policy restrictions, and could run into
  issues accessing files, shares and networks.

  As mentioned in the impact section, this will be a temporary fix to
  0.9.2 while 0.11.0 is being prepared to be released into the archive,
  which contains the full fix and testsuite coverage. This SRU should
  hopefully be short lived.

  [Other Info]

  The upstream merge request is:

  https://github.com/ubuntu/adsys/pull/498

  This was fixed in 0.10.0 by the commit:

  commit 5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
  Author: Didier Roche 
  Date:   Tue Nov 15 11:10:51 2022 +0100
  Subject: Fix special characters in domain conversion to dbus object path
  Link: 
https://github.com/ubuntu/adsys/commit/5752ba87347d7813dd56bc6a9ec6369ec56e5dc4

  Now, there were some additional commits that added testsuite coverage:

  commit cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
  Author: Didier Roche 
  Date:   Tue Nov 15 11:13:03 2022 +0100
  Subject: Refresh golden file now that we properly handle the path.
  Link: 
https://github.com/ubuntu/adsys/commit/cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540

  commit 4571e39cd724a973270a586d2b18f653f0007de9
  Author: Didier Roche 
  Date:   Tue Nov 15 11:14:35 2022 +0100
  Subject: Use a better case to assert on ServerURL() failure being ignored.
  Link: 
https://github.com/ubuntu/adsys/commit/4571e39cd724a973270a586d2b18f653f0007de9

  commit fdca6e462c26e1cbecdb8386f43515c1947d423d
  Author: Didier Roche 
  Date:   Tue Nov 15 11:16:21 2022 +0100
  Subject: Add a separate case for special characters in domain name.
  Link: 
https://github.com/ubuntu/adsys/commit/fdca6e462c26e1cbecdb8386f43515c1947d423d

  These commits are not compatible with 0.9.2 due to testsuite harnesses
  and frameworks and test data files not being added until 0.10.0, and
  adding such commits is numerous, and contains too many changes for a
  SRU. Regrettably, the testsuite commits must be omitted.

To manage notifications

[Desktop-packages] [Bug 2020834] [NEW] Properly convert DNS names with '-' characters to valid dbus object paths

Public bug reported:

[Impact]

It is common that domain names contain the '-' character, as in "test-
example.com", and adsys versions 0.9.2 and below cannot parse these
correctly, leading to the error:

ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from
server: error while updating policy: can't get policies for "test-
example.com": failed to retrieve offline state from SSSD: dbus: invalid
message: invalid path name

when attempting to run adsys on a system attached to "test-example.com"
Active Directory.

Currently, 0.9.2 only changes '.' into '_2e', and this would change all
special characters to use their hexadecimal representations, notably '-'
becomes '_2d'.

There is plans from Foundations + Desktop to SRU 0.11.0 back to at least
Jammy, documented in bug 2020682 which depends on golang 1.20 to be
included in the jammy archive, documented in bug 2020658. However, this
fixup is required with high priority while the 0.11.0 release is being
prepared, and the SRU will hopefully bridge a few weeks between SRU
release to release of 0.11.0.

[Testcase]

Start a Windows Server VM, 2022 will be fine, and create an Active
Directory with the domain "test-example.com".

Launch a Focal, or Jammy, or Kinetic VM, and use SSSD to join the
domain.

Try to enable adsys:

$ sudo apt install adsys
$ adsysctl update
ERRORgithub.com/ubuntu/adsys/cmd/adsysd/main.go:50 main.run() Error from 
server: error while updating policy: can't get policies for "test-example.com": 
failed to retrieve offline state from SSSD: dbus: invalid message: invalid path 
name

There are test packages in the below ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf360012-test

If you install the test package and retry to join the domain, it will
succeed.

[Where problems could occur]

We are changing how domain names are being parsed and converted to valid
dbus object path names. Domain names can only contain [0-9], [A-Z],
[a-z], [.], and [-], so by adding '-' to being processed to its
hexadecimal representation of '_2d', there should be limited scope of
regressions.

However, if a regression were to occur, then users may not be able to
use adsys to apply group policy restrictions, and could run into issues
accessing files, shares and networks.

As mentioned in the impact section, this will be a temporary fix to
0.9.2 while 0.11.0 is being prepared to be released into the archive,
which contains the full fix and testsuite coverage. This SRU should
hopefully be short lived.

[Other Info]

The upstream merge request is:

https://github.com/ubuntu/adsys/pull/498

This was fixed in 0.10.0 by the commit:

commit 5752ba87347d7813dd56bc6a9ec6369ec56e5dc4
Author: Didier Roche 
Date:   Tue Nov 15 11:10:51 2022 +0100
Subject: Fix special characters in domain conversion to dbus object path
Link: 
https://github.com/ubuntu/adsys/commit/5752ba87347d7813dd56bc6a9ec6369ec56e5dc4

Now, there were some additional commits that added testsuite coverage:

commit cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540
Author: Didier Roche 
Date:   Tue Nov 15 11:13:03 2022 +0100
Subject: Refresh golden file now that we properly handle the path.
Link: 
https://github.com/ubuntu/adsys/commit/cd79b3f81441a3d9ab50f11bc8c3b5c7bf722540

commit 4571e39cd724a973270a586d2b18f653f0007de9
Author: Didier Roche 
Date:   Tue Nov 15 11:14:35 2022 +0100
Subject: Use a better case to assert on ServerURL() failure being ignored.
Link: 
https://github.com/ubuntu/adsys/commit/4571e39cd724a973270a586d2b18f653f0007de9

commit fdca6e462c26e1cbecdb8386f43515c1947d423d
Author: Didier Roche 
Date:   Tue Nov 15 11:16:21 2022 +0100
Subject: Add a separate case for special characters in domain name.
Link: 
https://github.com/ubuntu/adsys/commit/fdca6e462c26e1cbecdb8386f43515c1947d423d

These commits are not compatible with 0.9.2 due to testsuite harnesses
and frameworks and test data files not being added until 0.10.0, and
adding such commits is numerous, and contains too many changes for a
SRU. Regrettably, the testsuite commits must be omitted.

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

** Affects: adsys (Ubuntu Focal)
     Importance: High
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress

** Affects: adsys (Ubuntu Jammy)
     Importance: High
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress

** Affects: adsys (Ubuntu Kinetic)
     Importance: High
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress


** Tags: sts

** Tags added: sts

** Also affects: adsys (Ubuntu Kinetic)
   Importance: Undecided
   Status: New

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

** Also affects: adsys (Ubuntu Jammy)
   Importance: Undecided
   Status: New

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

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

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

2023-05-18 Thread Matthew Ruffell

Its not necessary Loic, linux-hwe is a derivative of the kinetic kernel,
and it will be automatically built and pushed to -proposed in due
course, likely over the next few days.

It will be a part of the 5.19.0-44 HWE kernel. I'll keep an eye on it, I
don't think the HWE kernel is moving to the 6.2 kernel just yet.

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

Title:
  vmwgfx fails to reserve graphics buffer on aarch64 leading to blank
  display

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007001

  [Impact]

  Numerous VMWare users have reported that vmwgfx cannot reserve the
  memory region for the graphics framebuffer, leading their VMs to have
  blank screens.

  They see the following in dmesg:

  [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
  [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16

  And a cat /proc/iomem shows this:

  5000-7fff : PCI Bus :00
7000-77ff : :00:0f.0
  7000-702f : BOOTFB

  The kernel has failed to release this memory region for vmwgfx to
  occupy.

  Most affected users are on aarch64, with the host being Apple silicon
  systems.

  [Fix]

  The regression was introduced by the below commit in
  5.19.0-30-generic:

  commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
  Author: Thomas Zimmermann 
  Date: Mon Jul 18 09:23:18 2022 +0200
  Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
  Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

  This commit was part of a larger refactoring of the video subsystem,
  and requires the entire series to function correctly. You can review
  the whole series below:

  https://patchwork.freedesktop.org/series/106040/

  The patch series also requires quite a few additional fixups to fix
  bugs introduced by the series, making the size about 15 commits in
  total. The contents of the series don't really fix any bugs, and their
  purpose is to refactor the code for future changes to the fbdev
  subsystem, and really aren't appropriate to be backported to a stable
  kernel series.

  "video/aperture: Disable and unregister sysfb devices via aperture
  helpers" seems to have been selected for -stable by mistake by its
  fixes: tag, and was pulled into upstream stable by a robot with little
  human review.

  The best course of action is to revert. No action needed for Lunar, as
  the entire series is present in that release.

  [Testcase]

  This bug affects users running Ubuntu in VMWare VMs, notably on
  aarch64 devices, like modern Apple computers.

  Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
  Apple silicon, and see if the display comes up or not.

  Affected users will see a blank screen.

  There is a test kernel available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2007001-test

  If you install the test kernel and reboot, you will be able to see the
  screen on your VM like normal.

  [Where problems could occur]

  This commit changes when the sysfb is disabled and memory region for
  the graphics framebuffer is released to the proper device driver.

  If a regression were to occur, then graphics drivers may fail to
  reserve the framebuffer memory, and fail to start, leaving users with
  a blank screen.

  There are no workarounds, other than booting a previous kernel.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

2023-05-18 Thread Matthew Ruffell

** No longer affects: linux-hwe-5.19 (Ubuntu)

** No longer affects: linux-hwe-5.19 (Ubuntu Jammy)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-5.19 in Ubuntu.
https://bugs.launchpad.net/bugs/2007001

Title:
  vmwgfx fails to reserve graphics buffer on aarch64 leading to blank
  display

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007001

  [Impact]

  Numerous VMWare users have reported that vmwgfx cannot reserve the
  memory region for the graphics framebuffer, leading their VMs to have
  blank screens.

  They see the following in dmesg:

  [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
  [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16

  And a cat /proc/iomem shows this:

  5000-7fff : PCI Bus :00
7000-77ff : :00:0f.0
  7000-702f : BOOTFB

  The kernel has failed to release this memory region for vmwgfx to
  occupy.

  Most affected users are on aarch64, with the host being Apple silicon
  systems.

  [Fix]

  The regression was introduced by the below commit in
  5.19.0-30-generic:

  commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
  Author: Thomas Zimmermann 
  Date: Mon Jul 18 09:23:18 2022 +0200
  Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
  Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

  This commit was part of a larger refactoring of the video subsystem,
  and requires the entire series to function correctly. You can review
  the whole series below:

  https://patchwork.freedesktop.org/series/106040/

  The patch series also requires quite a few additional fixups to fix
  bugs introduced by the series, making the size about 15 commits in
  total. The contents of the series don't really fix any bugs, and their
  purpose is to refactor the code for future changes to the fbdev
  subsystem, and really aren't appropriate to be backported to a stable
  kernel series.

  "video/aperture: Disable and unregister sysfb devices via aperture
  helpers" seems to have been selected for -stable by mistake by its
  fixes: tag, and was pulled into upstream stable by a robot with little
  human review.

  The best course of action is to revert. No action needed for Lunar, as
  the entire series is present in that release.

  [Testcase]

  This bug affects users running Ubuntu in VMWare VMs, notably on
  aarch64 devices, like modern Apple computers.

  Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
  Apple silicon, and see if the display comes up or not.

  Affected users will see a blank screen.

  There is a test kernel available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2007001-test

  If you install the test kernel and reboot, you will be able to see the
  screen on your VM like normal.

  [Where problems could occur]

  This commit changes when the sysfb is disabled and memory region for
  the graphics framebuffer is released to the proper device driver.

  If a regression were to occur, then graphics drivers may fail to
  reserve the framebuffer memory, and fail to start, leaving users with
  a blank screen.

  There are no workarounds, other than booting a previous kernel.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

2023-05-17 Thread Matthew Ruffell

Wonderful! Thank you very much Paul for testing!

This will slowly work its way through the Kernel SRU process. We should
see a release to -updates the week of 5th June, as per
https://kernel.ubuntu.com/, give or take a few days if any CVEs turn up.

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

Title:
  vmwgfx fails to reserve graphics buffer on aarch64 leading to blank
  display

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007001

  [Impact]

  Numerous VMWare users have reported that vmwgfx cannot reserve the
  memory region for the graphics framebuffer, leading their VMs to have
  blank screens.

  They see the following in dmesg:

  [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
  [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16

  And a cat /proc/iomem shows this:

  5000-7fff : PCI Bus :00
7000-77ff : :00:0f.0
  7000-702f : BOOTFB

  The kernel has failed to release this memory region for vmwgfx to
  occupy.

  Most affected users are on aarch64, with the host being Apple silicon
  systems.

  [Fix]

  The regression was introduced by the below commit in
  5.19.0-30-generic:

  commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
  Author: Thomas Zimmermann 
  Date: Mon Jul 18 09:23:18 2022 +0200
  Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
  Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

  This commit was part of a larger refactoring of the video subsystem,
  and requires the entire series to function correctly. You can review
  the whole series below:

  https://patchwork.freedesktop.org/series/106040/

  The patch series also requires quite a few additional fixups to fix
  bugs introduced by the series, making the size about 15 commits in
  total. The contents of the series don't really fix any bugs, and their
  purpose is to refactor the code for future changes to the fbdev
  subsystem, and really aren't appropriate to be backported to a stable
  kernel series.

  "video/aperture: Disable and unregister sysfb devices via aperture
  helpers" seems to have been selected for -stable by mistake by its
  fixes: tag, and was pulled into upstream stable by a robot with little
  human review.

  The best course of action is to revert. No action needed for Lunar, as
  the entire series is present in that release.

  [Testcase]

  This bug affects users running Ubuntu in VMWare VMs, notably on
  aarch64 devices, like modern Apple computers.

  Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
  Apple silicon, and see if the display comes up or not.

  Affected users will see a blank screen.

  There is a test kernel available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2007001-test

  If you install the test kernel and reboot, you will be able to see the
  screen on your VM like normal.

  [Where problems could occur]

  This commit changes when the sysfb is disabled and memory region for
  the graphics framebuffer is released to the proper device driver.

  If a regression were to occur, then graphics drivers may fail to
  reserve the framebuffer memory, and fail to start, leaving users with
  a blank screen.

  There are no workarounds, other than booting a previous kernel.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

** Patch removed: "debdiff for tracker-miners on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663487/+files/lp1779890_focal.debdiff

** Patch removed: "Debdiff for tracker-miners fix on Kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5658668/+files/lp1779890_kinetic.debdiff

** Patch removed: "Debdiff for tracker-miners fix on Jammy"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5658667/+files/lp1779890_jammy.debdiff

** Tags added: sts-sponsor

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  New
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  New
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  New
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

** Patch removed: "debdiff for tracker-miners on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663487/+files/lp1779890_focal.debdiff

** Patch removed: "Debdiff for tracker-miners fix on Kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5658668/+files/lp1779890_kinetic.debdiff

** Patch removed: "Debdiff for tracker-miners fix on Jammy"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5658667/+files/lp1779890_jammy.debdiff

** Tags added: sts-sponsor

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Sts-sponsors] Please sponsor tracker-miners in LP#1779890 for SRU

Hi everyone,

Could you please review and sponsor tracker-miners in the below
Launchpad bug for Denison and I? We have been working on this for a
while, and we finally have the right service ordering in place.

https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890

Thanks,
Matthew

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

Hi everyone,

I have submitted the revert to the Kernel Team for SRU:

Cover letter:
https://lists.ubuntu.com/archives/kernel-team/2023-April/138908.html
Patch:
https://lists.ubuntu.com/archives/kernel-team/2023-April/138909.html

The next step is for the kernel team to review the patch, and for two senior
Kernel Team members to ack the patch. At that stage, it will be accepted into
the next SRU cycle.

You can track the dates for the 2023.05.15 SRU cycle on
https://kernel.ubuntu.com/

I will write back once have have two acks from the Kernel Team.

Thanks,
Matthew

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

Title:
  vmwgfx fails to reserve graphics buffer on aarch64 leading to blank
  display

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  In Progress

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007001

  [Impact]

  Numerous VMWare users have reported that vmwgfx cannot reserve the
  memory region for the graphics framebuffer, leading their VMs to have
  blank screens.

  They see the following in dmesg:

  [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
  [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16

  And a cat /proc/iomem shows this:

  5000-7fff : PCI Bus :00
7000-77ff : :00:0f.0
  7000-702f : BOOTFB

  The kernel has failed to release this memory region for vmwgfx to
  occupy.

  Most affected users are on aarch64, with the host being Apple silicon
  systems.

  [Fix]

  The regression was introduced by the below commit in
  5.19.0-30-generic:

  commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
  Author: Thomas Zimmermann 
  Date: Mon Jul 18 09:23:18 2022 +0200
  Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
  Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

  This commit was part of a larger refactoring of the video subsystem,
  and requires the entire series to function correctly. You can review
  the whole series below:

  https://patchwork.freedesktop.org/series/106040/

  The patch series also requires quite a few additional fixups to fix
  bugs introduced by the series, making the size about 15 commits in
  total. The contents of the series don't really fix any bugs, and their
  purpose is to refactor the code for future changes to the fbdev
  subsystem, and really aren't appropriate to be backported to a stable
  kernel series.

  "video/aperture: Disable and unregister sysfb devices via aperture
  helpers" seems to have been selected for -stable by mistake by its
  fixes: tag, and was pulled into upstream stable by a robot with little
  human review.

  The best course of action is to revert. No action needed for Lunar, as
  the entire series is present in that release.

  [Testcase]

  This bug affects users running Ubuntu in VMWare VMs, notably on
  aarch64 devices, like modern Apple computers.

  Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
  Apple silicon, and see if the display comes up or not.

  Affected users will see a blank screen.

  There is a test kernel available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp2007001-test

  If you install the test kernel and reboot, you will be able to see the
  screen on your VM like normal.

  [Where problems could occur]

  This commit changes when the sysfb is disabled and memory region for
  the graphics framebuffer is released to the proper device driver.

  If a regression were to occur, then graphics drivers may fail to
  reserve the framebuffer memory, and fail to start, leaving users with
  a blank screen.

  There are no workarounds, other than booting a previous kernel.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2007001] Re: vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

** Summary changed:

- Blank console display with aarch64 kernel 5.19.0-31
+ vmwgfx fails to reserve graphics buffer on aarch64 leading to blank display

** Description changed:

- Upgraded the kernel on 22.10 aarch64 (running in a VM on VMware Fusion
- 13.0.1 on Apple Silicon_ from 5.19.0-29 to 5.19.0-31. After the upgrade
- and after rebooting the VM no text or graphical console appears on the
- VM.
+ BugLink: https://bugs.launchpad.net/bugs/2007001
  
- The VM is running and can be accessed through SSH.
+ [Impact]
  
- Rebooting the VM with kernel 5.19.0-29 - everything is working as
- expected. Text and graphical consoles now display properly.
+ Numerous VMWare users have reported that vmwgfx cannot reserve the
+ memory region for the graphics framebuffer, leading their VMs to have
+ blank screens.
  
- ProblemType: Bug
- DistroRelease: Ubuntu 22.10
- Package: linux-image-5.19.0-31-generic 5.19.0-31.32
- ProcVersionSignature: Ubuntu 5.19.0-31.32-generic 5.19.17
- Uname: Linux 5.19.0-31-generic aarch64
- ApportVersion: 2.23.1-0ubuntu3
- Architecture: arm64
- AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
- CRDA: N/A
- CasperMD5CheckResult: pass
- Date: Sat Feb 11 13:04:22 2023
- InstallationDate: Installed on 2022-09-11 (153 days ago)
- InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha arm64 (20220911)
- IwConfig:
-  lono wireless extensions.
-  
-  ens160no wireless extensions.
- MachineType: VMware, Inc. VMware20,1
- ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  XDG_RUNTIME_DIR=
-  LANG=en_US.UTF-8
-  SHELL=/bin/bash
- ProcFB:
-  
- ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-31-generic 
root=UUID=5e9795ee-63e3-4df1-93e9-c36cd88c726c ro quiet splash vt.handoff=7
- RelatedPackageVersions:
-  linux-restricted-modules-5.19.0-31-generic N/A
-  linux-backports-modules-5.19.0-31-generic  N/A
-  linux-firmware 20220923.gitf09bebf3-0ubuntu1.3
- RfKill:
-  
- SourcePackage: linux
- UpgradeStatus: No upgrade log present (probably fresh install)
- dmi.bios.date: 12/05/2022
- dmi.bios.vendor: VMware, Inc.
- dmi.bios.version: VMW201.00V.20904234.BA64.2212051119
- dmi.board.name: VBSA
- dmi.board.vendor: VMware, Inc.
- dmi.board.version: 1
- dmi.chassis.type: 1
- dmi.chassis.vendor: VMware, Inc.
- dmi.chassis.version: VMware20,1
- dmi.modalias: 
dmi:bvnVMware,Inc.:bvrVMW201.00V.20904234.BA64.2212051119:bd12/05/2022:svnVMware,Inc.:pnVMware20,1:pvr1:rvnVMware,Inc.:rnVBSA:rvr1:cvnVMware,Inc.:ct1:cvrVMware20,1:sku0001:
- dmi.product.family: VMware
- dmi.product.name: VMware20,1
- dmi.product.sku: 0001
- dmi.product.version: 1
- dmi.sys.vendor: VMware, Inc.
+ They see the following in dmesg:
+ 
+ [ 11.135360] vmwgfx :00:0f.0: BAR 2: can't reserve [mem 
0x7000-0x77ff 64bit pref]
+ [ 11.135366] vmwgfx: probe of :00:0f.0 failed with error -16
+ 
+ And a cat /proc/iomem shows this:
+ 
+ 5000-7fff : PCI Bus :00
+   7000-77ff : :00:0f.0
+ 7000-702f : BOOTFB
+ 
+ The kernel has failed to release this memory region for vmwgfx to
+ occupy.
+ 
+ Most affected users are on aarch64, with the host being Apple silicon
+ systems.
+ 
+ [Fix]
+ 
+ The regression was introduced by the below commit in 5.19.0-30-generic:
+ 
+ commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
+ Author: Thomas Zimmermann 
+ Date: Mon Jul 18 09:23:18 2022 +0200
+ Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
+ Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea
+ 
+ This commit was part of a larger refactoring of the video subsystem, and
+ requires the entire series to function correctly. You can review the
+ whole series below:
+ 
+ https://patchwork.freedesktop.org/series/106040/
+ 
+ The patch series also requires quite a few additional fixups to fix bugs
+ introduced by the series, making the size about 15 commits in total. The
+ contents of the series don't really fix any bugs, and their purpose is
+ to refactor the code for future changes to the fbdev subsystem, and
+ really aren't appropriate to be backported to a stable kernel series.
+ 
+ "video/aperture: Disable and unregister sysfb devices via aperture
+ helpers" seems to have been selected for -stable by mistake by its
+ fixes: tag, and was pulled into upstream stable by a robot with little
+ human review.
+ 
+ The best course of action is to revert. No action needed for Lunar, as
+ the entire series is present in that release.
+ 
+ [Testcase]
+ 
+ This bug affects users running Ubuntu in VMWare VMs, notably on aarch64
+ devices, like modern Apple computers.
+ 
+ Start a Kinetic or Jammy-HWE Server or Desktop VM in VMWare Fusion on
+ Apple silicon, and see if the display comes up or not.
+ 
+ Affected users will see a blank screen.
+ 
+ There is a test kernel available in the following ppa:
+ 
+

[Kernel-packages] [Bug 2007001] Re: Blank console display with aarch64 kernel 5.19.0-31

2023-04-18 Thread Matthew Ruffell

Hi everyone,

I have built a test kernel based on the current 5.19.0-38-generic kernel for
both Kinetic and Jammy HWE. It has the below patch reverted:

commit 5e01376124309b4dbd30d413f43c0d9c2f60edea
Author: Thomas Zimmermann 
Date:   Mon Jul 18 09:23:18 2022 +0200
Subject: video/aperture: Disable and unregister sysfb devices via aperture 
helpers
Link: 
https://github.com/torvalds/linux/commit/5e01376124309b4dbd30d413f43c0d9c2f60edea

The revert patch is below:

https://paste.ubuntu.com/p/F5dxtqPqxC/

Could someone please test the test kernel to see if it fixes the problem on
their kinetic VM running on VMWare?

You may want to make the grub menu selectable first, in case the test kernel
does not work, so you can easily swap back to 5.19.0-29-generic which works.

Edit as root:
/etc/default/grub

Change GRUB_TIMEOUT_STYLE=hidden to GRUB_TIMEOUT_STYLE=menu and add a decent
timeout GRUB_TIMEOUT=30

Then update grub:

$ sudo update-grub

If you can test 5.19.0-38-generic from -updates first, and then test the test
kernel, it would be best to compare the two directly. Hopefully the test kernel
resolves the issue.

Please note this package is NOT SUPPORTED by Canonical, and is for TESTING
PURPOSES ONLY. ONLY Install in a dedicated test environment.

Instructions to install (on a Jammy or Kinetic system):
1) sudo add-apt-repository ppa:mruffell/lp2007001-test
2) sudo apt update
3) sudo apt install linux-image-unsigned-5.19.0-38-generic 
linux-modules-5.19.0-38-generic linux-modules-extra-5.19.0-38-generic 
linux-headers-5.19.0-38-generic
4) sudo reboot
5) uname -rv
5.19.0-38-generic #39+TEST2007001v20230418b1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 
18

Upon boot, you should be able to see the screen as normal on your VMWare
VM.

Let me know if the test kernel works.

Thanks,
Matthew

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

Title:
  Blank console display with aarch64 kernel 5.19.0-31

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  In Progress

Bug description:
  Upgraded the kernel on 22.10 aarch64 (running in a VM on VMware Fusion
  13.0.1 on Apple Silicon_ from 5.19.0-29 to 5.19.0-31. After the
  upgrade and after rebooting the VM no text or graphical console
  appears on the VM.

  The VM is running and can be accessed through SSH.

  Rebooting the VM with kernel 5.19.0-29 - everything is working as
  expected. Text and graphical consoles now display properly.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: linux-image-5.19.0-31-generic 5.19.0-31.32
  ProcVersionSignature: Ubuntu 5.19.0-31.32-generic 5.19.17
  Uname: Linux 5.19.0-31-generic aarch64
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: arm64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CRDA: N/A
  CasperMD5CheckResult: pass
  Date: Sat Feb 11 13:04:22 2023
  InstallationDate: Installed on 2022-09-11 (153 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha arm64 (20220911)
  IwConfig:
   lono wireless extensions.

   ens160no wireless extensions.
  MachineType: VMware, Inc. VMware20,1
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB:

  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-31-generic 
root=UUID=5e9795ee-63e3-4df1-93e9-c36cd88c726c ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-5.19.0-31-generic N/A
   linux-backports-modules-5.19.0-31-generic  N/A
   linux-firmware 20220923.gitf09bebf3-0ubuntu1.3
  RfKill:

  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/05/2022
  dmi.bios.vendor: VMware, Inc.
  dmi.bios.version: VMW201.00V.20904234.BA64.2212051119
  dmi.board.name: VBSA
  dmi.board.vendor: VMware, Inc.
  dmi.board.version: 1
  dmi.chassis.type: 1
  dmi.chassis.vendor: VMware, Inc.
  dmi.chassis.version: VMware20,1
  dmi.modalias: 
dmi:bvnVMware,Inc.:bvrVMW201.00V.20904234.BA64.2212051119:bd12/05/2022:svnVMware,Inc.:pnVMware20,1:pvr1:rvnVMware,Inc.:rnVBSA:rvr1:cvnVMware,Inc.:ct1:cvrVMware20,1:sku0001:
  dmi.product.family: VMware
  dmi.product.name: VMware20,1
  dmi.product.sku: 0001
  dmi.product.version: 1
  dmi.sys.vendor: VMware, Inc.

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

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-04-18 Thread Matthew Ruffell

Attached is a v2 debdiff for Focal, after Denison correctly pointed out
that I was missing a patch.

** Description changed:

  [ Impact ]
  
  The KRB5CCNAME environment variable points to the Kerberos ticket of the
  current machine and this ticket is used for authentication in Active
  Directory  servers.
  
  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input when
  accessing network shares, for example.
  
  Some services rely on gvfs-daemon in order to properly function, such as
  tracker-extract-3.service and tracker-miner-fs-3.service, which means
  they will ask for the gvfs-daemon to be initialized when they are
  executed by systemd. This creates problems if one service that relies on
  gvfsd is started too early, as it would result in gvfsd being started
  too early as well.
  
  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283
  
  However, the tracker-extract-3.service was not updated and its target is
  still default.target, which is too early for the service to start.
  
  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.
  
  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.
  
  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.
  
  [ Test Plan ]
  
  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1
  
     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.
  
  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:
  
     journalctl --user -b
  
  And check the order in which the services were started and when they
  were triggered.
  
  Test packages are available in the following ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test
  
  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.
  
  [ Where problems could occur ]
  
  The tracker project is a search engine that speeds up search operations
  in Gnome. The tracker-miners is the indexing daemon that populates the
  database with information, so changing its start does not affect the
  system behavior.
  
  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.
  
  [ Other info ]
  
  This was fixed upstream by the following commit:
  
  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  
- Focal requires three additional patches to solve the issue, namely:
+ Focal requires four additional patches to solve the issue, namely:
  
  commit 8065985c8d818414a36fe151862afdf42c5eda8a
  Author: Laurent Bigonville 
  Date: Sat, 4 Apr 2020 19:18:00 +0200
  Subject: Move the Install section to the systemd .service file instead
-  of the udev one
+  of the udev one
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/8065985c8d818414a36fe151862afdf42c5eda8a
  
  commit 74ae33ce01b8d314d6e33746915f75f270b0e21d
  Author: Sam Thursfield 
  Date: Tue, 3 Nov 2020 12:50:02 +0100
  Subject: miners: Opt out of systemd / XDG autostart integration
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/74ae33ce01b8d314d6e33746915f75f270b0e21d
  
  commit 3a75f93865e8eb002a377a341a72b1a4b22a8040
  Author: Sam Thursfield 
  Date: Tue, 27 Oct 2020 22:05:07 +0100
  Subject: miners: Tie systemd startup to gnome-session.service

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-04-18 Thread Matthew Ruffell

Attached is a v2 debdiff for Focal, after Denison correctly pointed out
that I was missing a patch.

** Description changed:

  [ Impact ]
  
  The KRB5CCNAME environment variable points to the Kerberos ticket of the
  current machine and this ticket is used for authentication in Active
  Directory  servers.
  
  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input when
  accessing network shares, for example.
  
  Some services rely on gvfs-daemon in order to properly function, such as
  tracker-extract-3.service and tracker-miner-fs-3.service, which means
  they will ask for the gvfs-daemon to be initialized when they are
  executed by systemd. This creates problems if one service that relies on
  gvfsd is started too early, as it would result in gvfsd being started
  too early as well.
  
  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283
  
  However, the tracker-extract-3.service was not updated and its target is
  still default.target, which is too early for the service to start.
  
  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.
  
  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.
  
  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.
  
  [ Test Plan ]
  
  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1
  
     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.
  
  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:
  
     journalctl --user -b
  
  And check the order in which the services were started and when they
  were triggered.
  
  Test packages are available in the following ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test
  
  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.
  
  [ Where problems could occur ]
  
  The tracker project is a search engine that speeds up search operations
  in Gnome. The tracker-miners is the indexing daemon that populates the
  database with information, so changing its start does not affect the
  system behavior.
  
  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.
  
  [ Other info ]
  
  This was fixed upstream by the following commit:
  
  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  
- Focal requires three additional patches to solve the issue, namely:
+ Focal requires four additional patches to solve the issue, namely:
  
  commit 8065985c8d818414a36fe151862afdf42c5eda8a
  Author: Laurent Bigonville 
  Date: Sat, 4 Apr 2020 19:18:00 +0200
  Subject: Move the Install section to the systemd .service file instead
-  of the udev one
+  of the udev one
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/8065985c8d818414a36fe151862afdf42c5eda8a
  
  commit 74ae33ce01b8d314d6e33746915f75f270b0e21d
  Author: Sam Thursfield 
  Date: Tue, 3 Nov 2020 12:50:02 +0100
  Subject: miners: Opt out of systemd / XDG autostart integration
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/74ae33ce01b8d314d6e33746915f75f270b0e21d
  
  commit 3a75f93865e8eb002a377a341a72b1a4b22a8040
  Author: Sam Thursfield 
  Date: Tue, 27 Oct 2020 22:05:07 +0100
  Subject: miners: Tie systemd startup to gnome-session.service

[Kernel-packages] [Bug 2007001] Re: Blank console display with aarch64 kernel 5.19.0-31

2023-04-17 Thread Matthew Ruffell

** No longer affects: linux-signed-hwe-5.19 (Ubuntu)

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

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

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

** Changed in: linux (Ubuntu Kinetic)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Kinetic)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-signed-hwe-5.19 in Ubuntu.
https://bugs.launchpad.net/bugs/2007001

Title:
  Blank console display with aarch64 kernel 5.19.0-31

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Kinetic:
  In Progress

Bug description:
  Upgraded the kernel on 22.10 aarch64 (running in a VM on VMware Fusion
  13.0.1 on Apple Silicon_ from 5.19.0-29 to 5.19.0-31. After the
  upgrade and after rebooting the VM no text or graphical console
  appears on the VM.

  The VM is running and can be accessed through SSH.

  Rebooting the VM with kernel 5.19.0-29 - everything is working as
  expected. Text and graphical consoles now display properly.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.10
  Package: linux-image-5.19.0-31-generic 5.19.0-31.32
  ProcVersionSignature: Ubuntu 5.19.0-31.32-generic 5.19.17
  Uname: Linux 5.19.0-31-generic aarch64
  ApportVersion: 2.23.1-0ubuntu3
  Architecture: arm64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CRDA: N/A
  CasperMD5CheckResult: pass
  Date: Sat Feb 11 13:04:22 2023
  InstallationDate: Installed on 2022-09-11 (153 days ago)
  InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha arm64 (20220911)
  IwConfig:
   lono wireless extensions.
   
   ens160no wireless extensions.
  MachineType: VMware, Inc. VMware20,1
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB:
   
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-31-generic 
root=UUID=5e9795ee-63e3-4df1-93e9-c36cd88c726c ro quiet splash vt.handoff=7
  RelatedPackageVersions:
   linux-restricted-modules-5.19.0-31-generic N/A
   linux-backports-modules-5.19.0-31-generic  N/A
   linux-firmware 20220923.gitf09bebf3-0ubuntu1.3
  RfKill:
   
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/05/2022
  dmi.bios.vendor: VMware, Inc.
  dmi.bios.version: VMW201.00V.20904234.BA64.2212051119
  dmi.board.name: VBSA
  dmi.board.vendor: VMware, Inc.
  dmi.board.version: 1
  dmi.chassis.type: 1
  dmi.chassis.vendor: VMware, Inc.
  dmi.chassis.version: VMware20,1
  dmi.modalias: 
dmi:bvnVMware,Inc.:bvrVMW201.00V.20904234.BA64.2212051119:bd12/05/2022:svnVMware,Inc.:pnVMware20,1:pvr1:rvnVMware,Inc.:rnVBSA:rvr1:cvnVMware,Inc.:ct1:cvrVMware20,1:sku0001:
  dmi.product.family: VMware
  dmi.product.name: VMware20,1
  dmi.product.sku: 0001
  dmi.product.version: 1
  dmi.sys.vendor: VMware, Inc.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2016706] Re: The 5.19 kernel backport is broken

2023-04-17 Thread Matthew Ruffell

*** This bug is a duplicate of bug 2007001 ***
https://bugs.launchpad.net/bugs/2007001

Hi Zack,

Thanks for the report and the link. I'll get a test kernel building with
a revert and we can get some community users to try it out.

I'll post it in bug 2007001 instead, the existing bug, and mark this one
as a duplicate. I'll post in the VMware forum too.

Thanks,
Matthew

** This bug has been marked a duplicate of bug 2007001
   Blank console display with aarch64 kernel 5.19.0-31

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

Title:
  The 5.19 kernel backport is broken

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  The latest 5.19 backport which migrated from 22.10 to 22.04 is broken on 
arm64. The kernel team decided to include the following change:
  5e0137612430 ("video/aperture: Disable and unregister sysfb devices via 
aperture helpers")
  it's the change 89314ff239e1933357419fa91b20190150f114a8 in the kinetic 
kernel repo. 

  This change was part of a much larger series that was making sure that
  fb devices were properly releasing the pci resources which is
  necessary for proper drivers to load. Because the backport misses all
  those other changes it breaks PCI resource release for efifb and
  prevents specific drivers (e.g. vmwgfx) from being loaded. It doesn't
  affect many other arm64 systems because most arm64 system don't have
  dedicated PCI gpu's, like vmwgfx is, which is presumably why it was
  missed.

  Without the rest of the changes in that series efifb won't release BAR 2, 
which results in :
  vmwgfx :00:0f.0 BAR 2: can't reserve [mem 0x700-0x77ff 64bit pref]
  and a black screen on boot. Because the way drm drivers work is that first 
they unload the legacy fb drivers, in this case efifb, and then they continue 
their own initialization. In this case vmwgfx can't initialize because even 
though efifb has been unloaded it never released the resource at BAR 2, so 
vmwgfx can't claim it. Currently there's no mechanism in the kernel to reload 
the original generic fb driver in case the specific gpu driver fails the 
initialization. This results in black screen on booth with vmware hypervisor on 
arm64 and Ubuntu's 5.19 kernel.

  To fix it either the above mentioned change needs to be backed out or the 
rest of the patches from that series needs to be backported as well.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu82.4
  Architecture: arm64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/controlC0', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D0c', 
'/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: pass
  DistroRelease: Ubuntu 22.04
  InstallationDate: Installed on 2022-01-13 (459 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha arm64 (20220112)
  IwConfig:
   lono wireless extensions.
   
   ens160no wireless extensions.
  MachineType: VMware, Inc. VMware20,1
  Package: linux (not installed)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB:
   
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-38-generic 
root=UUID=cd59243b-41f9-4a96-9a57-315489304b3e ro console=tty0 
console=ttyS0,115200n8 drm.debug=0x2 quiet splash vt.handoff=7
  ProcVersionSignature: Ubuntu 5.19.0-38.39~22.04.1-generic 5.19.17
  RelatedPackageVersions:
   linux-restricted-modules-5.19.0-38-generic N/A
   linux-backports-modules-5.19.0-38-generic  N/A
   linux-firmware 20220329.git681281e4-0ubuntu3.12
  RfKill:
   
  Tags:  jammy
  Uname: Linux 5.19.0-38-generic aarch64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 03/31/2023
  dmi.bios.vendor: VMware, Inc.
  dmi.bios.version: VMW201.00V.21529217.BA64.2303311427
  dmi.board.name: VBSA
  dmi.board.vendor: VMware, Inc.
  dmi.board.version: 1
  dmi.chassis.type: 1
  dmi.chassis.vendor: VMware, Inc.
  dmi.chassis.version: VMware20,1
  dmi.modalias: 
dmi:bvnVMware,Inc.:bvrVMW201.00V.21529217.BA64.2303311427:bd03/31/2023:svnVMware,Inc.:pnVMware20,1:pvr1:rvnVMware,Inc.:rnVBSA:rvr1:cvnVMware,Inc.:ct1:cvrVMware20,1:sku0001:
  dmi.product.family: VMware
  dmi.product.name: VMware20,1
  dmi.product.sku: 0001
  dmi.product.version: 1
  dmi.sys.vendor: VMware, Inc.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a v2 debdiff for kinetic. Again, minor changes, corrected
version, dep3 tags.

** Patch added: "debdiff for tracker-miners on kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663489/+files/lp1779890_kinetic_v2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a v2 debdiff for kinetic. Again, minor changes, corrected
version, dep3 tags.

** Patch added: "debdiff for tracker-miners on kinetic"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663489/+files/lp1779890_kinetic_v2.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  New
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  New
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  New
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link:

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a v2 debdiff for Jammy. Very minor changes, corrected
version, tidied up dep3 tags.

** Patch added: "debdiff for tracker-miners on jammy"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663488/+files/lp1779890_jammy_v2.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  New
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  New
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  New
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link:

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a v2 debdiff for Jammy. Very minor changes, corrected
version, tidied up dep3 tags.

** Patch added: "debdiff for tracker-miners on jammy"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663488/+files/lp1779890_jammy_v2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a debdiff for Focal.

** Patch added: "debdiff for tracker-miners on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663487/+files/lp1779890_focal.debdiff

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Bionic:
  New
Status in tracker-miners source package in Bionic:
  Won't Fix
Status in gvfs source package in Focal:
  New
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress
Status in gvfs source package in Lunar:
  New
Status in tracker-miners source package in Lunar:
  Fix Released

Bug description:
  [ Impact ]

  The KRB5CCNAME environment variable points to the Kerberos ticket of
  the current machine and this ticket is used for authentication in
  Active Directory  servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]

  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1

     You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs-
     3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its
     target was default.target. The easiest way is to remove the symlink that
     systemd created when enabling the unit, located under
     /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
     This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

     journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test

  After installing test packages of tracker-miners, KRB5CCNAME should be
  set in gvfs environment upon login to gnome.

  [ Where problems could occur ]

  The tracker project is a search engine that speeds up search
  operations in Gnome. The tracker-miners is the indexing daemon that
  populates the database with information, so changing its start does
  not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  [ Other info ]

  This was fixed upstream by the following commit:

  commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
  From: Denison Barbosa 
  Date: Tue, 21 Mar 2023 15:04:28 +
  Subject: Removing [Install] section from tracker-extract-3.service
  Link: 
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3

  Focal

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

Attached is a debdiff for Focal.

** Patch added: "debdiff for tracker-miners on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1779890/+attachment/5663487/+files/lp1779890_focal.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

** Description changed:

[ Impact ]
- The KRB5CCNAME environment variable points to the Kerberos ticket of the
current machine and this ticket is used for authentication in Active Directory
servers.
+
+ The KRB5CCNAME environment variable points to the Kerberos ticket of the
+ current machine and this ticket is used for authentication in Active
+ Directory servers.

This variable is set by pam_sss when the user authenticates and can be
used by other processes, such as gio, to skip the credentials input when
accessing network shares, for example.

Some services rely on gvfs-daemon in order to properly function, such as
tracker-extract-3.service and tracker-miner-fs-3.service, which means
they will ask for the gvfs-daemon to be initialized when they are
executed by systemd. This creates problems if one service that relies on
gvfsd is started too early, as it would result in gvfsd being started
too early as well.

As of version 3.1 of tracker-miners, the install target of tracker-
miners-fs-3.service was set to gnome-session.target:
https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

However, the tracker-extract-3.service was not updated and its target is
still default.target, which is too early for the service to start.

Starting tracker-extract too early is also starting gvfsd too early,
before the session environment gets fully updated. Which means that
gvfsd does not have the KRB5CCNAME variable and can not do any
operations with it.

Tracker-extract is supposed to be a helper service managed by tracker-
miner-fs-3.service. By using a [Install] section, we are actually
telling systemd that it should manage this service as well, when it
shouldn't.

So, by removing the [Install] section and having tracker-miner-
fs-3.service being tied to gnome-session.target, we fix the issue of
gvfsd starting too early without the updated session environment.

[ Test Plan ]
+
In order to test this issue, it's required to have an Active Directory server
running.
1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
2) Check gvfsd environment. This can be done by running:
- cat /proc/$(pidof gvfsd)/environ | xargs --null -n1
-
-You will be able to see that it does not have the variable listed.
- 3) Check that the information mentioned above about tracker-miner-fs-
-3.service is true.
- 4) Disable tracker-extract-3.service (This is a bit tricky, since its
-target was default.target. The easiest way is to remove the symlink that
-systemd created when enabling the unit, located under
-/etc/systemd/user/default.target.wants/tracker-extract-3.service
+ cat /proc/$(pidof gvfsd)/environ | xargs --null -n1
+
+ You will be able to see that it does not have the variable listed.
+ 3) Check that the information mentioned above about tracker-miner-fs-
+ 3.service is true.
+ 4) Disable tracker-extract-3.service (This is a bit tricky, since its
+ target was default.target. The easiest way is to remove the symlink that
+ systemd created when enabling the unit, located under
+ /etc/systemd/user/default.target.wants/tracker-extract-3.service
5) Reboot the machine;
6) Repeat steps 1 and 2.
-This will show that gvfsd is now started with the proper environment.
+ This will show that gvfsd is now started with the proper environment.

Is not enough to look at ptree and the pids of the processes, instead
it's better to look into the session logs with:

-journalctl --user -b
+ journalctl --user -b

And check the order in which the services were started and when they
were triggered.

+ Test packages are available in the following ppa:
+
+ https://launchpad.net/~mruffell/+archive/ubuntu/sf320070-test
+
+ After installing test packages of tracker-miners, KRB5CCNAME should be
+ set in gvfs environment upon login to gnome.
+
[ Where problems could occur ]
- The tracker project is a search engine that speeds up search operations in
Gnome. The tracker-miners is the indexing daemon that populates the database
with information, so changing its start does not affect the system behavior.
+
+ The tracker project is a search engine that speeds up search operations
+ in Gnome. The tracker-miners is the indexing daemon that populates the
+ database with information, so changing its start does not affect the
+ system behavior.

This changes fix the startup of gvfs-daemon.service, which could delay
services that relied on it running to be executed.
+
+ [ Other info ]
+
+ This was fixed upstream by the following commit:
+
+ commit 29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
+ From: Denison Barbosa
+ Date: Tue, 21 Mar 2023 15:04:28 +
+ Subject: Removing [Install] section from tracker-extract-3.service
+ Link:
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/29a2320c1e4f0f7ced3c3e9d4d1c06c51518c1f3
+
+ Focal requires three additional patches

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

** Description changed:

This variable is set by pam_sss when the user authenticates and can be
used by other processes, such as gio, to skip the credentials input when
accessing network shares, for example.

As of version 3.1 of tracker-miners, the install target of tracker-
miners-fs-3.service was set to gnome-session.target:
https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

However, the tracker-extract-3.service was not updated and its target is
still default.target, which is too early for the service to start.

So, by removing the [Install] section and having tracker-miner-
fs-3.service being tied to gnome-session.target, we fix the issue of
gvfsd starting too early without the updated session environment.

Is not enough to look at ptree and the pids of the processes, instead
it's better to look into the session logs with:

-journalctl --user -b
+ journalctl --user -b

And check the order in which the services were started and when they
were triggered.

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

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

** Also affects: tracker-miners (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: tracker-miners (Ubuntu Focal)
   Status: New => In Progress

** Changed in: tracker-miners (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: tracker-miners (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to tracker-miners in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Focal:
  New
Status in tracker-miners source package in Focal:
  In Progress
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress

Bug description:
  [ Impact ]
  The KRB5CCNAME environment variable points to the Kerberos ticket of the 
current machine and this ticket is used for authentication in Active Directory  
servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]
  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1
 
 You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs- 
 3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its 
 target was default.target. The easiest way is to remove the symlink that 
 systemd created when enabling the unit, located under 
 /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
 This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

 journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  [ Where problems could occur ]
  The tracker project is a search engine that speeds up search operations in 
Gnome. The tracker-miners is the indexing daemon that populates the database 
with information, so changing its start does not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  
  ## Original description ##
  Nautilus prompts for username and password when accessing a Samba share on a 
network drive, despite having a perfectly valid unexpired Kerberos ticket. The 
Kerberos ticket is obtained automatically at logon by authentication against a 
Samba Active Directory server (Samba AD-DC).

  Accessing the same Samba share with the same Kerberos ticket via
  "smbclient //host/sharename -k" works fine.

  One known workaround is: "nautilus -q", and then "killall gvfsd".
  After that, accessing the Samba share with Nautilus

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

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

** Also affects: tracker-miners (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: tracker-miners (Ubuntu Focal)
   Status: New => In Progress

** Changed in: tracker-miners (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: tracker-miners (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Desktop-packages] [Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-04-11 Thread Matthew Ruffell

** Changed in: tracker-miners (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: tracker-miners (Ubuntu Kinetic)
   Status: New => In Progress

** Changed in: tracker-miners (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: tracker-miners (Ubuntu Kinetic)
   Importance: Undecided => Medium

** Changed in: tracker-miners (Ubuntu Jammy)
 Assignee: (unassigned) => Denison Barbosa (justdenis)

** Changed in: tracker-miners (Ubuntu Kinetic)
 Assignee: (unassigned) => Denison Barbosa (justdenis)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

Status in gvfs package in Ubuntu:
  New
Status in tracker-miners package in Ubuntu:
  Fix Released
Status in gvfs source package in Jammy:
  New
Status in tracker-miners source package in Jammy:
  In Progress
Status in gvfs source package in Kinetic:
  New
Status in tracker-miners source package in Kinetic:
  In Progress

Bug description:
  [ Impact ]
  The KRB5CCNAME environment variable points to the Kerberos ticket of the 
current machine and this ticket is used for authentication in Active Directory  
servers.

  This variable is set by pam_sss when the user authenticates and can be
  used by other processes, such as gio, to skip the credentials input
  when accessing network shares, for example.

  Some services rely on gvfs-daemon in order to properly function, such
  as tracker-extract-3.service and tracker-miner-fs-3.service, which
  means they will ask for the gvfs-daemon to be initialized when they
  are executed by systemd. This creates problems if one service that
  relies on gvfsd is started too early, as it would result in gvfsd
  being started too early as well.

  As of version 3.1 of tracker-miners, the install target of tracker-
  miners-fs-3.service was set to gnome-session.target:
  https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/283

  However, the tracker-extract-3.service was not updated and its target
  is still default.target, which is too early for the service to start.

  Starting tracker-extract too early is also starting gvfsd too early,
  before the session environment gets fully updated. Which means that
  gvfsd does not have the KRB5CCNAME variable and can not do any
  operations with it.

  Tracker-extract is supposed to be a helper service managed by tracker-
  miner-fs-3.service. By using a [Install] section, we are actually
  telling systemd that it should manage this service as well, when it
  shouldn't.

  So, by removing the [Install] section and having tracker-miner-
  fs-3.service being tied to gnome-session.target, we fix the issue of
  gvfsd starting too early without the updated session environment.

  [ Test Plan ]
  In order to test this issue, it's required to have an Active Directory server 
running.
  1) Authenticate with an AD user (as this would set the KRB5CCNAME env);
  2) Check gvfsd environment. This can be done by running:
  cat /proc/$(pidof gvfsd)/environ | xargs --null -n1
 
 You will be able to see that it does not have the variable listed.
  3) Check that the information mentioned above about tracker-miner-fs- 
 3.service is true.
  4) Disable tracker-extract-3.service (This is a bit tricky, since its 
 target was default.target. The easiest way is to remove the symlink that 
 systemd created when enabling the unit, located under 
 /etc/systemd/user/default.target.wants/tracker-extract-3.service
  5) Reboot the machine;
  6) Repeat steps 1 and 2.
 This will show that gvfsd is now started with the proper environment.

  Is not enough to look at ptree and the pids of the processes, instead
  it's better to look into the session logs with:

 journalctl --user -b

  And check the order in which the services were started and when they
  were triggered.

  [ Where problems could occur ]
  The tracker project is a search engine that speeds up search operations in 
Gnome. The tracker-miners is the indexing daemon that populates the database 
with information, so changing its start does not affect the system behavior.

  This changes fix the startup of gvfs-daemon.service, which could delay
  services that relied on it running to be executed.

  
  ## Original description ##
  Nautilus prompts for username and password when accessing a Samba share on a 
network drive, despite having a perfectly valid unexpired Kerberos ticket. The 
Kerberos ticket is obtained automatically at logon by authentication against a 
Samba Active Directory server (Samba AD-DC).

  Accessing the same Samba share with the same Kerberos ticket via
  "smbclient //host/sharename -k" works fine.

  One known workaround is: "nautilus -q", and then "killall gvfsd".
  After that, accessing the Samba share with Nautilus works normally as
  it should.

  I did not experience this

[Bug 1779890] Re: gvfsd process does not have the KRB5CCNAME environment set

2023-04-11 Thread Matthew Ruffell

** Changed in: tracker-miners (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: tracker-miners (Ubuntu Kinetic)
   Status: New => In Progress

** Changed in: tracker-miners (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: tracker-miners (Ubuntu Kinetic)
   Importance: Undecided => Medium

** Changed in: tracker-miners (Ubuntu Jammy)
 Assignee: (unassigned) => Denison Barbosa (justdenis)

** Changed in: tracker-miners (Ubuntu Kinetic)
 Assignee: (unassigned) => Denison Barbosa (justdenis)

-- 
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1779890

Title:
  gvfsd process does not have the KRB5CCNAME environment set

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


-- 
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs

[Kernel-packages] [Bug 2009882] Re: Linux 5.4.0-144-generic x86_64 multithread / fork issues

2023-03-28 Thread Matthew Ruffell

Hi Christian, Alfredo,

5.4.0-146-generic was released yesterday with a fix for the NFS
regression, and it should have less bandwidth consumption than
5.4.0-144-generic.

There is still some reports that it still has higher NFS requests than
before the regression was introduced, so please chime in on the below
bug if the situation improves with 5.4.0-146-generic, but is not
completely addressed.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2009325

Thanks,
Matthew

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

Title:
  Linux 5.4.0-144-generic x86_64 multithread / fork issues

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  We have same servers already running in 5.4.0-122 , 126, 128 and 131
  releases with no issues whatsoever and exceptional good performance.
  They basically have either Apache/2.4.41/mod_php7.4 or
  Apache/2.4.41/mpm_event with phm7.4-fpm setups, all working perfect.

  When we load kernel 5.4.0-144 CPU processing go thru the roof, and
  process kworker/u17:0-xprtiod show at the top. Both setups perform
  badly with Apache performance going avg 200ms/req in older kernels to
  over 4,500ms/req in this 144 release. CPU usage from avg 0.4% to over
  50% under same traffic and requests rate.

  We just reloaded old kernels back, via /etc/default/grub, and
  performance is right back.  Same packages, same services, everything
  the same but the Linux kernel.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-144-generic 5.4.0-144.161
  ProcVersionSignature: Ubuntu 5.4.0-144.161-generic 5.4.229
  Uname: Linux 5.4.0-144-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Mar  9 13:21 seq
   crw-rw 1 root audio 116, 33 Mar  9 13:21 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu27.25
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: pass
  Date: Thu Mar  9 13:22:31 2023
  InstallationDate: Installed on 2021-11-17 (477 days ago)
  InstallationMedia: Ubuntu-Server 20.04.3 LTS "Focal Fossa" - Release amd64 
(20210824)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
   Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
   |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
  MachineType: VMware, Inc. VMware Virtual Platform
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 svgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-144-generic 
root=/dev/mapper/ubuntu--vg-ubuntu--lv ro maybe-ubiquity
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-144-generic N/A
   linux-backports-modules-5.4.0-144-generic  N/A
   linux-firmware 1.187.36
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/12/2018
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd12/12/2018:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
  dmi.product.name: VMware Virtual Platform
  dmi.product.version: None
  dmi.sys.vendor: VMware, Inc.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort

2023-03-21 Thread Matthew Ruffell

Hi William.

The libunwind SRU for Bionic and Focal have now been released to
-updates. Their versions are 1.2.1-8ubuntu0.1 for Bionic, and
1.2.1-9ubuntu0.1 for Focal.

I just want to apologise for the significant delay in getting libunwind
released. It really was a exceptional amount of time, and I'm sorry it
took so long.

Since I wrote to you last, I root caused the issue and worked with
Paride to resolve the regression that was introduced into autopkgtest
itself.

The bug in autopkgtest was quite obscure, and it required the following
to occur:

1. an all-proposed build (--apt-pocket=proposed with no package pinning)
2. multiple tests defined in d/t/control
3. the tests do not allow reusing the same testbed system

All these conditions were present in the kernel autopkgtests, and the
result was that the change to allow apt pinning for -proposed caused
_create_apt_pinning_for_packages() to be called incorrectly and it set a
pinning for the -release pocket at 990, over -updates and -proposed, at
500 each, which meant that -release was being favoured over -proposed,
and it caused all sorts of apt resolve issues.

The issue was introduced in:

commit 1c018c78de9d9421c0c358c900a37e545334cc66
From: Paride Legovini 
Date: Thu, 15 Dec 2022 21:47:02 +0100
Subject: Pin pockets with Pin-Priority: 500
Link: 
https://salsa.debian.org/ci-team/autopkgtest/-/commit/1c018c78de9d9421c0c358c900a37e545334cc66

The full explanation of the autopkgtest issues can be found in the below
emails:

>From myself to Paride
https://paste.ubuntu.com/p/44yFTBNBHh/

>From Paride to myself:
https://paste.ubuntu.com/p/jtt5wh6BB2/

Paride's merge request;
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/218

Final fix commit:
https://salsa.debian.org/ci-team/autopkgtest/-/commit/94b9bb8db3051123d7b29a7880420340a76c7b7e

The fix is in place on the Launchpad build infrastructure, and we re-ran
all autopkgtests around libunwind and its reverse dependencies, and they
all passed, leading us clear to release libunwind to -updates.

Again, I sincerely apologise for keeping you waiting for so long, and I
thank you for your patience and understanding while I debugged
autopkgtest.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libunwind in Ubuntu.
https://bugs.launchpad.net/bugs/1999104

Title:
  arm64: broken c++ exception handler support leads to std::terminate()
  being called and program abort

Status in libunwind package in Ubuntu:
  Fix Released
Status in libunwind source package in Bionic:
  Fix Released
Status in libunwind source package in Focal:
  Fix Released

Bug description:
  [Impact]

  On architectures other than i386 and amd64, the C++ exception support
  in libunwind appears to be broken, always failing and calling
  std::terminate() which leads to the program aborting.

  (gdb) bt
  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
  #1  0xf7c2daac in __GI_abort () at abort.c:79
  #2  0xf7e21868 in __gnu_cxx::__verbose_terminate_handler() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #3  0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
  #4  0xf7e1f280 in std::terminate() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #5  0xf7e1f5e0 in __cxa_rethrow ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #6  0xf7e21804 in __gnu_cxx::__verbose_terminate_handler() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #7  0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
  #8  0xf7e1f280 in std::terminate() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #9  0xf7e1f574 in __cxa_throw ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #10 0xf7fb9f50 in function_throws_int () at lib.cpp:9
  #11 0x0d54 in main (argc=1, argv=0xfab8) at main.cpp:9

  Compiling libunwind with --enable-cxx-exceptions enabled leads to
  _Unwind_RaiseException being called during __cxa_throw(), which fails
  to find a handler, and the generic std::terminate() is called instead,
  aborting the program.

  On i386 and amd64 this doesn't seem to be the case, and the libunwind
  handlers seem to be present.

  To fix, we only enable the configure option --enable-cxx-exceptions on
  i386 and amd64 only, in debian/rules. This lets other architectures
  fall back to the symbols provided by libgcc_s, which implementation
  works correctly.

  [Testcase]

  Ali Sadi has provided a reproducer program.

  Start an arm64 instance, for example, a c6g.medium instance on AWS,
  with either Bionic or Focal.

  $ wget 
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635122/+files/libunwind.tar.gz
  $ sudo apt install -y build-essential libunwind-dev
  $ tar xvf libunwind.tar.gz && cd test
  $ make all

  There are two executable, main and main_unwind. main is not linked to

[Kernel-packages] [Bug 1987430] Re: Ubuntu 22.04 kernel 5.15.0-46-generic leaks kernel memory in kmalloc-2k slabs

2023-03-14 Thread Matthew Ruffell

Performing verification for Jammy.

I started a fresh Jammy VM, and installed 5.15.0-67-generic from
-updates.

I appended apparmor=0 to GRUB_CMDLINE_LINUX_DEFAULT, updated grub, and
rebooted.

>From there, I installed auditd, and stress-ng. I edited
/etc/audit/rules.d/audit.rules to include:

-a exit,always -F arch=b64 -S execve
-a exit,always -F arch=b32 -S execve

I then rebooted, and started stress-ng.

I checked the kmalloc-2k slab with:

$ watch "sudo cat /proc/meminfo | grep SUnreclaim"
$ watch "sudo cat /proc/slabinfo | grep kmalloc-2k"
$ sudo slabtop

Now, since this bug has been worked around by:

39cce16cfeed UBUNTU: SAUCE: LSM: Change Landlock from LSMBLOB_NEEDED to
LSMBLOB_NOT_NEEDED

in 5.15.0-53-generic, the kmalloc-k slab did not uncontrollably increase, but
that is okay, it is just the leak isn't reachable with landlock not using the
task_getsecid_obj hook.

This means this verification is more of a smoke test than checking root
cause.

I then enabled -proposed, and installed 5.15.0-68-generic, and rebooted.

I again ran stress-ng and checked the kmalloc-2k slab, and all was well, there
was no memory leak.

The core issue was fixed, but again, masked by the previous fix in 
5.15.0-53-generic. 

There was no smoke, and things ran as expected. Marking verified for
Jammy.

** Tags removed: verification-needed-jammy
** Tags added: verification-done-jammy

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

Title:
  Ubuntu 22.04 kernel 5.15.0-46-generic leaks kernel memory in
  kmalloc-2k slabs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Jammy:
  Fix Committed
Status in linux source package in Kinetic:
  Fix Released

Bug description:
  Since updating to kernel 5.15.0-46-generic (package version
  5.15.0-46.49), all of our Ubuntu 22.04 LTS servers are leaking kernel
  memory; our first server with 8 GB of RAM just fatally OOMed, causing
  us to detect this. Inspection of OOM reports, /proc/meminfo, and
  /proc/slabinfo says that it's mostly going to unreclaimable kmalloc-2k
  slabs:

  Aug 23 12:51:11 cluster kernel: [361299.864757] Unreclaimable slab 
info:
  Aug 23 12:51:11 cluster kernel: [361299.864757] Name  
Used  Total
  [...]
  Aug 23 12:51:11 cluster kernel: [361299.864924] kmalloc-2k   
6676584KB6676596KB

  Most of our machines appear to be leaking slab memory at a rate of
  around 20 to 40 Mbytes/hour, with some machines leaking much faster;
  the champions are leaking kernel memory at 145 Mbytes/hour and 237
  Mbytes/hour.

  We aren't running any proprietary kernel modules and our only unusual
  kernel configuration is that we've disabled AppArmor with 'apparmor=0'
  on the kernel command line.

  /proc/version_signature:
  Ubuntu 5.15.0-46.49-generic 5.15.39

  Full kernel command line from the Dell R240 system that fatally OOMd:
  BOOT_IMAGE=/boot/vmlinuz-5.15.0-46-generic 
root=UUID=3165564f-a2dd-4b39-935b-114f3e23ff54 ro console=ttyS0,115200 
console=tty0 apparmor=0

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2007219] Re: xfs: Preallocated ioend transactions cause deadlock due to log buffer exhaustion

2023-03-14 Thread Matthew Ruffell

Performing verification for Focal.

The customer in question installed 5.4.0-145-generic to their busy
production Kubernetes cluster, and have had no issues in the week and a
half the kernel has been running for. Before, they would suffer
deadlocks three or four times a day, so the kernel in -proposed fixes
the issue.

The customer is happy to mark this bug as verified for Focal.

** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

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

Title:
  xfs: Preallocated ioend transactions cause deadlock due to log buffer
  exhaustion

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Focal:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/2007219

  [Impact]

  A deadlock exists in the XFS filesystem that occurs when the XFS log
  buffer becomes completely exhausted.

  XFS maintains a circular ring buffer for the log, and it is a fixed
  size. To be able to create a transaction, you need to be able to
  reserve space on the log buffer.

  Certain ioend transactions, such as file append, can be preallocated
  for a negligible performance gain. This takes up space in the log
  buffer, and these preallocated ioends are placed on a workqueue,
  behind other ioends that are not preallocated.

  The deadlock occurs when the XFS log buffer is running low on space,
  and an ioend append transaction comes in. It is preallocated,
  consuming nearly all of the remaining XFS log buffer space, and is
  placed at the very end of the ioend workqueue. The kernel then takes a
  ioend from the top of the ioend workqeueue, creates a transaction,
  xfs_trans_alloc(), attempts to allocate space  for it,
  xfs_trans_reserve(), xfs_log_reserve(), and then waits in a while loop
  checking free space in the log, xlog_grant_head_check(),
  xlog_grant_head_wait().

  Since there is no space, the thread sleeps with schedule(). This
  happens with all ioend transactions, since the log is exhausted and
  I/O is not moving.

  Since I/O never moves, the thread is never woken up, and we get hung
  task timeouts, with system failure shortly afterward.

  An example hung task timeout is:

  INFO: task kworker/60:0:4002982 blocked for more than 360 seconds.
    Tainted: G   OE 5.4.0-137-generic #154-Ubuntu
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  kworker/60:0D0 4002982  2 0x90004080
  Workqueue: xfs-conv/dm-3 xfs_end_io [xfs]
  Call Trace:
   __schedule+0x2e3/0x740
   schedule+0x42/0xb0
   xlog_grant_head_wait+0xb9/0x1e0 [xfs]
   xlog_grant_head_check+0xde/0x100 [xfs]
   xfs_log_reserve+0xc9/0x1e0 [xfs]
   xfs_trans_reserve+0x17a/0x1e0 [xfs]
   xfs_trans_alloc+0xda/0x170 [xfs]
   xfs_iomap_write_unwritten+0x128/0x2f0 [xfs]
   xfs_end_ioend+0x15b/0x1b0 [xfs]
   xfs_end_io+0xb1/0xe0 [xfs]
   process_one_work+0x1eb/0x3b0
   worker_thread+0x4d/0x400
   kthread+0x104/0x140
   ? process_one_work+0x3b0/0x3b0
   ? kthread_park+0x90/0x90
   ret_from_fork+0x1f/0x40

  There is no known workaround, other than to have a larger log buffer
  at filesystem creation, but even then, it only buys you time until you
  get high enough load to exhaust the log buffer.

  [Fix]

  This was fixed in 5.13-rc1 by the following patch:

  commit 7cd3099f4925d7c15887d1940ebd65acd66100f5
  Author: Brian Foster 
  Date:   Fri Apr 9 10:27:43 2021 -0700
  Subject: xfs: drop submit side trans alloc for append ioends
  Link: 
https://github.com/torvalds/linux/commit/7cd3099f4925d7c15887d1940ebd65acd66100f5

  The patch more or less removes all preallocated ioend transactions,
  and instead, when ioend appends are needed, they go to the standard
  workqueue like any other ioend, where transactions are allocated when
  they reach the top of the workqueue.

  The patch required some backporting for Focal. The changes to the
  patch itself is minimal and should be straightforward to read,
  however, the changes to the XFS ioend subsystem between 5.4 and
  5.13-rc1 were quite extreme, with a lot of refactoring taking place
  over very many commits.

  Additionally, the patch was part of a five part series, the first,
  fixes the deadlock, and the rest remove all the code to do with
  transaction preallocation.

  It is safe to leave the rest of the code in place. It will become dead
  code, but it will not be reachable, and not cause any risk of
  regression, due to ioend->io_append_trans always being NULL, and not
  entering into any of the if statements.

  [Testcase]

  There is currently no known testcase for this issue. The issue has
  only been seen in a customer production environment, running under
  heavy load. The issue has not been seen in a customer test
  environment, only production.

  The production workload is a busy Kubernetes cluster running
  containers

[Kernel-packages] [Bug 2004132] Re: btrfs/154: rename fails with EOVERFLOW when calculating item size during item key collision

2023-03-13 Thread Matthew Ruffell

Performing verification for Bionic

I started a fresh VM with 4.15.0-206-generic from -updates. I attached 2x virtio
disks of 3gb each, for scratch disks.

I ran btrfs/154 with the following results:

# ./check btrfs/154
FSTYP -- btrfs
PLATFORM  -- Linux/x86_64 bionic-xfs 4.15.0-206-generic #217-Ubuntu SMP Fri 
Feb 3 19:10:13 UTC 2023
MKFS_OPTIONS  -- /dev/vdd
MOUNT_OPTIONS -- /dev/vdd /scratch

btrfs/154 4s ... _check_dmesg: something found in dmesg (see 
/home/ubuntu/xfstests-dev/results//btrfs/154.dmesg)
- output mismatch (see /home/ubuntu/xfstests-dev/results//btrfs/154.out.bad)
--- tests/btrfs/154.out 2023-01-28 02:53:03.566450703 +
+++ /home/ubuntu/xfstests-dev/results//btrfs/154.out.bad2023-03-14 
04:46:12.824848412 +
@@ -1,2 +1,6 @@
 QA output created by 154
+Traceback (most recent call last):
+  File "/home/ubuntu/xfstests-dev/src/btrfs_crc32c_forged_name.py", line 
99, in 
+os.rename(srcpath, dstpath)
+OSError: [Errno 75] Value too large for defined data type: '/scratch/309' 
-> 
b'/scratch/ec73\xb4\xd3?\xc4249e4acad9bcfc483738ce72c1da9a5e0dcc098e3103a2e00d8e05fe6a463df2c472d5df948dc08e6aaf48cdff3c41de690ce50cd88be6cdea40e616db44152df10f8dfe36a5de62550b277db85c01455dde98b189b68'
 Silence is golden
...
(Run 'diff -u /home/ubuntu/xfstests-dev/tests/btrfs/154.out 
/home/ubuntu/xfstests-dev/results//btrfs/154.out.bad'  to see the entire diff)
Ran: btrfs/154
Failures: btrfs/154
Failed 1 of 1 tests

[   69.108117] BTRFS: device fsid 032cd7d2-e729-4a6a-aa6d-95141191525a devid 1 
transid 5 /dev/vdc
[   78.693183] BTRFS info (device vdc): disk space caching is enabled
[   78.693184] BTRFS info (device vdc): has skinny extents
[   78.693185] BTRFS info (device vdc): flagging fs with big metadata feature
[   78.695928] BTRFS info (device vdc): creating UUID tree
[   78.828837] BTRFS: device fsid 053e2dfb-59fb-45ab-8a69-08262d44d669 devid 1 
transid 5 /dev/vdd
[   78.840701] BTRFS info (device vdd): disk space caching is enabled
[   78.840703] BTRFS info (device vdd): has skinny extents
[   78.840704] BTRFS info (device vdd): flagging fs with big metadata feature
[   78.843953] BTRFS info (device vdd): creating UUID tree
[   79.053524] BTRFS info (device vdc): disk space caching is enabled
[   79.053526] BTRFS info (device vdc): has skinny extents
[   79.104532] run fstests btrfs/154 at 2023-03-14 04:46:08
[   79.230124] BTRFS: device fsid af57acbb-7a45-46e8-969f-4cb3ce52e29e devid 1 
transid 5 /dev/vdd
[   79.235760] BTRFS info (device vdd): disk space caching is enabled
[   79.235761] BTRFS info (device vdd): has skinny extents
[   79.235761] BTRFS info (device vdd): flagging fs with big metadata feature
[   79.239893] BTRFS info (device vdd): creating UUID tree
[   82.714095] [ cut here ]
[   82.714098] BTRFS: Transaction aborted (error -75)
[   82.714180] WARNING: CPU: 2 PID: 1883 at 
/build/linux-sIqTXt/linux-4.15.0/fs/btrfs/inode.c:10217 
btrfs_rename+0xcf1/0xdf0 [btrfs]
[   82.714210] CPU: 2 PID: 1883 Comm: python3 Not tainted 4.15.0-206-generic 
#217-Ubuntu
[   82.714212] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.16.0-debian-1.16.0-4 04/01/2014
[   82.714234] RIP: 0010:btrfs_rename+0xcf1/0xdf0 [btrfs]
[   82.714235] RSP: 0018:af86c1adfd20 EFLAGS: 00010282
[   82.714238] RAX:  RBX: 96e6f7bac118 RCX: 0006
[   82.714239] RDX: 0007 RSI: 0096 RDI: 96e6ffd1b4d0
[   82.714240] RBP: af86c1adfdc0 R08: 02d9 R09: 0004
[   82.714241] R10:  R11: 0001 R12: 0236
[   82.714242] R13: 96e6f6842618 R14: 96e6f7b78cc0 R15: 96e6f7bac118
[   82.714245] FS:  7fbf05988740() GS:96e6ffd0() 
knlGS:
[   82.714246] CS:  0010 DS:  ES:  CR0: 80050033
[   82.714248] CR2: 7fbf058ef4c8 CR3: 000175166005 CR4: 00760ee0
[   82.714254] PKRU: 5554
[   82.714255] Call Trace:
[   82.714277]  btrfs_rename2+0x1d/0x30 [btrfs]
[   82.714283]  vfs_rename+0x46e/0x960
[   82.714287]  SyS_rename+0x362/0x3c0
[   82.714293]  do_syscall_64+0x73/0x130
[   82.714297]  entry_SYSCALL_64_after_hwframe+0x59/0xbe
[   82.714299] RIP: 0033:0x7fbf053f8ce7
[   82.714300] RSP: 002b:7ffdb2ba86d8 EFLAGS: 0246 ORIG_RAX: 
0052
[   82.714302] RAX: ffda RBX: 7ffdb2ba8790 RCX: 7fbf053f8ce7
[   82.714303] RDX:  RSI: 7fbf044872f0 RDI: 7fbf057dafb0
[   82.714304] RBP: ff00 R08:  R09: 00713557
[   82.714306] R10:  R11: 0246 R12: 7ffdb2ba8740
[   82.714307] R13: ff9c R14: ff9c R15: 01365da0
[   82.714309] Code: 0f ba a8 d0 cd 00 00 02 72 2b 41 83 f8 fb 0f 84 d9 00 00 
00 44 89 c6 48 c7 c7 68 83 43 c0 44 89 55 80 44 89 45 98 e8 6f 1c 0e f5 <0f> 0b 
44 8b 45 98 44 8b 55 80 44 89 55 80 44

[Kernel-packages] [Bug 2004132] Re: btrfs/154: rename fails with EOVERFLOW when calculating item size during item key collision

2023-03-13 Thread Matthew Ruffell

Performing verification for Focal

I started a fresh VM with 5.4.0-144-generic from -updates. I attached 2x virtio
disks of 3gb each, for scratch disks.

I ran btrfs/154 with the following results:

# ./check btrfs/154
FSTYP -- btrfs
PLATFORM  -- Linux/x86_64 focal-xfs 5.4.0-144-generic #161-Ubuntu SMP Fri 
Feb 3 14:49:04 UTC 2023
MKFS_OPTIONS  -- /dev/vdd
MOUNT_OPTIONS -- /dev/vdd /scratch

btrfs/154 4s ... _check_dmesg: something found in dmesg (see 
/home/ubuntu/xfstests-dev/results//btrfs/154.dmesg)
- output mismatch (see /home/ubuntu/xfstests-dev/results//btrfs/154.out.bad)
--- tests/btrfs/154.out 2023-01-28 07:54:34.007433164 +
+++ /home/ubuntu/xfstests-dev/results//btrfs/154.out.bad2023-03-14 
04:34:53.765899711 +
@@ -1,2 +1,6 @@
 QA output created by 154
+Traceback (most recent call last):
+  File "/home/ubuntu/xfstests-dev/src/btrfs_crc32c_forged_name.py", line 
99, in 
+os.rename(srcpath, dstpath)
+OSError: [Errno 75] Value too large for defined data type: '/scratch/309' 
-> 
b'/scratch/69f3?u\x97\xf3c33c58c648a2a9686fad82dbf43d7bfb443de4698f629e5b2b95126d6382430b8f29e4f502ccf306254d24cfd3800cb04a305989253db49f699a83cc2bc5d86a4f9b235891c0f72ba344a34e41aa69f819f196f7dbf29'
 Silence is golden
...
(Run 'diff -u /home/ubuntu/xfstests-dev/tests/btrfs/154.out 
/home/ubuntu/xfstests-dev/results//btrfs/154.out.bad'  to see the entire diff)
Ran: btrfs/154
Failures: btrfs/154
Failed 1 of 1 tests

[   49.889518] BTRFS info (device vdc): flagging fs with big metadata feature
[   49.889520] BTRFS info (device vdc): disk space caching is enabled
[   49.889521] BTRFS info (device vdc): has skinny extents
[   49.891250] BTRFS info (device vdc): checking UUID tree
[   50.007425] BTRFS: device fsid 382d436d-5f41-48a3-b96d-42c07ede9a03 devid 1 
transid 5 /dev/vdd
[   50.012807] BTRFS info (device vdd): flagging fs with big metadata feature
[   50.012809] BTRFS info (device vdd): disk space caching is enabled
[   50.012810] BTRFS info (device vdd): has skinny extents
[   50.014307] BTRFS info (device vdd): checking UUID tree
[   50.171099] BTRFS info (device vdc): flagging fs with big metadata feature
[   50.171102] BTRFS info (device vdc): disk space caching is enabled
[   50.171103] BTRFS info (device vdc): has skinny extents
[   50.204928] run fstests btrfs/154 at 2023-03-14 04:34:47
[   50.378091] BTRFS: device fsid 68eee97a-92e0-47da-9d5e-c6c8312ee358 devid 1 
transid 5 /dev/vdd
[   50.393188] BTRFS info (device vdd): flagging fs with big metadata feature
[   50.393191] BTRFS info (device vdd): disk space caching is enabled
[   50.393193] BTRFS info (device vdd): has skinny extents
[   50.401657] BTRFS info (device vdd): checking UUID tree
[   56.084117] [ cut here ]
[   56.084121] BTRFS: Transaction aborted (error -75)
[   56.084229] WARNING: CPU: 2 PID: 1741 at fs/btrfs/inode.c:10148 
btrfs_rename+0x9c6/0xa40 [btrfs]
[   56.084265] CPU: 2 PID: 1741 Comm: python3 Not tainted 5.4.0-144-generic 
#161-Ubuntu
[   56.084267] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.16.0-debian-1.16.0-4 04/01/2014
[   56.084302] RIP: 0010:btrfs_rename+0x9c6/0xa40 [btrfs]
[   56.084306] Code: 48 0f ba a8 38 ce 00 00 02 72 25 41 83 f8 fb 74 43 41 83 
f8 e2 74 3d 44 89 c6 48 c7 c7 e0 68 49 c0 44 89 45 a0 e8 ac 2c 0a e6 <0f> 0b 44 
8b 45 a0 44 89 c1 ba a4 27 00 00 4c 89 f7 44 89 45 a0 48
[   56.084309] RSP: 0018:bb1182f17cd8 EFLAGS: 00010286
[   56.084311] RAX:  RBX: 9ca8b7114210 RCX: 0006
[   56.084313] RDX: 0007 RSI: 0086 RDI: 9ca8bbb1c8c0
[   56.084314] RBP: bb1182f17d70 R08: 032b R09: 0004
[   56.084315] R10:  R11: 0001 R12: 9ca8b7104b40
[   56.084317] R13: 9ca8b726a220 R14: 9ca8b7b03548 R15: 0236
[   56.084320] FS:  7f3e9e8be740() GS:9ca8bbb0() 
knlGS:
[   56.084321] CS:  0010 DS:  ES:  CR0: 80050033
[   56.084323] CR2: 7fb85fbc5110 CR3: 00016c17e004 CR4: 00760ee0
[   56.084331] PKRU: 5554
[   56.084333] Call Trace:
[   56.084364]  btrfs_rename2+0x1d/0x30 [btrfs]
[   56.084371]  vfs_rename+0x3df/0x9b0
[   56.084377]  ? _cond_resched+0x19/0x30
[   56.084383]  ? security_path_rename+0x88/0xb0
[   56.084387]  do_renameat2+0x507/0x570
[   56.084391]  __x64_sys_rename+0x23/0x30
[   56.084397]  do_syscall_64+0x57/0x190
[   56.084401]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
[   56.084403] RIP: 0033:0x7f3e9eaece8b
[   56.084406] Code: e8 ca ce 0a 00 85 c0 0f 95 c0 0f b6 c0 f7 d8 5d c3 66 0f 
1f 44 00 00 b8 ff ff ff ff 5d c3 90 f3 0f 1e fa b8 52 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 d1 8f 18 00 f7 d8
[   56.084408] RSP: 002b:7ffddfe043f8 EFLAGS: 0246 ORIG_RAX: 
0052
[   56.084410] RAX: ffda RBX: 7ffddfe044c0 RCX: 7f3e9eaece8b
[   56.084412]

[Kernel-packages] [Bug 2009882] Re: Linux 5.4.0-144-generic x86_64 multithread / fork issues

2023-03-09 Thread Matthew Ruffell

Hi Alfredo,

Do you happen to use NFSv3 in your environment? There was a regression
in 5.4.0-144-generic that cased a massive spike in ACCESS requests being
made, which could explain low performance.

bug 2009325

Thanks,
Matthew

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

Title:
  Linux 5.4.0-144-generic x86_64 multithread / fork issues

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  We have same servers already running in 5.4.0-122 , 126, 128 and 131
  releases with no issues whatsoever and exceptional good performance.
  They basically have either Apache/2.4.41/mod_php7.4 or
  Apache/2.4.41/mpm_event with phm7.4-fpm setups, all working perfect.

  When we load kernel 5.4.0-144 CPU processing go thru the roof, and
  process kworker/u17:0-xprtiod show at the top. Both setups perform
  badly with Apache performance going avg 200ms/req in older kernels to
  over 4,500ms/req in this 144 release. CPU usage from avg 0.4% to over
  50% under same traffic and requests rate.

  We just reloaded old kernels back, via /etc/default/grub, and
  performance is right back.  Same packages, same services, everything
  the same but the Linux kernel.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.4.0-144-generic 5.4.0-144.161
  ProcVersionSignature: Ubuntu 5.4.0-144.161-generic 5.4.229
  Uname: Linux 5.4.0-144-generic x86_64
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Mar  9 13:21 seq
   crw-rw 1 root audio 116, 33 Mar  9 13:21 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu27.25
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: pass
  Date: Thu Mar  9 13:22:31 2023
  InstallationDate: Installed on 2021-11-17 (477 days ago)
  InstallationMedia: Ubuntu-Server 20.04.3 LTS "Focal Fossa" - Release amd64 
(20210824)
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
   Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
   |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
   |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/7p, 12M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
  MachineType: VMware, Inc. VMware Virtual Platform
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 svgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-144-generic 
root=/dev/mapper/ubuntu--vg-ubuntu--lv ro maybe-ubiquity
  RelatedPackageVersions:
   linux-restricted-modules-5.4.0-144-generic N/A
   linux-backports-modules-5.4.0-144-generic  N/A
   linux-firmware 1.187.36
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/12/2018
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd12/12/2018:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
  dmi.product.name: VMware Virtual Platform
  dmi.product.version: None
  dmi.sys.vendor: VMware, Inc.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2009325] Re: NFS deathlock with last Kernel 5.4.0-144.161 and 5.15.0-67.74

2023-03-06 Thread Matthew Ruffell

** Tags added: seg

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

Title:
  NFS deathlock with last Kernel 5.4.0-144.161 and 5.15.0-67.74

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After updating on the kernel 
  5.4.0-144.161 at Ubuntu 18 and 
  5.15.0-67.74 at Ubuntu 20, 
  we have a 100% CPU outlation and 20 to 30 Mbit traffic to the clients for our 
NFS servers.

  All clients are extremely slow when it comes to access to the NFS
  resources.

  Restart and use older kernel, fixed the problem.
  Ubuntu 18 5.4.0-139-generic
  Ubuntu 20 5.15.0-60-Generic
  I don't have a NFS problem with this kernel.

  Problem came with the last releas on March 3rd, 2023
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Mär  4 15:00 seq
   crw-rw 1 root audio 116, 33 Mär  4 15:00 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu27.25
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CasperMD5CheckResult: skip
  DistroRelease: Ubuntu 20.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  Lsusb-t:
   
  Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
  MachineType: VMware, Inc. VMware Virtual Platform
  Package: linux (not installed)
  PciMultimedia:
   
  ProcFB: 0 svgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.15.0-67-generic 
root=/dev/mapper/vg1-root ro net.ifnames=0 biosdevname=0 kvm.nx_huge_pages=auto 
elevator=noop
  ProcVersionSignature: Ubuntu 5.15.0-67.74~20.04.1-generic 5.15.85
  RelatedPackageVersions:
   linux-restricted-modules-5.15.0-67-generic N/A
   linux-backports-modules-5.15.0-67-generic  N/A
   linux-firmware 1.187.36
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill'
  Tags:  focal
  Uname: Linux 5.15.0-67-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: N/A
  _MarkForUpload: True
  dmi.bios.date: 11/12/2020
  dmi.bios.release: 4.6
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.ec.firmware.release: 0.0
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd11/12/2020:br4.6:efr0.0:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:sku:
  dmi.product.name: VMware Virtual Platform
  dmi.product.version: None
  dmi.sys.vendor: VMware, Inc.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Mär  4 15:03 seq
   crw-rw 1 root audio 116, 33 Mär  4 15:03 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.28
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  DistroRelease: Ubuntu 18.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb: Error: command ['lsusb'] failed with exit code 1:
  MachineType: VMware, Inc. VMware Virtual Platform
  Package: linux (not installed)
  PciMultimedia:
   
  ProcFB: 0 svgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.0.0-43-generic 
root=/dev/mapper/vg1-root ro net.ifnames=0 biosdevname=0 kvm.nx_huge_pages=auto 
elevator=noop
  ProcVersionSignature: Ubuntu 5.0.0-43.47~18.04.1-generic 5.0.21
  RelatedPackageVersions:
   linux-restricted-modules-5.0.0-43-generic N/A
   linux-backports-modules-5.0.0-43-generic  N/A
   linux-firmware1.173.21
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 5.0.0-43-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: True
  dmi.bios.date: 12/12/2018
  dmi.bios.vendor: Phoenix Technologies LTD
  dmi.bios.version: 6.00
  dmi.board.name: 440BX Desktop Reference Platform
  dmi.board.vendor: Intel Corporation
  dmi.board.version: None
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 1
  dmi.chassis.vendor: No Enclosure
  dmi.chassis.version: N/A
  dmi.modalias: 
dmi:bvnPhoenixTechnologiesLTD:bvr6.00:bd12/12/2018:svnVMware,Inc.:pnVMwareVirtualPlatform:pvrNone:rvnIntelCorporation:rn440BXDesktopReferencePlatform:rvrNone:cvnNoEnclosure:ct1:cvrN/A:
  dmi.product.name: VMware

[Kernel-packages] [Bug 1987430] Re: Ubuntu 22.04 kernel 5.15.0-46-generic leaks kernel memory in kmalloc-2k slabs

2023-02-19 Thread Matthew Ruffell

Hi JianlinLV,

I tried the latest 5.15.0-60-generic kernel from -updates, and I
couldn't reproduce the issue anymore.

Can you try 5.15.0-60-generic and let me know?

I bisected it down to 5.15.0-52-generic being broken, and it being fixed
in 5.15.0-53-generic.

Still trying to find the commit which fixed the issue.

I had a read of your patch, and it fixes a part of the Apparmor LSM
Stacking patchset that Ubuntu carries out of tree. The upstream code has
changed a bit from what is found in the 5.15.0-x-generic kernel in
Jammy. https://patchew.org/linux/20220927195421.14713-1-casey@schaufler-
ca.com/

Let me know how 5.15.0-60-generic goes.

Thanks,
Matthew

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

Title:
  Ubuntu 22.04 kernel 5.15.0-46-generic leaks kernel memory in
  kmalloc-2k slabs

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Jammy:
  In Progress
Status in linux source package in Kinetic:
  In Progress

Bug description:
  Since updating to kernel 5.15.0-46-generic (package version
  5.15.0-46.49), all of our Ubuntu 22.04 LTS servers are leaking kernel
  memory; our first server with 8 GB of RAM just fatally OOMed, causing
  us to detect this. Inspection of OOM reports, /proc/meminfo, and
  /proc/slabinfo says that it's mostly going to unreclaimable kmalloc-2k
  slabs:

  Aug 23 12:51:11 cluster kernel: [361299.864757] Unreclaimable slab 
info:
  Aug 23 12:51:11 cluster kernel: [361299.864757] Name  
Used  Total
  [...]
  Aug 23 12:51:11 cluster kernel: [361299.864924] kmalloc-2k   
6676584KB6676596KB

  Most of our machines appear to be leaking slab memory at a rate of
  around 20 to 40 Mbytes/hour, with some machines leaking much faster;
  the champions are leaking kernel memory at 145 Mbytes/hour and 237
  Mbytes/hour.

  We aren't running any proprietary kernel modules and our only unusual
  kernel configuration is that we've disabled AppArmor with 'apparmor=0'
  on the kernel command line.

  /proc/version_signature:
  Ubuntu 5.15.0-46.49-generic 5.15.39

  Full kernel command line from the Dell R240 system that fatally OOMd:
  BOOT_IMAGE=/boot/vmlinuz-5.15.0-46-generic 
root=UUID=3165564f-a2dd-4b39-935b-114f3e23ff54 ro console=ttyS0,115200 
console=tty0 apparmor=0

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort

2023-02-17 Thread Matthew Ruffell

Hi William,

I sincerely apologise for the delay.

Currently libunwind is stuck in -proposed due to benign autopkgtest
regressions in the kernel packages.

If you go to the below page:

https://people.canonical.com/~ubuntu-archive/pending-sru.html

And search for "libunwind" you will see entries for Bionic and Focal.

It is SRU policy to not release a package with current autopkgtest
regressions.

Now, I have spent more time than I am willing to admit on trying to
debug these failures, and I have also asked the Kernel Team, several
which took a look, and some Launchpad admins, and we are still a bit
stuck. The problem does not reproduce locally, only on Launchpad
builders.

For example, take the 4.15 Bionic Kernel:

https://autopkgtest.ubuntu.com/packages/l/linux/bionic/amd64

(it is a reverse dependency of libunwind, which is why it is selected
for autopkgtest)

https://autopkgtest.ubuntu.com/results/autopkgtest-
bionic/bionic/amd64/l/linux/20230110_115614_09e98@/log.gz

It rebuilds fine, but then runs into apt resolver trouble when running
the kernel testsuite.

autopkgtest makes a dummy package, that contains the list of necessary
dependencies to run the testsuite, dpkg -i to install the package, and
then does an apt install -f to force dependency resolution. The dummy
package is called autopkgtest-satdep.

https://paste.ubuntu.com/p/Cszfkvy47Z/

But it fails in strange ways, like not being able to select build-
essential, even though it is already installed in the builder.

I am still trying to debug the root cause behind these autopkgtest
regressions, which is why things have been delayed.

There is a provision in SRUs where they can be released as long as I can
prove that the upload did not cause the regression:

https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

In which case, I may as well invoke this clause, since I don't wish to
keep you waiting any longer.

I will try and get this package released within the week.

Thanks,
Matthew

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libunwind in Ubuntu.
https://bugs.launchpad.net/bugs/1999104

Title:
  arm64: broken c++ exception handler support leads to std::terminate()
  being called and program abort

Status in libunwind package in Ubuntu:
  Fix Released
Status in libunwind source package in Bionic:
  Fix Committed
Status in libunwind source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  On architectures other than i386 and amd64, the C++ exception support
  in libunwind appears to be broken, always failing and calling
  std::terminate() which leads to the program aborting.

  (gdb) bt
  #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
  #1  0xf7c2daac in __GI_abort () at abort.c:79
  #2  0xf7e21868 in __gnu_cxx::__verbose_terminate_handler() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #3  0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
  #4  0xf7e1f280 in std::terminate() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #5  0xf7e1f5e0 in __cxa_rethrow ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #6  0xf7e21804 in __gnu_cxx::__verbose_terminate_handler() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #7  0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
  #8  0xf7e1f280 in std::terminate() ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #9  0xf7e1f574 in __cxa_throw ()
 from /lib/aarch64-linux-gnu/libstdc++.so.6
  #10 0xf7fb9f50 in function_throws_int () at lib.cpp:9
  #11 0x0d54 in main (argc=1, argv=0xfab8) at main.cpp:9

  Compiling libunwind with --enable-cxx-exceptions enabled leads to
  _Unwind_RaiseException being called during __cxa_throw(), which fails
  to find a handler, and the generic std::terminate() is called instead,
  aborting the program.

  On i386 and amd64 this doesn't seem to be the case, and the libunwind
  handlers seem to be present.

  To fix, we only enable the configure option --enable-cxx-exceptions on
  i386 and amd64 only, in debian/rules. This lets other architectures
  fall back to the symbols provided by libgcc_s, which implementation
  works correctly.

  [Testcase]

  Ali Sadi has provided a reproducer program.

  Start an arm64 instance, for example, a c6g.medium instance on AWS,
  with either Bionic or Focal.

  $ wget 
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635122/+files/libunwind.tar.gz
  $ sudo apt install -y build-essential libunwind-dev
  $ tar xvf libunwind.tar.gz && cd test
  $ make all

  There are two executable, main and main_unwind. main is not linked to
  libunwind, and main_unwind is linked to libunwind.

  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  terminate called after throwing an instance of 'int'
  terminate called recursively
  Aborted

[Kernel-packages] [Bug 1962485] Re: Kernel Crash [general protection fault: 0000 [#1] SMP NOPTI]

2023-02-16 Thread Matthew Ruffell

ovs-vsctl[51186]: ovs|1|vsctl|INFO|Called as ovs-vsctl --timeout=120 
--oneline --format=json --db=tcp:127.0.0.1:6640 -- --if-exists del-port br-int 
tap8c883ee5-5f
kernel: device tap8c883ee5-5f left promiscuous mode
lldpd[2309]: removal request for address of fe80::fc16:3eff:fe07:2be2%27, but 
no knowledge of it
systemd-networkd[1608]: tap8c883ee5-5f: Link DOWN
systemd-networkd[1608]: tap8c883ee5-5f: Lost carrier
kernel: general protection fault:  [#1] SMP NOPTI
kernel: CPU: 41 PID: 25064 Comm: privsep-helper Tainted: GW 
5.4.0-81-generic #91~18.04.1-Ubuntu
kernel: Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 
07/16/2020
kernel: RIP: 0010:count_subheaders.part.15+0x41/0x60
kernel: Code: 31 e4 53 48 89 fb 48 8b 7b 18 48 85 ff 75 1b 41 bc 01 00 00 00 48 
83 c3 40 48 83 3b 00 75 e7 43 8d 04 2c 5b 41 5c 41 5d 5d c3 <48> 83 3f 00 b8 01 
00 00 00 74 05 e8 af ff ff ff 41 01 c5 eb d6 31
kernel: RSP: 0018:a8fa4d0437a0 EFLAGS: 00010286
kernel: RAX: 0001 RBX: 98cfefac0800 RCX: 
kernel: RDX: 001b RSI: 98f85782cac0 RDI: 8c0a25048c0abfe4
kernel: RBP: a8fa4d0437b8 R08:  R09: 000a
kernel: R10: a8fa4d0438e8 R11: 00031220 R12: 
kernel: R13:  R14: 98cff12e R15: 98f85782ca00
kernel: FS:  7f7f3f9f9700() GS:98e05fb4() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 0225b7f8 CR3: 00248bf1c006 CR4: 007626e0
kernel: DR0:  DR1:  DR2: 
kernel: DR3:  DR6: fffe0ff0 DR7: 0400
kernel: PKRU: 5554
kernel: Call Trace:
kernel:  count_subheaders.part.15+0x51/0x60
kernel:  unregister_sysctl_table+0x31/0xb0
kernel:  unregister_net_sysctl_table+0xe/0x10
kernel:  __devinet_sysctl_unregister.isra.25+0x2b/0x50
kernel:  devinet_sysctl_unregister+0x29/0x40
kernel:  inetdev_event+0x1f0/0x570
kernel:  ? skb_dequeue+0x60/0x70
kernel:  notifier_call_chain+0x4c/0x70
kernel:  ? notifier_call_chain+0x4c/0x70
kernel:  ? tun_show_group+0x60/0x60
kernel:  raw_notifier_call_chain+0x16/0x20
kernel:  call_netdevice_notifiers_info+0x2d/0x60
kernel:  rollback_registered_many+0x346/0x520
kernel:  ? mem_cgroup_throttle_swaprate+0x1d/0x140
kernel:  unregister_netdevice_many.part.127+0x12/0x90
kernel:  unregister_netdevice_many+0x16/0x20
kernel:  rtnl_delete_link+0x4e/0x80
kernel:  rtnl_dellink+0x12d/0x2b0
kernel:  ? __nla_parse+0x22/0x30
kernel:  ? rtnl_dump_ifinfo+0x360/0x5d0
kernel:  ? ns_capable+0x10/0x20
kernel:  rtnetlink_rcv_msg+0x296/0x340
kernel:  ? aa_label_sk_perm.part.4+0x10f/0x160
kernel:  ? _cond_resched+0x19/0x40
kernel:  ? rtnl_calcit.isra.30+0x120/0x120
kernel:  netlink_rcv_skb+0x51/0x120
kernel:  rtnetlink_rcv+0x15/0x20
kernel:  netlink_unicast+0x1a4/0x250
kernel:  netlink_sendmsg+0x2eb/0x3f0
kernel:  sock_sendmsg+0x63/0x70
kernel:  __sys_sendto+0x13f/0x180
kernel:  ? handle_mm_fault+0xcb/0x210
kernel:  ? __do_page_fault+0x2be/0x4d0
kernel:  __x64_sys_sendto+0x28/0x30
kernel:  do_syscall_64+0x57/0x190
kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9

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

Title:
  Kernel Crash [general protection fault:  [#1] SMP NOPTI]

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I am running openstack xena release on ubuntu focal. Today my compute
  node running ubuntu focal crashed with due to kernel and dump has been
  generated in /var/crash/. Below is the kernel trace in crash dump.

  [455151.890114] general protection fault:  [#1] SMP NOPTI
  [455151.890285] CPU: 43 PID: 83232 Comm: qemu-system-x86 Kdump: loaded 
Tainted: G   OE 5.4.0-88-generic #99-Ubuntu
  [455151.890612] Hardware name: Dell Inc. PowerEdge R6525/X, BIOS 2.5.6 
10/06/2021
  [455151.890842] RIP: 0010:count_subheaders.part.0+0x26/0x60
  [455151.890998] Code: 00 00 00 90 0f 1f 44 00 00 48 83 3f 00 74 4d 55 48 89 
e5 41 55 45 31 ed 41 54 45 31 e4 53 48 89 fb 48 8b 7b 18 48 85 ff 74 23 <48> 83 
3f 00 74 25 e8 cf ff ff ff 41 
  01 c5 48 83 c3 40 48 83 3b 00
  [455151.891552] RSP: 0018:a6b477487b88 EFLAGS: 00010202
  [455151.891707] RAX:  RBX: 9387c594f280 RCX: 

  [455151.891918] RDX: 0060 RSI: 9390702a72c0 RDI: 
0314a8c0f1b16f3e
  [455151.892130] RBP: a6b477487ba0 R08:  R09: 
bc6ed7f0
  [455151.892341] R10: a6b477487cd0 R11: 0001 R12: 

  [455151.892552] R13:  R14: 9391e5684000 R15: 
bd5f9880
  [455151.892767] FS:  7f69950c75c0() GS:9391feac() 
knlGS:
  [455151.893016] CS:  0010 DS:  ES:  CR0: 80050033
  [455151.893207] CR2:

[Kernel-packages] [Bug 1962485] Re: Kernel Crash [general protection fault: 0000 [#1] SMP NOPTI]

2023-02-16 Thread Matthew Ruffell

Hi David,

Thanks for the link, I think that is the most plausible explanation I have
seen so far.

The only problem is, if we look at the patch:

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 7a3ab3427369..24001112c323 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -686,7 +686,6 @@ static void __tun_detach(struct tun_file *tfile, bool clean)
if (tun)
xdp_rxq_info_unreg(>xdp_rxq);
ptr_ring_cleanup(>tx_ring, tun_ptr_free);
-   sock_put(>sk);
}
 }
 
@@ -702,6 +701,9 @@ static void tun_detach(struct tun_file *tfile, bool clean)
if (dev)
netdev_state_change(dev);
rtnl_unlock();
+
+   if (clean)
+   sock_put(>sk);
 }
 
 static void tun_detach_all(struct net_device *dev)

It moves the final sock_put(>sk) from the end of __tun_detach()
to tun_detach(), after the call to netdev_state_change(dev).

 685 static void __tun_detach(struct tun_file *tfile, bool clean)
 686 {
...
 725 if (clean) {
 726 if (tun && tun->numqueues == 0 && tun->numdisabled == 0) {
 727 netif_carrier_off(tun->dev);
 728 
 729 if (!(tun->flags & IFF_PERSIST) &&
 730 tun->dev->reg_state == NETREG_REGISTERED)
 731 unregister_netdevice(tun->dev);
 732 }
 733 if (tun)
 734 xdp_rxq_info_unreg(>xdp_rxq);
 735 ptr_ring_cleanup(>tx_ring, tun_ptr_free);
 736 sock_put(>sk);
 737 }
 738 }
 739 
 740 static void tun_detach(struct tun_file *tfile, bool clean)
 741 {
 742 struct tun_struct *tun;
 743 struct net_device *dev;
 744 
 745 rtnl_lock();
 746 tun = rtnl_dereference(tfile->tun);
 747 dev = tun ? tun->dev : NULL;
 748 __tun_detach(tfile, clean);
 749 if (dev)
 750 netdev_state_change(dev);
 751 rtnl_unlock();
 752 }
 
This more or less makes sense, but if you look at the call trace in the bug:

...
[455151.89] notifier_call_chain+0x55/0x80
...
[455151.895239] unregister_netdevice_queue+0x94/0x120
[455151.895383] __tun_detach+0x421/0x430
...

$ eu-addr2line -ifae ./vmlinux-5.4.0-88-generic  __tun_detach+0x421
0x8178b991
unregister_netdevice inlined at 
/build/linux-q2DMsi/linux-5.4.0/drivers/net/tun.c:731:5 in __tun_detach
/build/linux-q2DMsi/linux-5.4.0/include/linux/netdevice.h:2677:1
__tun_detach
/build/linux-q2DMsi/linux-5.4.0/drivers/net/tun.c:731:5

We get to notifier_call_chain() not from netdev_state_change() as
mentioned in the bug report, but unregister_netdevice() from line 731.
This means we haven't yet run sock_put(>sk) from line 736.

Puzzling isn't it? There are calls to sock_put(>sk) earlier in
__tun_detach(), maybe it freed the socket buffer already, which would
explain the behaviour.

But then when we run sock_put(>sk) again, wouldn't we then run
into use-after-free territory, when we try free the socket buffer again?

1735 /* Ungrab socket and destroy it, if it was the last reference. */
1736 static inline void sock_put(struct sock *sk)
1737 {
1738 if (refcount_dec_and_test(>sk_refcnt))
1739 sk_free(sk);
1740 }

I have a second call trace that I have been debugging along with the one
in the description, I'll add it in the next comment.

I'll keep looking into the patch anyway. I have been running the
syzkaller reproducer in a VM for the last few hours, but I haven't
reproduced yet.

https://syzkaller.appspot.com/bug?id=96eb7f1ce75ef933697f24eeab928c4a716edefe
https://groups.google.com/g/syzkaller-bugs/c/C0r0nwrvBME/m/MxQ5Z7_VBAAJ
https://syzkaller.appspot.com/x/repro.c?x=11bd3a10f0

Thanks,
Matthew

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

Title:
  Kernel Crash [general protection fault:  [#1] SMP NOPTI]

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I am running openstack xena release on ubuntu focal. Today my compute
  node running ubuntu focal crashed with due to kernel and dump has been
  generated in /var/crash/. Below is the kernel trace in crash dump.

  [455151.890114] general protection fault:  [#1] SMP NOPTI
  [455151.890285] CPU: 43 PID: 83232 Comm: qemu-system-x86 Kdump: loaded 
Tainted: G   OE 5.4.0-88-generic #99-Ubuntu
  [455151.890612] Hardware name: Dell Inc. PowerEdge R6525/X, BIOS 2.5.6 
10/06/2021
  [455151.890842] RIP: 0010:count_subheaders.part.0+0x26/0x60
  [455151.890998] Code: 00 00 00 90 0f 1f 44 00 00 48 83 3f 00 74 4d 55 48 89 
e5 41 55 45 31 ed 41 54 45 31 e4 53 48 89 fb 48 8b 7b 18 48 85 ff 74 23 <48> 83 
3f 00 74 25 e8 cf ff ff ff 41 
  01 c5 48 83 c3 40 48 83 3b 00
  [455151.891552] RSP: 0018:a6b477487b88 EFLAGS: 00010202
  [455151.891707] RAX:  RBX: 9387c594f280 RCX: 

  [455151.891918] RDX: 0060 RSI: 9390702a72c0 RDI: 
0314a8c0f1b16f3e

[Kernel-packages] [Bug 2007219] [NEW] xfs: Preallocated ioend transactions cause deadlock due to log buffer exhaustion

2023-02-13 Thread Matthew Ruffell

ated, at
the top of the workqueue when it is processed, and not preallocated when
the ioend is first submitted.

There will be a very minor performance penalty, but it wouldn't be
measurable in any tangible workload.

I have run xfstests for the xfs/* subset against the released
5.4.0-137-generic and the test 5.4.0-137-generic test kernel with the
patch included. The test kernel had identical results, it will likely
not cause any regressions.

There is some additional risk leaving the dead code in place, but I have
read the code and the commits to remove the dead code, and I came to the
conclusion it is less risky to leave it in place, than to backport the
refactor commits.

[Other Info]

The XFS ioend subsystem refactor took place in the following commits:

commit 598ecfbaa742aca0dcdbbea25681406f95cc0b63
From: Christoph Hellwig 
Date: Thu, 17 Oct 2019 13:12:15 -0700
Subject: iomap: lift the xfs writeback code to iomap
Link: 
https://github.com/torvalds/linux/commit/598ecfbaa742aca0dcdbbea25681406f95cc0b63

commit 9e91c5728cab3d0aa3197d009c3d63e147914e77
From: Christoph Hellwig 
Date: Thu, 17 Oct 2019 13:12:13 -0700
Subject: iomap: lift common tracing code from xfs to iomap
Link: 
https://github.com/torvalds/linux/commit/9e91c5728cab3d0aa3197d009c3d63e147914e77

commit 433dad94ec5d6b90385b56a8bc8718dd9542b289
From: Christoph Hellwig 
Date: Thu, 17 Oct 2019 13:12:07 -0700
Subject: xfs: refactor the ioend merging code
Link: 
https://github.com/torvalds/linux/commit/433dad94ec5d6b90385b56a8bc8718dd9542b289

ioend->io_append_trans was renamed to ioend->io_private in the following
commit:

commit 5653017bc44e54baa299f3523f160c23ac0628fd
From: Christoph Hellwig 
Date: Thu, 17 Oct 2019 13:12:09 -0700
Subject: xfs: turn io_append_trans into an io_private void pointer
Link: 
https://github.com/torvalds/linux/commit/5653017bc44e54baa299f3523f160c23ac0628fd

The full five part preallocated ioend deadlock patch series is:

commit 7cd3099f4925d7c15887d1940ebd65acd66100f5
Author: Brian Foster 
Date:   Fri Apr 9 10:27:43 2021 -0700
Subject: xfs: drop submit side trans alloc for append ioends
Link: 
https://github.com/torvalds/linux/commit/7cd3099f4925d7c15887d1940ebd65acd66100f5

commit 7adb8f14e134d5f885d47c4ccd620836235f0b7f
Author: Brian Foster 
Date:   Fri Apr 9 10:27:55 2021 -0700
Subject: xfs: open code ioend needs workqueue helper
Link: 
https://github.com/torvalds/linux/commit/7adb8f14e134d5f885d47c4ccd620836235f0b7f

commit 044c6449f18f174ba8d86640936add3fc7582e49
Author: Brian Foster 
Date:   Fri Apr 9 10:27:55 2021 -0700
Subject: xfs: drop unused ioend private merge and setfilesize code
Link: 
https://github.com/torvalds/linux/commit/044c6449f18f174ba8d86640936add3fc7582e49

commit e7a3d7e792a5ad50583a2e6c35e72bd2ca6096f4
Author: Brian Foster 
Date:   Fri Apr 9 10:27:56 2021 -0700
Subject: xfs: drop unnecessary setfilesize helper
Link: 
https://github.com/torvalds/linux/commit/e7a3d7e792a5ad50583a2e6c35e72bd2ca6096f4

commit 6e552494fb90acae005d74ce6a2ee102d965184b
Author: Brian Foster 
Date:   Tue May 4 08:54:29 2021 -0700
Subject: iomap: remove unused private field from ioend
Link: 
https://github.com/torvalds/linux/commit/6e552494fb90acae005d74ce6a2ee102d965184b

As you can see, the four latter commits are not necessary. They simply
remove dead code, which has no harm being left in place. They also do
not backport at all, not without the ALL of the significant refactor
commits.

Hence, we only take "xfs: drop submit side trans alloc for append
ioends" only, as it is the only needed commit to solve the problem.

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

** Affects: linux (Ubuntu Focal)
 Importance: High
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress


** Tags: focal sts

** Description changed:

- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs.launchpad.net/bugs/2007219
  
  [Impact]
  
  A deadlock exists in the XFS filesystem that occurs when the XFS log
  buffer becomes completely exhausted.
  
  XFS maintains a circular ring buffer for the log, and it is a fixed
  size. To be able to create a transaction, you need to be able to reserve
  space on the log buffer.
  
  Certain ioend transactions, such as file append, can be preallocated for
  a negligible performance gain. This takes up space in the log buffer,
  and these preallocated ioends are placed on a workqueue, behind other
  ioends that are not preallocated.
  
  The deadlock occurs when the XFS log buffer is running low on space, and
  an ioend append transaction comes in. It is preallocated, consuming
  nearly all of the remaining XFS log buffer space, and is placed at the
  very end of the ioend workqueue. The kernel then takes a ioend from the
  top of the ioend workqeueue, creates a transaction, xfs_trans_alloc(),
  attempts to allocate space  for it, xfs_trans_reserve(),
  xfs_log_reserve(), and then waits in a while loop

[Kernel-packages] [Bug 2004132] [NEW] btrfs/154: rename fails with EOVERFLOW when calculating item size during item key collision

2023-01-29 Thread Matthew Ruffell

stall the test kernel from the below ppa:

https://launchpad.net/~mruffell/+archive/ubuntu/sf349467-btrfs-154

The issue no longer occurs:

# ./check btrfs/154

Ran: btrfs/154
Passed all 1 tests

[Fix]

This was fixed in 5.11-rc3 by the below commit:

commit 9a664971569daf68254928149f580b4f5856d274
Author: ethanwu 
Date:   Tue Dec 1 17:25:12 2020 +0800
Subject: btrfs: correctly calculate item size used when item key collision 
happens
Link: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a664971569daf68254928149f580b4f5856d274

This cherry-picks to Focal, and required a small backport to Bionic,
removing the hunk that contained comments explaining the parameters to
btrfs_search_slot().

[Where problems could occur]

Problems could occur when calculating the size required for btrfs_item
and item data when hash collisions occur. Such collisions are rare in of
itself, but possible if you have a large amount files or craft filenames
to force collisions with the crc32 hash algorithm.

If a regression were to occur, it could cause more transactions to be
aborted, and would likely result in the users volume being forced read
only. They might not lose any existing data, but data being written
might be lost.

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

** Affects: linux (Ubuntu Bionic)
 Importance: Medium
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress

** Affects: linux (Ubuntu Focal)
 Importance: Medium
 Assignee: Matthew Ruffell (mruffell)
 Status: In Progress


** Tags: sts

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

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

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

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

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

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: linux (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Description changed:

- BugLink: https://bugs.launchpad.net/bugs/
+ BugLink: https://bugs.launchpad.net/bugs/2004132
  
  [Impact]
  
  xfstests btrfs/154 fails on both Bionic and Focal, leading to a kernel
  oops and the btrfs volume being forced readonly.
  
  In btrfs, item key collision is allowed for some item types, namely dir
  item and inode references. When inserting items into the btree, there
  are two objects, the btrfs_item and the item data. These objects must
  fit within the btree nodesize.
  
  When a hash collision occurs, and we call btrfs_search_slot() to place
  the objects in the tree, when btrfs_search_slot() reaches the leaf node,
  a check is performed to see if we need to split the leaf. The check is
  incorrect, returning that we need to split the leaf, since it thinks
  that both btrfs_item and the item data need to be inserted, when in
  reality, the item can be merged with the existing one and no new
  btrfs_item will be inserted.
  
  split_leaf() will return EOVERFLOW from following code:
- 
-   if (extend && data_size + btrfs_item_size_nr(l, slot) +
-   sizeof(struct btrfs_item) > BTRFS_LEAF_DATA_SIZE(fs_info))
-   return -EOVERFLOW;
+ 
+   if (extend && data_size + btrfs_item_size_nr(l, slot) +
+   sizeof(struct btrfs_item) > BTRFS_LEAF_DATA_SIZE(fs_info))
+   return -EOVERFLOW;
  
  In the rename case, btrfs_check_dir_item_collision() is called early
  stages of treewalking, and correctly calculates the needed size, taking
  into account that a hash collision has occurred.
  
-   data_size = sizeof(*di) + name_len;
-   if (data_size + btrfs_item_size_nr(leaf, slot) +
-   sizeof(struct btrfs_item) > BTRFS_LEAF_DATA_SIZE(root->fs_info))
+   data_size = sizeof(*di) + name_len;
+   if (data_size + btrfs_item_size_nr(leaf, slot) +
+   sizeof(struct btrfs_item) > BTRFS_LEAF_DATA_SIZE(root->fs_info))
  
  The two sizes reported from btrfs_check_dir_item_collision() and
  btrfs_search_slot() are different, and rename fails due to split_leaf()
  returning -EOVERFLOW, leading to transaction abort and forcing the
  volume readonly.
  
  Kernel oops:
  
  BTRFS: Transaction aborted (error -75)
  WARNING: CPU: 0 PID: 2921 at 
/build/linux-fTmV3T/linux-4.15.0/fs/btrfs/inode.c:10217 
btrfs_rename+0xcf1/0xdf0 [btrfs]
  CPU: 0 PID: 2921 Comm: python3 Not tainted 4.15.0-202-generic #213-Ubuntu
  RIP: 0010:btrfs_rename+0xcf1/0xdf0 [btrfs]
  RSP: 0018:9e6f4183fd20 EFLAGS: 00010282
  RAX:  RBX: 91a493f27b98 RCX: 0006
  RDX: 0007 RSI: 0096 RDI: 91a4b

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

2023-01-24 Thread Matthew Ruffell

read
+ or add any extra thread synchronisation primitives.
+ 
+ This has been tested with 13k VM deployments on Microsoft Azure, and has
+ found to work as expected with no failures, meaning risk of additional
+ race conditions we are not aware of is low.
+ 
+ The reason why this patch was not forwarded upstream, is that isc-dhcp
+ is now officially End Of Life, and has effectively been abandoned by
+ upstream. You can read about it in these notices:
+ 
+ https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
+ https://www.isc.org/blogs/isc-dhcp-eol/
+ 
+ Upstream won't fix any more bugs, make any new releases, or even accept
+ any new commits. They are putting their efforts into isc-kea now.

** No longer affects: bind9-libs (Ubuntu Focal)

** No longer affects: bind9-libs (Ubuntu Jammy)

** Changed in: bind9-libs (Ubuntu)
   Status: Fix Released => Won't Fix

** Also affects: isc-dhcp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** No longer affects: bind9-libs (Ubuntu Focal)

** No longer affects: bind9-libs (Ubuntu Jammy)

** Changed in: isc-dhcp (Ubuntu Focal)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: isc-dhcp (Ubuntu Jammy)
   Importance: Undecided => High

** Changed in: isc-dhcp (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: isc-dhcp (Ubuntu Jammy)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1926139

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump:
  Screenshot of Wireshark:

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix is to
  add a mutex that restricts access to the global linked list of open
  sockets, and ensures that a newly created socket is added to this
  list, before the socketmanager callback has an opportunity to walk
  this list when there is data immediately able to be read.

  Mauricio has provided such a patch, and includes options to disable
  this behaviour during runtime to minimise regression risk.

  [Testcase]

  Reproducer based on GDB and DHCP noise injection.

  It uses 3 veth pairs (DHCP server/cl

[Sts-sponsors] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

2023-01-24 Thread Matthew Ruffell

read
+ or add any extra thread synchronisation primitives.
+ 
+ This has been tested with 13k VM deployments on Microsoft Azure, and has
+ found to work as expected with no failures, meaning risk of additional
+ race conditions we are not aware of is low.
+ 
+ The reason why this patch was not forwarded upstream, is that isc-dhcp
+ is now officially End Of Life, and has effectively been abandoned by
+ upstream. You can read about it in these notices:
+ 
+ https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
+ https://www.isc.org/blogs/isc-dhcp-eol/
+ 
+ Upstream won't fix any more bugs, make any new releases, or even accept
+ any new commits. They are putting their efforts into isc-kea now.

** No longer affects: bind9-libs (Ubuntu Focal)

** No longer affects: bind9-libs (Ubuntu Jammy)

** Changed in: bind9-libs (Ubuntu)
   Status: Fix Released => Won't Fix

** Also affects: isc-dhcp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** No longer affects: bind9-libs (Ubuntu Focal)

** No longer affects: bind9-libs (Ubuntu Jammy)

** Changed in: isc-dhcp (Ubuntu Focal)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: isc-dhcp (Ubuntu Jammy)
   Importance: Undecided => High

** Changed in: isc-dhcp (Ubuntu Focal)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Changed in: isc-dhcp (Ubuntu Jammy)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of SE SRU
("STS") Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1926139

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Won't Fix
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in isc-dhcp source package in Focal:
  In Progress
Status in isc-dhcp source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump:
  Screenshot of Wireshark:

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix is to
  add a mutex that restricts access to the global linked list of open
  sockets, and ensures that a newly created socket is added to this
  list, before the socketmanager callback has an opportunity to walk
  this list when there is data immediately able to be read.

  Mauricio has provided such a patch, and includes options to disable
  this behaviour during runtime to minimise regression risk.

  [Testcase]

  Reproducer based on GDB and DHCP noise injection.

  It uses 3 veth pairs (DHCP server/c

[Sts-sponsors] Please review and sponsor bind9-libs for LP1926139

Hi everyone,

Can I get a courageous person to help sponsor bind9-libs for Focal and
Jammy in LP1926139:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139

Microsoft Azure have been putting a bit of pressure on me about this
case, in SF337873. Not in the case itself, but this went from not
important at all to this is very important and need daily updates mid
last week to getting pings every day from Kyler and Melissa about
status updates so they can keep them calm over email.

Its a little complicated, and the analysis is a bit long, but the LP
bug explains what is happening. You might go mad reading it. Turned
out to be a one line fix though, as all complicated fixes are.

Press the edit description button to see code indentation.

Thanks,
Matthew

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

** Tags added: sts-sponsor

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1926139

Title:
  dhclient: thread concurrency race leads to DHCPOFFER packets not being
  received

Status in bind9-libs package in Ubuntu:
  Fix Released
Status in isc-dhcp package in Ubuntu:
  Invalid
Status in bind9-libs source package in Focal:
  In Progress
Status in bind9-libs source package in Jammy:
  In Progress

Bug description:
  [Impact]

  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.

  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2%
  of deployments on Microsoft Azure. Azure uses dhclient called from
  cloud-init instead of systemd-networkd, and this is causing issues
  with larger deployments.

  The logs of an affected dhclient produce the following:

  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.

  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/

  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches
  25 DHCPDISCOVER packets sent, it gives up.

  tcpdump: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641810/+files/test.pcap
  Screenshot of Wireshark: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png

  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket
  is closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.

  The full explanation is in the "Other Info" section, but the fix for
  this is to change bind9-libs from being built multithreaded, back to
  single threaded as intended by dhclient maintainers.

  In Focal and Jammy, isc-dhcp links against bind9 libraries provided in
  bind9-libs, while in Kinetic onward isc-dhcp has an in-tree bind9
  library it uses, which is already configured properly to --disable-
  threads.

  Change the Focal and Jammy bind9-libs to --disable-threads and update
  symbol files to reflect the library is single threaded again.

  [Testcase]

  Start a fresh Focal or Jammy instance.

  Download and set executable test-parallel.sh, and edit some lines:

  1) wget 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5593045/+files/test-parallel.sh
  2) chmod +x test-parallel.sh
  3) vim test-parallel.sh

  Change iface="enp5s0" to your interface, likely iface="enp1s0".
  Comment out the line "#   cp bionic-dhclient $workdir/dhclient".

  4) sudo ./test-parallel.sh

  After five minutes, if you issue reproduces, you will see "TEST
  FAILED".

  You can watch the output with:

  5) cat /tmp/dhclient-* | less

  Next, for instrumented runs, you need to build dhclient from source.

  1) sudo apt install build-essential devscripts
  2) apt source isc-dhcp
  3) sudo apt build-dep isc-dhcp
  4) cd isc-dhcp

  Apply the below patch:

  https://paste.ubuntu.com/p/hGsssrVyG4/

  5) patch -p1 < ~/patch.patch
  6) debuild -b -uc -us
  7) cd ..
  8) sudo dpkg -i isc-dhcp-client-*
  9) sudo ./test-parallel.sh
  10) cat /tmp/dhclient-* | less

  Look for the race, as described in "Other Info", namely:

  mruffell: registering with socket manager
  mruffell: callback called
  mruffell: omapi object is NULL
  mruffell: omapi object is NULL
  mruffell: Adding obj to linked list
  mruffell: Obj added to list

  The issue has reproduced.

  If you install the test package from the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf337873-test

  Instructions to install (on a Focal or Jammy system):
  1) sudo add-apt-repository

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

Screenshot of wireshark.

** Attachment added: "Screenshot of wireshark"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png

** Description changed:

  [Impact]
  
  Occasionally, during instance boot or machine start-up, dhclient will
  attempt to acquire a dhcp lease and fail, leaving the instance with no
  IP address and making it unreachable.
  
  This happens about once every 100 reboots on bare metal, or Chris
  Patterson in comment #2 describes it as affecting between ~0.3% to 2% of
  deployments on Microsoft Azure. Azure uses dhclient called from cloud-
  init instead of systemd-networkd, and this is causing issues with larger
  deployments.
  
  The logs of an affected dhclient produce the following:
  
  Listening on LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   LPF/enp1s0/52:54:00:1c:d7:00
  Sending on   Socket/fallback
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f)
  ...
  (omitting 20 similar lines)
  ...
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f)
  DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f)
  No DHCPOFFERS received.
  No working leases in persistent database - sleeping.
  
  Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/
  Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/
  
  The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER
  packets being replied to with DHCPOFFER packets, but the got_one()
  callback is never called, dhclient does not read these DHCPOFFER
  packets, and continues sending DHCPDISCOVER packets. Once it reaches 25
  DHCPDISCOVER packets sent, it gives up.
  
- tcpdump:
- Screenshot of Wireshark:
+ tcpdump: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641810/+files/test.pcap
+ Screenshot of Wireshark: 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png
  
  This behaviour led several bug reporters to believe it was a kernel
  issue, with the kernel not pushing DHCPOFFER packets to dhclient. This
  is not the case, the actual problem is dhclient containing a thread
  concurrency race condition, and when the race occurs, the read socket is
  closed prematurely, and dhclient does not read any of the DHCPOFFER
  replies.
  
  The full explanation is in the "Other Info" section, but the fix for
  this is to change bind9-libs from being built multithreaded, back to
  single threaded as intended by dhclient maintainers.
  
  In Focal and Jammy, isc-dhcp links against bind9 libraries provided in
  bind9-libs, while in Kinetic onward isc-dhcp has an in-tree bind9
  library it uses, which is already configured properly to --disable-
  threads.
  
  Change the Focal and Jammy bind9-libs to --disable-threads and update
  symbol files to reflect the library is single threaded again.
  
  [Testcase]
  
  Start a fresh Focal or Jammy instance.
  
  Download and set executable test-parallel.sh, and edit some lines:
  
  1) wget 
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5593045/+files/test-parallel.sh
  2) chmod +x test-parallel.sh
  3) vim test-parallel.sh
  
  Change iface="enp5s0" to your interface, likely iface="enp1s0".
  Comment out the line "#   cp bionic-dhclient $workdir/dhclient".
  
  4) sudo ./test-parallel.sh
  
  After five minutes, if you issue reproduces, you will see "TEST FAILED".
  
  You can watch the output with:
  
  5) cat /tmp/dhclient-* | less
  
  Next, for instrumented runs, you need to build dhclient from source.
  
  1) sudo apt install build-essential devscripts
  2) apt source isc-dhcp
  3) sudo apt build-dep isc-dhcp
  4) cd isc-dhcp
  
  Apply the below patch:
  
  https://paste.ubuntu.com/p/hGsssrVyG4/
  
  5) patch -p1 < ~/patch.patch
  6) debuild -b -uc -us
  7) cd ..
  8) sudo dpkg -i isc-dhcp-client-*
  9) sudo ./test-parallel.sh
  10) cat /tmp/dhclient-* | less
  
  Look for the race, as described in "Other Info", namely:
  
  mruffell: registering with socket manager
  mruffell: callback called
  mruffell: omapi object is NULL
  mruffell: omapi object is NULL
  mruffell: Adding obj to linked list
  mruffell: Obj added to list
  
  The issue has reproduced.
  
  If you install the test package from the following ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf337873-test
  
  Instructions to install (on a Focal or Jammy system):
  1) sudo add-apt-repository ppa:mruffell/sf337873-test
  2) sudo apt update
  3) sudo apt install libdns-export1109 libisc-export1105
  4) sudo apt-cache policy libisc-export1105 | grep Installed
  Installed:

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received