from:"Matthew"

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

[Touch-packages] [Bug 1066529] Re: All jobs stopped, epson_inkjet_printer_filter failed

2023-07-19 Thread Matthew H McKenzie

sudo chmod -Rc 755 /opt/epson-inkjet-printer-escpr2 worked for me.
There is a temptation when writing under /opt to go 777 when untaring to make 
the drag and drop.

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

Title:
  All jobs stopped, epson_inkjet_printer_filter failed

Status in cups package in Ubuntu:
  Confirmed

Bug description:
  Kubuntu 12.04.1 64bit
  Cups 1.5.3-0ubuntu4
  EPSON WF-7520 - epson-inkjet-printer 1.0.0-1lsb3.2 - the last driver from 
Epson.
  Connected via USB.

  The printer just stopped to print - every job added in "stopped" state and 
this error:
  
"/opt/epson-inkjet-printer-201115w/cups/lib/filter/epson_inkjet_printer_filter 
failed"

  The printer screen says "Printing" endless.

  Will happy to provide additional info to resolve this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1066529/+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 2018171] [NEW] package nvidia-kernel-common-525 525.105.17-0ubuntu1 failed to install/upgrade: installed nvidia-kernel-common-525 package post-installation script subprocess retu

2023-04-29 Thread Matthew Mattox

Public bug reported:

Upgrading from 22.10 to 23.04

ProblemType: Package
DistroRelease: Ubuntu 23.04
Package: nvidia-kernel-common-525 525.105.17-0ubuntu1
ProcVersionSignature: Ubuntu 5.19.0-35.36-generic 5.19.17
Uname: Linux 5.19.0-35-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_uvm 
nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.26.1-0ubuntu2
Architecture: amd64
CasperMD5CheckResult: pass
CloudArchitecture: x86_64
CloudID: none
CloudName: none
CloudPlatform: none
CloudSubPlatform: config
Date: Sat Apr 29 19:33:35 2023
ErrorMessage: installed nvidia-kernel-common-525 package post-installation 
script subprocess returned error exit status 1
InstallationDate: Installed on 2022-11-22 (158 days ago)
InstallationMedia: Ubuntu-Server 20.04.5 LTS "Focal Fossa" - Release amd64 
(20220831)
Python3Details: /usr/bin/python3.11, Python 3.11.2, python3-minimal, 3.11.2-1
PythonDetails: N/A
RebootRequiredPkgs: Error: path contained symlinks.
RelatedPackageVersions:
 dpkg 1.21.21ubuntu1
 apt  2.6.0
SourcePackage: initramfs-tools
Title: package nvidia-kernel-common-525 525.105.17-0ubuntu1 failed to 
install/upgrade: installed nvidia-kernel-common-525 package post-installation 
script subprocess returned error exit status 1
UpgradeStatus: Upgraded to lunar on 2023-04-30 (0 days ago)

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-package lunar

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

Title:
  package nvidia-kernel-common-525 525.105.17-0ubuntu1 failed to
  install/upgrade: installed nvidia-kernel-common-525 package post-
  installation script subprocess returned error exit status 1

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  Upgrading from 22.10 to 23.04

  ProblemType: Package
  DistroRelease: Ubuntu 23.04
  Package: nvidia-kernel-common-525 525.105.17-0ubuntu1
  ProcVersionSignature: Ubuntu 5.19.0-35.36-generic 5.19.17
  Uname: Linux 5.19.0-35-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_uvm 
nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.26.1-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CloudArchitecture: x86_64
  CloudID: none
  CloudName: none
  CloudPlatform: none
  CloudSubPlatform: config
  Date: Sat Apr 29 19:33:35 2023
  ErrorMessage: installed nvidia-kernel-common-525 package post-installation 
script subprocess returned error exit status 1
  InstallationDate: Installed on 2022-11-22 (158 days ago)
  InstallationMedia: Ubuntu-Server 20.04.5 LTS "Focal Fossa" - Release amd64 
(20220831)
  Python3Details: /usr/bin/python3.11, Python 3.11.2, python3-minimal, 3.11.2-1
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   dpkg 1.21.21ubuntu1
   apt  2.6.0
  SourcePackage: initramfs-tools
  Title: package nvidia-kernel-common-525 525.105.17-0ubuntu1 failed to 
install/upgrade: installed nvidia-kernel-common-525 package post-installation 
script subprocess returned error exit status 1
  UpgradeStatus: Upgraded to lunar on 2023-04-30 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2018171/+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 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

[Touch-packages] [Bug 1930914] Re: ubuntu-minimal depends on ubuntu-advantage-tools

2023-02-25 Thread Matthew J. Hill

This is indeed a defect--marking it "wontfix" is not helpful.

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

Title:
  ubuntu-minimal depends on ubuntu-advantage-tools

Status in ubuntu-meta package in Ubuntu:
  Won't Fix

Bug description:
  This is counter to #1566183 There is no reason to enforce desktop
  users who manage machine on their own to install ubuntu-advantage-
  tools, especially when this is 'minimal' version.  This should include
  only essential packages to make the OS functional

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: ubuntu-minimal 1.450.2
  ProcVersionSignature: Ubuntu 5.4.0-73.82-lowlatency 5.4.106
  Uname: Linux 5.4.0-73-lowlatency x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.18
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Fri Jun  4 18:54:56 2021
  InstallationDate: Installed on 2020-01-29 (491 days ago)
  InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: ubuntu-meta
  UpgradeStatus: Upgraded to focal on 2020-06-27 (342 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1930914/+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 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 rec

[Touch-packages] [Bug 1987631] Re: Screencast only records one second

2023-01-26 Thread Matthew D. Mower

It seems like this has stalled again and I don't understand why. Patches
were posted about 1 month ago and they got some testing feedback within
2 days of availability.

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

Title:
  Screencast only records one second

Status in GNOME Shell:
  Fix Released
Status in OEM Priority Project:
  In Progress
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New
Status in pipewire package in Ubuntu:
  Fix Released
Status in gnome-shell source package in Jammy:
  Fix Released
Status in gst-plugins-base1.0 source package in Jammy:
  New
Status in gstreamer1.0 source package in Jammy:
  New
Status in pipewire source package in Jammy:
  Confirmed

Bug description:
  [Impact]
  When recording a screencast with gnome on kinetic the resulting video will 
play for one second and then freeze. It looks like the same bug was discussed 
upstream at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585

  This issue is caused by the new two patches in 0.3.48-1ubuntu2 which is fixed 
the Cheese preview stuck issue on jammy
* d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
  d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
  - Camera output freeze when using pipewiresrc (LP: #1985057)

  Here is a comment from 
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1985057/comments/51 .
  ===
  So that's a regression of one of the cherrypicked commits, details are in 
https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d32c03488

  the issue is fixed in Kinetic through a combination of the shell fix
  and a new pipewire.

  In 22.04 the shell issue is fixed in the recent 42.5 update but we will need 
to cherrypick 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525 in pipewire 
to be working.
  ===

  [Test Plan]
  1. Install Jammy on the hardware issue reported, and hardware didn't report 
the issue to avoid the regression
 hardware list:
 a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
 b. 0c45:6747 Microdia Integrated_Webcam_HD
 c. 0c45:6a14 Microdia Integrated_Webcam_HD
 d. 1bcf:28d0 Sunplus Innovation Technology Inc. Integrated_Webcam_5M
 e. 04f2:b76b Chicony Electronics Co., Ltd HP HD Camera
 f. 0408:545a Quanta Computer, Inc. HP 5MP Camera
 g. 0408:5483 Quanta Computer, Inc. HP HD Camera
 h. 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4)
 i. 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)
 j. 0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD
  2. try to install the updated pipewire packages (= 0.3.48-1ubuntu2)
  3. $ sudo reboot
  4. Check if gst-launch-1.0 work
 a. $ gst-device-monitor-1.0 Video/Source to get caps and suggest 
gst-launch-1.0 command
 b. $ gst-launch-1.0 pipewiresrc path= !  ! decodebin ! 
videoconvert ! glimagesink
 c. Check if the result ok
  5. Check the screencast function by pressing 'prt sc'
 a. the screenshot of all screen/selected region should work good
 b. the screenrecord of all screen/selected region should work good
  6. Check that video recording in gnome-shell works
 - use Ctrl+Shift+Alt+R to start a recording, stop it from the indicator, 
verify that there is a new entry in ~/Video
  7. Check that screen sharing is working
 - go to settings, screen sharing and enable the feature
 - try to connect using rdp/vnc from another client

  do those steps under wayland and unset X

  [Where problems could occur]
  The patches try to dequeue the shared buffer, instead of pool buffer to 
prevent the pool buffer being corrupted. it might cause some camera preview 
failed if shared buffer is corrupted.
  It is from upstream and there is no regression found, so the risk is low.

  [Other Info]
  Upstream commits for pipewire:
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/7cc509b117a6db66c395fb56ac4f17fb8cbd0c92
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a1f33a99df5756c3dedd68f5ba2690819098d14f
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525c1ac946a915599c6bee813e88e8cee12
  Upstream commits for gstreamer:
  
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/3b900e1fa4fd888012dc005fa26ae2532a89b7a7

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1987631/+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 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

2023-01-24 Thread Matthew Ruffell

taching after fork from child process 15283]
+  bound to 192.168.42.100 -- renewal in 252 seconds.
+  ^C
+  ...
+  (gdb) quit
+ 
+ The issue did not happen!
+ 
+ The DHCP client successfully acquired a DHCP address (above).
+ It can even be released later, outside of GDB (below).
+ 
+  # ip netns exec ns1 \
+dhclient -v veth1 -r
+  ...
+  DHCPRELEASE of 192.168.42.100 on veth1 to 192.168.42.1 port 67 
(xid=0x70f6c778)
  
  [Where problems could occur]
  
- We are changing the configuration of bind9-libs for Focal and Jammy from
- a net --enable-threads, to --disable-threads. This will remove
- multithreading for bind9-libs and all applications that link to it.
- 
- bind9-libs only services isc-dhcp, as per apt rdepends in the "Other
- Info" section, and the package was only introduced as a way to get isc-
- dhcp to build with older bind9 libs, and avoid having bind9 in-tree.
- 
- In Kinetic onward, the bind9 libs are shipped in-tree for isc-dhcp, and
- bind9-libs was removed from the archive.
- 
- Since we are only affecting isc-dhcp, we won't affect users of other
- packages, unless they for some reason decided to link against bind9-libs
- instead of the actual bind9 in the archive.
- 
- dhclient was never written for thread concurrency, shown by the lack of
- any synchronisation primitives whatsoever, and won't be negatively
- affected by going back to being single threaded, as it is in all other
- Ubuntu releases.
- 
- We are editing the symbol files to remove exported library calls. I have
- manually grep'd the isc-dhcp source, and those functions are not used,
- but for any users that got confused and link against bind9-libs, they
- might be affected by the change. For them, they need to link against the
- actual bind9 in the archive.
+ isc-dhcp is a core package, and any change comes with the risk that
+ users would not be able to receive dhcp leases with dhclient, leaving
+ their systems with no IP address and unreachable, and could potentially
+ cripple images that depend on it, e.g. Microsoft Azure uses dhclient
+ called from cloud-init, instead of systemd-networkd, so a regression
+ could potentially affect all Ubuntu users on Azure.
+ 
+ Additionally, the code is called whenever sockets are constructed, and
+ isc-dhcp-server could also be affected.
+ 
+ We have mitigated the risks of regression as best as possible by adding
+ as much detail as possible to this launchpad bug, so it is clear how the
+ race operates and how the patch fixes the issue.
+ 
+ Mauricio has additionally added a environment variable and a kernel
+ command line parameter, that when present, disables the mutex from
+ operating. If a regression were to occur, users can add these parameters
+ to their deployments to work around any issues.
+ 
+ Mauricio and Matthew have decided that the mutex route is best in terms
+ of lessening regression risk, as the alternate solution would be to
+ disable threading on bind9-libs.
+ 
+ Disabling threading on bind9-libs, while complete as a solution, and
+ removes the risk of a future regression caused by thread concurrency
+ issues that are currently undetected, comes with the fact that it
+ removes publicly exported symbols from bind9-libs, and adds others, and
+ changes the entire library from multithreaded to single threaded. If any
+ users happen to use bind9-libs outside of isc-dhcp, they would see their
+ applications either fail to work due to missing symbols, or performance
+ would change.
+ 
+ Disabling threading on bind9-libs is shelved, and can be looked at in
+ the future if necessary.
+ 
+ Back to the mutex solution, Chris Patterson, has been testing this
+ solution at scale on Azure, and in 13k instances, has not had a failure.
+ With the gdb reproducer, we are confident that adding the mutex will not
+ prevent other parts of the software from functioning correctly.
  
  [Other info]
  
  I was reading around the upstream issue trackers, and found the
  following two bug reports:
  
  https://gitlab.isc.org/isc-projects/dhcp/-/issues/264
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996356
  
  The ISC upstream report was actually quite detailed, and it has the same
  symptoms of what we are experiencing.
  
  Let's have a look at the root cause. The code I am using is isc-dhcp
  4.4.1-2.1ubuntu5.20.04.4 from Focal.
  
  common/discover.c
  
-  567 void
-  568 discover_interfaces(int state) {
+  567 void
+  568 discover_interfaces(int state) {
  ...
  1002 case AF_INET:
  1003 default:
  1004 status = omapi_register_io_object((omapi_object_t *)tmp,
  1005   if_readsocket,
  1006   0, got_one, 0, 0);
  1007 break;
  1008 }
  ...
  
  In discover.c, we call discover_interfaces() to iterate over the
  interfaces, and attempt to register a raw socket against it. We do this
  by calling omapi_register_io_object() which is used for reading data,
  and calls th

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

2023-01-16 Thread Matthew Ruffell

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

2023-01-16 Thread Matthew Ruffell

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

2023-01-16 Thread Matthew Ruffell

packet capture from a reproduction run

** Description changed:

- Platform: Qemu/libvirt on AMD64
- Ubuntu version: 20.04
- isc-dhcp-client version: 4.4.1-2.1ubuntu5
- Problem: When dhclient is used during boot every few reboots the DHCP OFFER 
packets aren't pushed from the kernel to dhclient. The DISCOVER packets can be 
seen in strace and tcpdump. The OFFER packets can be seen in tcpdump, but no 
read event is triggered.
- Ubuntu 18.04 doesn't have the problem, neither does Debian 10. Building these 
dhclient versions on Ubuntu 20.04 alleviates the problem a little, but it still 
occurs. So this issue might also be kernel related.
- 
- Attached diff shows a strace of all threads and a pcap showing the
- tcpdump output.
- 
- Edit:
- - Sometimes the dhclient command does receive the OFFER packet and connection 
is restored.
- - In my testing running dhclient manually from the terminal when the OFFERs 
aren't received will result in a new dhclient session which does receive the 
OFFER packet and connection is restored.
+ [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 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:

[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received

2023-01-15 Thread Matthew Ruffell

** Summary changed:

- dhclient doesn't receive dhcp offer from kernel
+ dhclient: thread concurrency race leads to DHCPOFFER packets not being 
received

-- 
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:
  Platform: Qemu/libvirt on AMD64
  Ubuntu version: 20.04
  isc-dhcp-client version: 4.4.1-2.1ubuntu5
  Problem: When dhclient is used during boot every few reboots the DHCP OFFER 
packets aren't pushed from the kernel to dhclient. The DISCOVER packets can be 
seen in strace and tcpdump. The OFFER packets can be seen in tcpdump, but no 
read event is triggered.
  Ubuntu 18.04 doesn't have the problem, neither does Debian 10. Building these 
dhclient versions on Ubuntu 20.04 alleviates the problem a little, but it still 
occurs. So this issue might also be kernel related.

  Attached diff shows a strace of all threads and a pcap showing the
  tcpdump output.

  Edit:
  - Sometimes the dhclient command does receive the OFFER packet and connection 
is restored.
  - In my testing running dhclient manually from the terminal when the OFFERs 
aren't received will result in a new dhclient session which does receive the 
OFFER packet and connection is restored.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9-libs/+bug/1926139/+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 1926139] Re: dhclient doesn't receive dhcp offer from kernel

2023-01-15 Thread Matthew Ruffell

Attached is a debdiff for Jammy which fixes this bug.

** Patch added: "Debdiff for bind9-libs for Jammy"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641516/+files/lp1926139_jammy.debdiff

** Tags added: focal jammy sts

** Also affects: bind9-libs (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: isc-dhcp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu Focal)
   Importance: Undecided
   Status: New

** No longer affects: isc-dhcp (Ubuntu Focal)

** No longer affects: isc-dhcp (Ubuntu Jammy)

** Changed in: isc-dhcp (Ubuntu)
   Status: New => Invalid

** Changed in: bind9-libs (Ubuntu Focal)
   Status: New => In Progress

** Changed in: bind9-libs (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: bind9-libs (Ubuntu)
   Status: New => Fix Released

** Changed in: bind9-libs (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: bind9-libs (Ubuntu Jammy)
   Importance: Undecided => High

** Changed in: bind9-libs (Ubuntu Focal)
     Assignee: (unassigned) => Matthew Ruffell (mruffell)

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

-- 
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 doesn't receive dhcp offer from kernel

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:
  Platform: Qemu/libvirt on AMD64
  Ubuntu version: 20.04
  isc-dhcp-client version: 4.4.1-2.1ubuntu5
  Problem: When dhclient is used during boot every few reboots the DHCP OFFER 
packets aren't pushed from the kernel to dhclient. The DISCOVER packets can be 
seen in strace and tcpdump. The OFFER packets can be seen in tcpdump, but no 
read event is triggered.
  Ubuntu 18.04 doesn't have the problem, neither does Debian 10. Building these 
dhclient versions on Ubuntu 20.04 alleviates the problem a little, but it still 
occurs. So this issue might also be kernel related.

  Attached diff shows a strace of all threads and a pcap showing the
  tcpdump output.

  Edit:
  - Sometimes the dhclient command does receive the OFFER packet and connection 
is restored.
  - In my testing running dhclient manually from the terminal when the OFFERs 
aren't received will result in a new dhclient session which does receive the 
OFFER packet and connection is restored.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9-libs/+bug/1926139/+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 1926139] Re: dhclient doesn't receive dhcp offer from kernel

2023-01-15 Thread Matthew Ruffell

Attached is a debdiff for Focal which fixes this bug.

** Patch added: "Debdiff for bind9-libs for Focal"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641515/+files/lp1926139_focal.debdiff

-- 
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 doesn't receive dhcp offer from kernel

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:
  Platform: Qemu/libvirt on AMD64
  Ubuntu version: 20.04
  isc-dhcp-client version: 4.4.1-2.1ubuntu5
  Problem: When dhclient is used during boot every few reboots the DHCP OFFER 
packets aren't pushed from the kernel to dhclient. The DISCOVER packets can be 
seen in strace and tcpdump. The OFFER packets can be seen in tcpdump, but no 
read event is triggered.
  Ubuntu 18.04 doesn't have the problem, neither does Debian 10. Building these 
dhclient versions on Ubuntu 20.04 alleviates the problem a little, but it still 
occurs. So this issue might also be kernel related.

  Attached diff shows a strace of all threads and a pcap showing the
  tcpdump output.

  Edit:
  - Sometimes the dhclient command does receive the OFFER packet and connection 
is restored.
  - In my testing running dhclient manually from the terminal when the OFFERs 
aren't received will result in a new dhclient session which does receive the 
OFFER packet and connection is restored.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bind9-libs/+bug/1926139/+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 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort

2023-01-04 Thread Matthew Ruffell

Performing verification for Bionic.

I started two instances on AWS, one c6g.medium (arm64) and a t2.micro
(amd64).

I went through the reproducer listed in the testcase with libunwind-dev
1.2.1-8 from -release.

$ 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
test/
test/lib.hpp
test/main.cpp
test/lib.cpp
test/Makefile
~/test$ make all
g++ -g -shared-libgcc -shared -fPIC -std=c++11 -o libtest.so lib.cpp
g++ -g -shared-libgcc -o main -L. -Wl,-rpath,. main.cpp -ltest
g++ -g -shared-libgcc -o main_unwind -L. -Wl,-rpath,.  main.cpp -ltest -lunwind

On arm64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
terminate called after throwing an instance of 'int'
terminate called recursively
Aborted (core dumped)

On amd64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
int throws lib
int caught main

As expected, we see arm64 abort the execution of the reproducer.

I then installed 1.2.1-8ubuntu0.1 from -proposed and rebuilt the
reproducers:

$ make clean
$ make all
g++ -g -shared-libgcc -shared -fPIC -std=c++11 -o libtest.so lib.cpp
g++ -g -shared-libgcc -o main -L. -Wl,-rpath,. main.cpp -ltest
g++ -g -shared-libgcc -o main_unwind -L. -Wl,-rpath,.  main.cpp -ltest -lunwind

On arm64:

$ ./main
int throws lib
int caught main
$ ./main_unwind
int throws lib
int caught main

On amd64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
int throws lib
int caught main

We see that 1.2.1-8ubuntu0.1 from -proposed does not abort, and instead
runs as expected. There is no change in behaviour on amd64. The package
in -proposed fixes the problem, happy to mark as verified for Bionic.

-- 
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 (core dumped)

  If you install the test package available in the following ppa:

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

  $ make clean
  $ sudo apt install -y

[Touch-packages] [Bug 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort

2023-01-04 Thread Matthew Ruffell

Performing verification for Focal.

I started two instances on AWS, one c6g.medium (arm64) and a t2.micro
(amd64).

I went through the reproducer listed in the testcase with libunwind-dev
1.2.1-9build1 from -release.

$ 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
test/
test/lib.hpp
test/main.cpp
test/lib.cpp
test/Makefile
~/test$ make all
g++ -g -shared-libgcc -shared -fPIC -std=c++11 -o libtest.so lib.cpp
g++ -g -shared-libgcc -o main -L. -Wl,-rpath,. main.cpp -ltest
g++ -g -shared-libgcc -o main_unwind -L. -Wl,-rpath,.  main.cpp -ltest -lunwind

On arm64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
terminate called after throwing an instance of 'int'
terminate called recursively
Aborted (core dumped)

On amd64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
int throws lib
int caught main

As expected, we see arm64 abort the execution of the reproducer.

I then installed 1.2.1-9ubuntu0.1 from -proposed and rebuilt the
reproducers:

$ make clean
$ make all
g++ -g -shared-libgcc -shared -fPIC -std=c++11 -o libtest.so lib.cpp
g++ -g -shared-libgcc -o main -L. -Wl,-rpath,. main.cpp -ltest
g++ -g -shared-libgcc -o main_unwind -L. -Wl,-rpath,.  main.cpp -ltest -lunwind

On arm64:

$ ./main
int throws lib
int caught main
$ ./main_unwind
int throws lib
int caught main

On amd64:

~/test$ ./main
int throws lib
int caught main
~/test$ ./main_unwind
int throws lib
int caught main

We see that 1.2.1-9ubuntu0.1 from -proposed does not abort, and instead
runs as expected. There is no change in behaviour on amd64. The package
in -proposed fixes the problem, happy to mark as verified for Focal.

-- 
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 (core dumped)

  If you install the test package available in the following ppa:

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

  $ make clean
  $ sudo apt

[Touch-packages] [Bug 1987631] Re: Screencast only records one second

2022-12-31 Thread Matthew D. Mower

@binli - here are my testing results with patches:
- gstreamer1.0_1.20.3-0ubuntu2.debdiff
- gst-plugins-base1.0_1.20.1-2.debdiff
- pipewire_0.3.48-1ubuntu4.debdiff

Gnome Shell screen recorder: pass
gst-launch-1.0 video preview: pass
Gnome Shell screen recorder while gst-launch-1.0 video preview is visible: pass
Cheese video preview: pass*

Cheese has an asterisk* because I ran into other problems: 1)
intermittently, selecting a filter can freeze the preview until a
different filter is selected. 2) lp:1994928

Camera hardware tested (two different computers):
13d3:5405 IMC Networks Integrated Camera (Lenovo T14s Gen2 AMD Laptop)
046d:082d Logitech, Inc. HD Pro Webcam C920

-

Details of how I built the packages and which ones I installed. Note
that I only installed packages that are part of a default Ubuntu jammy
installation: http://releases.ubuntu.com/jammy/ubuntu-22.04.1-desktop-
amd64.manifest .

$ wget 
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1987631/+attachment/5638524/+files/gstreamer1.0_1.20.3-0ubuntu2.debdiff
$ wget 
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1987631/+attachment/5638525/+files/gst-plugins-base1.0_1.20.1-2.debdiff
$ wget 
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1987631/+attachment/5638528/+files/pipewire_0.3.48-1ubuntu4.debdiff

$ pull-lp-source gstreamer1.0 1.20.3-0ubuntu1
$ pull-lp-source gst-plugins-base1.0 1.20.1-1
$ pull-lp-source pipewire 0.3.48-1ubuntu3

$ patch -p1 -d gstreamer1.0-1.20.3 < gstreamer1.0_1.20.3-0ubuntu2.debdiff
$ patch -p1 -d gst-plugins-base1.0-1.20.1 < gst-plugins-base1.0_1.20.1-2.debdiff
$ patch -p1 -d pipewire-0.3.48 < pipewire_0.3.48-1ubuntu4.debdiff

$ sudo apt-get build-dep gstreamer1.0 gst-plugins-base1.0 pipewire

$ cd gstreamer1.0
$ dpkg-buildpackage -rfakeroot -b
$ cdu ..
$ sudo dpkg -i gir1.2-gstreamer-1.0_1.20.3-0ubuntu2_amd64.deb 
gstreamer1.0-tools_1.20.3-0ubuntu2_amd64.deb 
libgstreamer1.0-0_1.20.3-0ubuntu2_amd64.deb 
libgstreamer1.0-dev_1.20.3-0ubuntu2_amd64.deb

$ cd gst-plugins-base1.0-1.20.1
$ dpkg-buildpackage -rfakeroot -b
$ cdu ..
$ sudo dpkg -i gir1.2-gst-plugins-base-1.0_1.20.1-2_amd64.deb 
gstreamer1.0-alsa_1.20.1-2_amd64.deb gstreamer1.0-gl_1.20.1-2_amd64.deb 
gstreamer1.0-plugins-base_1.20.1-2_amd64.deb 
gstreamer1.0-plugins-base-apps_1.20.1-2_amd64.deb 
gstreamer1.0-x_1.20.1-2_amd64.deb libgstreamer-gl1.0-0_1.20.1-2_amd64.deb 
libgstreamer-plugins-base1.0-0_1.20.1-2_amd64.deb

$ cd pipewire-0.3.48
$ dpkg-buildpackage -rfakeroot -b
$ cd ..
$ sudo dpkg -i gstreamer1.0-pipewire_0.3.48-1ubuntu4_amd64.deb 
libpipewire-0.3-0_0.3.48-1ubuntu4_amd64.deb 
libpipewire-0.3-common_0.3.48-1ubuntu4_all.deb 
libpipewire-0.3-modules_0.3.48-1ubuntu4_amd64.deb 
libspa-0.2-modules_0.3.48-1ubuntu4_amd64.deb pipewire_0.3.48-1ubuntu4_amd64.deb 
pipewire-bin_0.3.48-1ubuntu4_amd64.deb

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

Title:
  Screencast only records one second

Status in GNOME Shell:
  Fix Released
Status in OEM Priority Project:
  In Progress
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New
Status in pipewire package in Ubuntu:
  Fix Released
Status in gnome-shell source package in Jammy:
  Fix Released
Status in gst-plugins-base1.0 source package in Jammy:
  New
Status in gstreamer1.0 source package in Jammy:
  New
Status in pipewire source package in Jammy:
  Confirmed

Bug description:
  [Impact]
  When recording a screencast with gnome on kinetic the resulting video will 
play for one second and then freeze. It looks like the same bug was discussed 
upstream at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585

  This issue is caused by the new two patches in 0.3.48-1ubuntu2 which is fixed 
the Cheese preview stuck issue on jammy
* d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
  d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
  - Camera output freeze when using pipewiresrc (LP: #1985057)

  Here is a comment from 
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1985057/comments/51 .
  ===
  So that's a regression of one of the cherrypicked commits, details are in 
https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d32c03488

  the issue is fixed in Kinetic through a combination of the shell fix
  and a new pipewire.

  In 22.04 the shell issue is fixed in the recent 42.5 update but we will need 
to cherrypick 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525 in pipewire 
to be working.
  ===

  [Test Plan]
  1. Install Jammy on the hardware issue reported, and hardware didn't report 
the issue to avoid the regression
 hardware list:
 a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
 b. 0c45:6747 Microdia

[Touch-packages] [Bug 1987631] Re: Screencast only records one second

2022-12-29 Thread Matthew D. Mower

@binli - I'm still on pipewire from jammy-updates:

$ apt-cache policy pipewire
pipewire:
  Installed: 0.3.48-1ubuntu2
  Candidate: 0.3.48-1ubuntu2
  Version table:
 *** 0.3.48-1ubuntu2 500
500 http://us.archive.ubuntu.com/ubuntu jammy-updates/main amd64 
Packages
100 /var/lib/dpkg/status
 0.3.48-1ubuntu1 500
500 http://us.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

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

Title:
  Screencast only records one second

Status in GNOME Shell:
  Fix Released
Status in OEM Priority Project:
  In Progress
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New
Status in pipewire package in Ubuntu:
  Fix Released
Status in gnome-shell source package in Jammy:
  Fix Released
Status in gst-plugins-base1.0 source package in Jammy:
  New
Status in gstreamer1.0 source package in Jammy:
  New
Status in pipewire source package in Jammy:
  Confirmed

Bug description:
  [Impact]
  When recording a screencast with gnome on kinetic the resulting video will 
play for one second and then freeze. It looks like the same bug was discussed 
upstream at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5585

  This issue is caused by the new two patches in 0.3.48-1ubuntu2 which is fixed 
the Cheese preview stuck issue on jammy
* d/p/0001-buffers-ensure-buffer-size-does-not-exceed-maxsize.patch
  d/p/0002-gst-dequeue-a-shared-buffer-instead-of-original-pool.patch
  - Camera output freeze when using pipewiresrc (LP: #1985057)

  Here is a comment from 
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1985057/comments/51 .
  ===
  So that's a regression of one of the cherrypicked commits, details are in 
https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/d32c03488

  the issue is fixed in Kinetic through a combination of the shell fix
  and a new pipewire.

  In 22.04 the shell issue is fixed in the recent 42.5 update but we will need 
to cherrypick 
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525 in pipewire 
to be working.
  ===

  [Test Plan]
  1. Install Jammy on the hardware issue reported, and hardware didn't report 
the issue to avoid the regression
 hardware list:
 a. 0bda:58ff Realtek Semiconductor Corp. Integrated_Webcam_HD
 b. 0c45:6747 Microdia Integrated_Webcam_HD
 c. 0c45:6a14 Microdia Integrated_Webcam_HD
 d. 1bcf:28d0 Sunplus Innovation Technology Inc. Integrated_Webcam_5M
 e. 04f2:b76b Chicony Electronics Co., Ltd HP HD Camera
 f. 0408:545a Quanta Computer, Inc. HP 5MP Camera
 g. 0408:5483 Quanta Computer, Inc. HP HD Camera
 h. 174f:2459 Syntek Integrated Camera (ThinkBook 14 Gen 4)
 i. 5986:116d Acer, Inc Integrated Camera (ThinkCentre Neo 50a)
 j. 0bda:5556 Realtek Semiconductor Corp. Integrated_Webcam_FHD
  2. try to install the updated pipewire packages (= 0.3.48-1ubuntu2)
  3. $ sudo reboot
  4. Check if gst-launch-1.0 work
 a. $ gst-device-monitor-1.0 Video/Source to get caps and suggest 
gst-launch-1.0 command
 b. $ gst-launch-1.0 pipewiresrc path= !  ! decodebin ! 
videoconvert ! glimagesink
 c. Check if the result ok
  5. Check the screencast function by pressing 'prt sc'
 a. the screenshot of all screen/selected region should work good
 b. the screenrecord of all screen/selected region should work good
  6. Check that video recording in gnome-shell works
 - use Ctrl+Shift+Alt+R to start a recording, stop it from the indicator, 
verify that there is a new entry in ~/Video
  7. Check that screen sharing is working
 - go to settings, screen sharing and enable the feature
 - try to connect using rdp/vnc from another client

  do those steps under wayland and unset X

  [Where problems could occur]
  The patches try to dequeue the shared buffer, instead of pool buffer to 
prevent the pool buffer being corrupted. it might cause some camera preview 
failed if shared buffer is corrupted.
  It is from upstream and there is no regression found, so the risk is low.

  [Other Info]
  Upstream commits for pipewire:
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/7cc509b117a6db66c395fb56ac4f17fb8cbd0c92
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a1f33a99df5756c3dedd68f5ba2690819098d14f
  
https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1ea1d525c1ac946a915599c6bee813e88e8cee12
  Upstream commits for gstreamer:
  
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/3b900e1fa4fd888012dc005fa26ae2532a89b7a7

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1987631/+subscriptions


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

[Touch-packages] [Bug 1987631] Re: Screencast only records one second

2022-12-29 Thread Matthew D. Mower

@binli - I never found a need to update pipewire; the gstreamer patches
(for gstreamer and gst-plugins-base) seem to be sufficient in my
testing.

I tested your gstreamer & gst-plugins-base packages and they work the same as 
the ones I built. I think you could drop "-0ubuntu1binli1" from the symbols 
update though:
- _gst_meta_tag_memory_reference@Base 1.20.3-0ubuntu1binli1
+ _gst_meta_tag_memory_reference@Base 1.20.3

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

Title:
  Screencast only records one second

Status in GNOME Shell:
  Fix Released
Status in OEM Priority Project:
  In Progress
Status in gnome-shell package in Ubuntu:
  Fix Released
Status in gst-plugins-base1.0 package in Ubuntu:
  New
Status in gstreamer1.0 package in Ubuntu:
  New
Status in pipewire package in Ubuntu:
  Fix Released
Status in gnome-shell source package in Jammy:
  Fix Released
Status in gst-plugins-base1.0 source package in Jammy:
  New
Status in gstreamer1.0 source package in Jammy:
  New
Status in pipewire source package in Jammy:
  Confirmed

Bug description:
  When recording a screencast with gnome on kinetic the resulting video
  will play for one second and then freeze. It looks like the same bug
  was discussed upstream at https://gitlab.gnome.org/GNOME/gnome-
  shell/-/issues/5585

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1987631/+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 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort

2022-12-13 Thread Matthew Ruffell

** Tags added: sts-sponsor

-- 
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:
  In Progress
Status in libunwind source package in Focal:
  In Progress

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 (core dumped)

  If you install the test package available in the following ppa:

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

  $ make clean
  $ sudo apt install -y libunwind-dev
  $ make all
  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  int throws lib
  int caught main

  The exception is caught as expected the program does not abort.

  [Where problems could occur]

  For architectures other than i386 and amd64, we are changing from
  libunwind provided exception handlers for __cxa_throw(), and using
  those provided by libgcc_s instead.

  There are a few reverse dependencies for libunwind-dev and libunwind8,
  which need to be considered:

  $ apt rdepends libunwind-dev
  libunwind-dev
  Reverse Depends:
Depends: libunwind-setjmp0-dev (= 1.2.1-9build1)
Depends: libefl-all-dev

  t$ apt rdepends libunwind-dev8
  libunwind8
  Reverse Depends:
Depends: libunwind-dev (= 1.2.1-9build1)
Depends: xvfb
Depends: xnest
Depends: xdmx
Depends: xwayland
Depends: xserver-xorg-core
Depends: xserver-xephyr
Depends: linux-tools-5.4.0-*
Depends: linux-raspi-tools-*
Depends: linux-raspi2-tools-5.4.0-*
Depends: linux-raspi2-5.4-tools-5.4.0-*
Depends: linux-oracle-5.15-tools-5.15.0-*
Depends: linux-lowlatency-hwe-5.15-tools-5.15.0-*
Depends: linux-hwe-5.8-tools-5.8.0-*
Depends: linux-hwe-5.15-tools-5.15.0-*
Depends: linux-gke-tools-5.4.0-*
Depends: linux-gke-5.15-tools-5.15.0-*
Depends: linux-gcp-tools-5.4.0-*
Depends: linux-gcp-5.15-tools-5.15.0-*
Depends: linux-azure-tools-5.4.0-*
Depends: linux-azure-5.15-tools-5.15.0-*
Depends: linux-aws-tools-5.4.0-*
Depends: linux-aws-5.8-tools-5.8.0-*
Depends: linux-aws-5.15-tools-5.15.0-*
Depends: xvfb
Depends: xnest
Depends: xdmx
Depends: trafficserver
Depends: tilix
Depends: tigervnc-standalone-server
Depends: tarantool
Depends:

[Touch-packages] [Bug 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort

2022-12-12 Thread Matthew Ruffell

** Summary changed:

- libunwind causes crashes on arm64
+ arm64: broken c++ exception handler support leads to std::terminate() being 
called and program abort

** Description changed:

- There is a bug in libunwind in both 18.04 and 20.04 on arm64 where when
- linked with libunwind instead of catching an exception, the program
- crashes. This was first seen on mcrouter, but attached is a small
- reproducer where `main_unwind` will crash. The libunwind shipping with
- 22.04 doesn't appear to have this problem, nor do unmodified upstream
- versions (including the 1.2.1 which is the 18.04 and 20.04 version).
+ [Impact]
  
- Attached is a small reproducer that demonstrates the problem.
+ 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.
  
- Ubuntu 22.04:
- ```
- $ ./main
- int throws lib
- int caught main
- $ ./main_unwind
- int throws lib
- int caught main
- ```
+ (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
  
- Ubuntu 20.04:
- ```
+ 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 (core dumped)
- ```
+ 
+ If you install the test package available in the following ppa:
+ 
+ https://launchpad.net/~mruffell/+archive/ubuntu/sf350246-test
+ 
+ $ make clean
+ $ sudo apt install -y libunwind-dev
+ $ make all
+ $ ./main
+ int throws lib
+ int caught main
+ $ ./main_unwind
+ int throws lib
+ int caught main
+ 
+ The exception is caught as expected the program does not abort.
+ 
+ [Where problems could occur]
+ 
+ For architectures other than i386 and amd64, we are changing from
+ libunwind provided exception handlers for __cxa_throw(), and using those
+ provided by libgcc_s instead.
+ 
+ There are a few reverse dependencies for libunwind-dev and libunwind8,
+ which need to be considered:
+ 
+ $ apt rdepends libunwind-dev
+ libunwind-dev
+ Reverse Depends:
+   Depends: libunwind-setjmp0-dev (= 1.2.1-9build1)
+   Depends: libefl-all-dev
+ 
+ t$ apt rdepends libunwind-dev8
+ libunwind8
+ Reverse Depends:
+   Depends: libunwind-dev (= 1.2.1-9build1)
+   Depends: xvfb
+   Depends: xnest
+   Depends: xdmx
+   Depends: xwayland
+   Depends: xserver-xorg-core
+   Depends: xserver-xephyr
+   Depends: linux-tools-5.4.0-*
+   Depends: linux-raspi-tools-*
+   Depends: linux-raspi2-tools-5.4.0-*
+   Depends: linux-raspi2-5.4-tools-5.4.0-*
+   Depends: linux-oracle-5.15-tools-5.15.0-*
+   Depends: linux-lowlatency-hwe-5.15-tools-5.15.0-*
+   Depends: linux-hwe-5.8-tools-5.8.0-*
+   Depends: linux-hwe-5.15-tools-5.15.0-*
+   Depends: linux-gke-tools-5.4.0-*
+   Depends: linux-gke-5.15-tools-5.15.0-*
+   Depends: linux-gcp-tools-5.4.0-*
+   Depends: linux-gcp-5.15-tools-5.15.0-*
+   Depends:

[Touch-packages] [Bug 1999104] Re: libunwind causes crashes on arm64

2022-12-12 Thread Matthew Ruffell

Attached is a debdiff which fixes this problem on Bionic

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

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

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

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

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

** Changed in: libunwind (Ubuntu Bionic)
   Importance: Undecided => Medium

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

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

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

** Patch added: "Debdiff for libunwind on Bionic"
   
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635450/+files/lp1999104_bionic.debdiff

-- 
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:
  libunwind causes crashes on arm64

Status in libunwind package in Ubuntu:
  Fix Released
Status in libunwind source package in Bionic:
  In Progress
Status in libunwind source package in Focal:
  In Progress

Bug description:
  There is a bug in libunwind in both 18.04 and 20.04 on arm64 where
  when linked with libunwind instead of catching an exception, the
  program crashes. This was first seen on mcrouter, but attached is a
  small reproducer where `main_unwind` will crash. The libunwind
  shipping with 22.04 doesn't appear to have this problem, nor do
  unmodified upstream versions (including the 1.2.1 which is the 18.04
  and 20.04 version).

  Attached is a small reproducer that demonstrates the problem.

  Ubuntu 22.04:
  ```
  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  int throws lib
  int caught main
  ```

  Ubuntu 20.04:
  ```
  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  terminate called after throwing an instance of 'int'
  terminate called recursively
  Aborted (core dumped)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+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 1999104] Re: libunwind causes crashes on arm64

2022-12-12 Thread Matthew Ruffell

Attached is a debdiff which fixes this problem on Focal.

** Patch added: "Debdiff for libunwind on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635451/+files/lp1999104_focal.debdiff

-- 
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:
  libunwind causes crashes on arm64

Status in libunwind package in Ubuntu:
  Fix Released
Status in libunwind source package in Bionic:
  In Progress
Status in libunwind source package in Focal:
  In Progress

Bug description:
  There is a bug in libunwind in both 18.04 and 20.04 on arm64 where
  when linked with libunwind instead of catching an exception, the
  program crashes. This was first seen on mcrouter, but attached is a
  small reproducer where `main_unwind` will crash. The libunwind
  shipping with 22.04 doesn't appear to have this problem, nor do
  unmodified upstream versions (including the 1.2.1 which is the 18.04
  and 20.04 version).

  Attached is a small reproducer that demonstrates the problem.

  Ubuntu 22.04:
  ```
  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  int throws lib
  int caught main
  ```

  Ubuntu 20.04:
  ```
  $ ./main
  int throws lib
  int caught main
  $ ./main_unwind
  terminate called after throwing an instance of 'int'
  terminate called recursively
  Aborted (core dumped)
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure

2022-09-07 Thread Matthew Ruffell

Attached is an improvement on the previous patch revision. Output is now
forwarded to logger, we use shell expansion to enumerate network
devices, we omit loopback, and we added a udevadm settle to wait for any
thunderstorms to resolve before we continue installing the new udev
package.

** Patch added: "Debdiff for systemd on Bionic part two V2"

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+attachment/5614287/+files/lp1988119_bionic_part_two_V2.debdiff

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

Title:
systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS
outages on Azure

Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed

Bug description:
[Impact]

A widespread outage was caused on Azure instances earlier today, when
systemd 237-3ubuntu10.54 was published to the bionic-security pocket.
Instances could no longer resolve DNS queries, breaking networking.

For affected users, the following workarounds are available. Use whatever is
most convenient.
- Reboot your instances
- or -
- Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd"
as root

The trigger was found to be open-vm-tools issuing "udevadm trigger".
Azure has a specific netplan setup that uses the `driver` match to set
up networking. If a udevadm trigger is executed, the KV pair that
contains this info is lost. Next time netplan is executed, the server
loses it's DNS information.

This is the same as bug 1902960 experienced on Focal two years ago.

The root cause was found to be a bug in systemd, where if we receive a
"Remove" action from a change uevent, we need to run net_setup_link(),
we need to skip device rename and keep the old name.

[Testcase]

Start an instance up on Azure, any type. Simply issue udevadm trigger
and reload systemd-networkd:

$ ping google.com
PING google.com (172.253.62.102) 56(84) bytes of data.
64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56
time=1.85 ms
$ sudo udevadm trigger && sudo systemctl restart systemd-networkd
$ ping google.com
ping: google.com: Temporary failure in name resolution

To fix a broken instance, you can run:

$ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd-
networkd

and then install the test packages below:

Test packages are available in the following ppa:

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

If you install them, the issue should no longer occur.

[Where problems could occur]

If a regression were to occur, it would affect systemd-udevd
processing 'change' events from network devices, which could lead to
network outages. Since this would happen when systemd-networkd is
restarted on postinstall, a regression would cause widespread outages
due to this SRU being targeted to the security pocket, where
unattended-upgrades will automatically install from.

Side effects could include incorrect udevd device properties.

It is very important that this SRU is well tested before release.

[Other info]

This was fixed in Systemd 247 with the following commit:

commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151
Author: Yu Watanabe
Date: Mon, 14 Sep 2020 15:21:04 +0900
Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME=
properties on non-'add' uevent
Link:
https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151

This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960
two years ago. Focal required a heavy backport, which was performed by
Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re-
assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below
pastebin:

https://paste.ubuntu.com/p/K5k7bGt3Wx/

The changes between the Focal backport and the Bionic backport are:

- We use udev_device_get_action() instead of device_get_action()
- device_action_from_string() is used to get to enum DeviceAction
- We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto
no_rename"
- log_device_* has been changed to log_*.

See attached debdiff for Bionic backport.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure

2022-09-05 Thread Matthew Ruffell

Attached is the second patch required to fully fix this bug. It adds a
check on preinstall to see if ID_NET_DRIVER is present on the network
interface, and if it is missing, call udevadm trigger -c add on the
interface to add it.

** Patch added: "Debdiff for systemd on Bionic part two"

https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+attachment/5613890/+files/lp1988119_bionic_part_two.debdiff

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

Title:
systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS
outages on Azure

Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Committed

Bug description:
[Impact]

This is the same as bug 1902960 experienced on Focal two years ago.

The root cause was found to be a bug in systemd, where if we receive a
"Remove" action from a change uevent, we need to run net_setup_link(),
we need to skip device rename and keep the old name.

[Testcase]

Start an instance up on Azure, any type. Simply issue udevadm trigger
and reload systemd-networkd:

To fix a broken instance, you can run:

$ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd-
networkd

and then install the test packages below:

Test packages are available in the following ppa:

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

If you install them, the issue should no longer occur.

[Where problems could occur]

Side effects could include incorrect udevd device properties.

It is very important that this SRU is well tested before release.

[Other info]

This was fixed in Systemd 247 with the following commit:

https://paste.ubuntu.com/p/K5k7bGt3Wx/

The changes between the Focal backport and the Bionic backport are:

See attached debdiff for Bionic backport.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure

The failure mode still exists if "udevadm trigger" has been issued
before the package upgrade to systemd 237-3ubuntu10.55.

That is, if unattended-upgrades or the user had installed open-vm-tools,
and has not rebooted yet, they will lose network connection on upgrade
to 237-3ubuntu10.55.

We need to implement a way to add ID_NET_DRIVER back to the device
before the systemd upgrade takes place, otherwise an outage will occur.

Release admins - DO NOT RELEASE systemd 237-3ubuntu10.55 yet.

Tagging block-proposed.

$ ping google.com
PING google.com (142.251.45.110) 56(84) bytes of data.
64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=1 ttl=56 
time=1.51 ms
64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=2 ttl=56 
time=1.35 ms
64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=3 ttl=56 
time=1.17 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.172/1.349/1.516/0.140 ms
azureuser@mruffell-test:~$ sudo apt-cache policy systemd | grep Installed
  Installed: 237-3ubuntu10.53
azureuser@mruffell-test:~$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
E: ID_NET_DRIVER=hv_netvsc
azureuser@mruffell-test:~$ sudo udevadm trigger
azureuser@mruffell-test:~$ ping google.com
PING google.com (142.251.45.110) 56(84) bytes of data.
64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=1 ttl=56 
time=2.15 ms
64 bytes from iad23s04-in-f14.1e100.net (142.251.45.110): icmp_seq=2 ttl=56 
time=1.21 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.212/1.682/2.152/0.470 ms
azureuser@mruffell-test:~$ udevadm info /sys/class/net/eth0 | grep ID_NET_DRIVER
azureuser@mruffell-test:~$ sudo apt install libnss-systemd libpam-systemd 
libsystemd0 libudev1 systemd systemd-sysv udev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following package was automatically installed and is no longer required:
  linux-headers-4.15.0-191
Use 'sudo apt autoremove' to remove it.
Suggested packages:
  systemd-container
The following packages will be upgraded:
  libnss-systemd libpam-systemd libsystemd0 libudev1 systemd systemd-sysv udev
7 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
Need to get 4497 kB of archives.
After this operation, 8192 B of additional disk space will be used.
Get:1 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 libsystemd0 amd64 237-3ubuntu10.55 [205 kB]
Get:2 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 libnss-systemd amd64 237-3ubuntu10.55 [105 kB]
Get:3 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 libpam-systemd amd64 237-3ubuntu10.55 [107 kB]
Get:4 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 systemd amd64 237-3ubuntu10.55 [2915 kB]
Get:5 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 udev amd64 237-3ubuntu10.55 [1099 kB]
Get:6 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 libudev1 amd64 237-3ubuntu10.55 [54.2 kB]
Get:7 http://ppa.launchpad.net/ubuntu-security-proposed/ppa/ubuntu bionic/main 
amd64 systemd-sysv amd64 237-3ubuntu10.55 [12.0 kB]
Fetched 4497 kB in 3s (1461 kB/s)
(Reading database ... 77176 files and directories currently installed.)
Preparing to unpack .../libsystemd0_237-3ubuntu10.55_amd64.deb ...
Unpacking libsystemd0:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Setting up libsystemd0:amd64 (237-3ubuntu10.55) ...
(Reading database ... 77176 files and directories currently installed.)
Preparing to unpack .../libnss-systemd_237-3ubuntu10.55_amd64.deb ...
Unpacking libnss-systemd:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Preparing to unpack .../libpam-systemd_237-3ubuntu10.55_amd64.deb ...
Unpacking libpam-systemd:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Preparing to unpack .../systemd_237-3ubuntu10.55_amd64.deb ...
Unpacking systemd (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Preparing to unpack .../udev_237-3ubuntu10.55_amd64.deb ...
Unpacking udev (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Preparing to unpack .../libudev1_237-3ubuntu10.55_amd64.deb ...
Unpacking libudev1:amd64 (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Setting up libudev1:amd64 (237-3ubuntu10.55) ...
Setting up systemd (237-3ubuntu10.55) ...
(Reading database ... 77176 files and directories currently installed.)
Preparing to unpack .../systemd-sysv_237-3ubuntu10.55_amd64.deb ...
Unpacking systemd-sysv (237-3ubuntu10.55) over (237-3ubuntu10.53) ...
Setting up libnss-systemd:amd64 (237-3ubuntu10.55) ...
Setting up systemd-sysv (237-3ubuntu10.55) ...
Setting up udev (237-3ubuntu10.55) ...
update-initramfs: deferring update (trigger activated)
Setting up libpam-systemd:amd64 (237-3ubuntu10.55) ...

[Touch-packages] [Bug 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure

** Changed in: systemd (Ubuntu Bionic)
   Status: Fix Released => Fix Committed

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

Title:
  systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS
  outages on Azure

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

  A widespread outage was caused on Azure instances earlier today, when
  systemd 237-3ubuntu10.54 was published to the bionic-security pocket.
  Instances could no longer resolve DNS queries, breaking networking.

  For affected users, the following workarounds are available. Use whatever is 
most convenient.
  - Reboot your instances
  - or -
  - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" 
as root

  The trigger was found to be open-vm-tools issuing "udevadm trigger".
  Azure has a specific netplan setup that uses the `driver` match to set
  up networking. If a udevadm trigger is executed, the KV pair that
  contains this info is lost. Next time netplan is executed, the server
  loses it's DNS information.

  This is the same as bug 1902960 experienced on Focal two years ago.

  The root cause was found to be a bug in systemd, where if we receive a
  "Remove" action from a change uevent, we need to run net_setup_link(),
  we need to skip device rename and keep the old name.

  [Testcase]

  Start an instance up on Azure, any type. Simply issue udevadm trigger
  and reload systemd-networkd:

  $ ping google.com
  PING google.com (172.253.62.102) 56(84) bytes of data.
  64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 
time=1.85 ms
  $ sudo udevadm trigger && sudo systemctl restart systemd-networkd
  $ ping google.com
  ping: google.com: Temporary failure in name resolution

  To fix a broken instance, you can run:

  $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd-
  networkd

  and then install the test packages below:

  Test packages are available in the following ppa:

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

  If you install them, the issue should no longer occur.

  [Where problems could occur]

  If a regression were to occur, it would affect systemd-udevd
  processing 'change' events from network devices, which could lead to
  network outages. Since this would happen when systemd-networkd is
  restarted on postinstall, a regression would cause widespread outages
  due to this SRU being targeted to the security pocket, where
  unattended-upgrades will automatically install from.

  Side effects could include incorrect udevd device properties.

  It is very important that this SRU is well tested before release.

  [Other info]

  This was fixed in Systemd 247 with the following commit:

  commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151
  Author: Yu Watanabe 
  Date: Mon, 14 Sep 2020 15:21:04 +0900
  Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= 
properties on non-'add' uevent
  Link: 
https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151

  This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960
  two years ago. Focal required a heavy backport, which was performed by
  Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re-
  assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below
  pastebin:

  https://paste.ubuntu.com/p/K5k7bGt3Wx/

  The changes between the Focal backport and the Bionic backport are:

  - We use udev_device_get_action() instead of device_get_action()
  - device_action_from_string() is used to get to enum DeviceAction
  - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto 
no_rename"
  - log_device_* has been changed to log_*.

  See attached debdiff for Bionic backport.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure

Hello everyone,

I know there are quite a few people watching this bug, so I will provide
a status update.

The test package has been looking good throughout our internal testing,
and we have proceeded to build the next systemd update, version
237-3ubuntu10.55, and it is currently in the bionic-security -proposed
ppa.

If you would like to help test, that would be greatly appreciated.
Please use a fresh VM on Azure, and please don't put the package into
production just yet.

Instructions to install (On a Bionic system):
1) sudo add-apt-repository ppa:ubuntu-security-proposed/ppa
2) sudo apt update
3) sudo apt install libnss-systemd libpam-systemd libsystemd0 libudev1 systemd 
systemd-sysv udev
4) sudo apt-cache policy systemd | grep Installed
Installed: 237-3ubuntu10.55
5) sudo rm 
/etc/apt/sources.list.d/ubuntu-security-proposed-ubuntu-ppa-bionic.list
6) sudo apt update

>From there you can run the reproducer:

$ sudo udevadm trigger && sudo systemctl restart systemd-networkd
$ ping google.com
PING google.com (172.253.122.138) 56(84) bytes of data.
64 bytes from bh-in-f138.1e100.net (172.253.122.138): icmp_seq=1 ttl=103 
time=1.67 ms

if you do test, comment here on how it went. Again, please don't put the
package into production until it has had a little more testing, and we
will get this released to the world as quickly and safely as we can.

Thanks,
Matthew

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

Title:
  systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS
  outages on Azure

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]

  A widespread outage was caused on Azure instances earlier today, when
  systemd 237-3ubuntu10.54 was published to the bionic-security pocket.
  Instances could no longer resolve DNS queries, breaking networking.

  For affected users, the following workarounds are available. Use whatever is 
most convenient.
  - Reboot your instances
  - or -
  - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" 
as root

  The trigger was found to be open-vm-tools issuing "udevadm trigger".
  Azure has a specific netplan setup that uses the `driver` match to set
  up networking. If a udevadm trigger is executed, the KV pair that
  contains this info is lost. Next time netplan is executed, the server
  loses it's DNS information.

  This is the same as bug 1902960 experienced on Focal two years ago.

  The root cause was found to be a bug in systemd, where if we receive a
  "Remove" action from a change uevent, we need to run net_setup_link(),
  we need to skip device rename and keep the old name.

  [Testcase]

  Start an instance up on Azure, any type. Simply issue udevadm trigger
  and reload systemd-networkd:

  $ ping google.com
  PING google.com (172.253.62.102) 56(84) bytes of data.
  64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 
time=1.85 ms
  $ sudo udevadm trigger && sudo systemctl restart systemd-networkd
  $ ping google.com
  ping: google.com: Temporary failure in name resolution

  To fix a broken instance, you can run:

  $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd-
  networkd

  and then install the test packages below:

  Test packages are available in the following ppa:

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

  If you install them, the issue should no longer occur.

  [Where problems could occur]

  If a regression were to occur, it would affect systemd-udevd
  processing 'change' events from network devices, which could lead to
  network outages. Since this would happen when systemd-networkd is
  restarted on postinstall, a regression would cause widespread outages
  due to this SRU being targeted to the security pocket, where
  unattended-upgrades will automatically install from.

  Side effects could include incorrect udevd device properties.

  It is very important that this SRU is well tested before release.

  [Other info]

  This was fixed in Systemd 247 with the following commit:

  commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151
  Author: Yu Watanabe 
  Date: Mon, 14 Sep 2020 15:21:04 +0900
  Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= 
properties on non-'add' uevent
  Link: 
https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151

  This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960
  two years ago. Focal required a heavy backport, which was performed by
  Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re-
  assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below
  pastebin:

  https://paste.ubuntu.com/p/K5k7bGt3Wx/

  The changes between the Focal backpor

[Touch-packages] [Bug 1988119] Re: Update to systemd 237-3ubuntu10.54 broke dns

Attached is a debdiff for systemd on Bionic which fixes this bug.

** Description changed:

- Two servers today that updated systemd to "systemd 237-3ubuntu10.54" 
- https://ubuntu.com/security/notices/USN-5583-1
+ [Impact]
  
- could not resolve dns anymore.
- no dns servers, normally set through dhcp.
+ A widespread outage was caused on Azure instances earlier today, when
+ systemd 237-3ubuntu10.54 was published to the bionic-security pocket.
+ Instances could no longer resolve DNS queries, breaking networking.
  
- Ubuntu 18.04
+ For affected users, the following workarounds are available. Use whatever is 
most convenient.
+ - Reboot your instances
+ - or -
+ - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" 
as root
  
- Temp fix.
-  1. Edit /etc/systemd/resolved.conf
-  1. Add/Uncomment # FallbackDNS=168.63.129.16
-  1. Restart systemd-resolved sudo systemctl restart systemd-resolved.service
-  1. Confirm dns working with systemd-resolve google.com
+ The trigger was found to be open-vm-tools issuing "udevadm trigger".
+ Azure has a specific netplan setup that uses the `driver` match to set
+ up networking. If a udevadm trigger is executed, the KV pair that
+ contains this info is lost. Next time netplan is executed, the server
+ loses it's DNS information.
+ 
+ This is the same as bug 1902960 experienced on Focal two years ago.
+ 
+ The root cause was found to be a bug in systemd, where if we receive a
+ "Remove" action from a change uevent, we need to run net_setup_link(),
+ we need to skip device rename and keep the old name.
+ 
+ [Testcase]
+ 
+ Start an instance up on Azure, any type. Simply issue udevadm trigger
+ and reload systemd-networkd:
+ 
+ $ ping google.com
+ PING google.com (172.253.62.102) 56(84) bytes of data.
+ 64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 
time=1.85 ms
+ $ sudo udevadm trigger && sudo systemctl restart systemd-networkd
+ $ ping google.com
+ ping: google.com: Temporary failure in name resolution
+ 
+ To fix a broken instance, you can run:
+ 
+ $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd-
+ networkd
+ 
+ and then install the test packages below:
+ 
+ Test packages are available in the following ppa:
+ 
+ https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test
+ 
+ If you install them, the issue should no longer occur.
+ 
+ [Where problems could occur]
+ 
+ If a regression were to occur, it would affect systemd-udevd processing
+ 'change' events from network devices, which could lead to network
+ outages. Since this would happen when systemd-networkd is restarted on
+ postinstall, a regression would cause widespread outages due to this SRU
+ being targeted to the security pocket, where unattended-upgrades will
+ automatically install from.
+ 
+ Side effects could include incorrect udevd device properties.
+ 
+ It is very important that this SRU is well tested before release.
+ 
+ [Other info]
+ 
+ This was fixed in Systemd 247 with the following commit:
+ 
+ commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151
+ Author: Yu Watanabe 
+ Date: Mon, 14 Sep 2020 15:21:04 +0900
+ Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= 
properties on non-'add' uevent
+ Link: 
https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151
+ 
+ This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960
+ two years ago. Focal required a heavy backport, which was performed by
+ Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re-
+ assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below
+ pastebin:
+ 
+ https://paste.ubuntu.com/p/K5k7bGt3Wx/
+ 
+ The changes between the Focal backport and the Bionic backport are:
+ 
+ - We use udev_device_get_action() instead of device_get_action()
+ - device_action_from_string() is used to get to enum DeviceAction
+ - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto 
no_rename"
+ - log_device_* has been changed to log_*.
+ 
+ See attached debdiff for Bionic backport.

** Summary changed:

- Update to systemd 237-3ubuntu10.54 broke dns
+ systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages 
on Azure

** Patch added: "Debdiff for systemd on Bionic"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+attachment/5612617/+files/lp1988119_bionic.debdiff

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

Title:
  systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS
  outages on Azure

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]

  A widespread outage was caused on Azure instances earlier today, when
  systemd 237-3ubuntu10.54 was published to the bionic-security pocket.
  Instances could no longer

[Touch-packages] [Bug 1988119] Re: Update to systemd 237-3ubuntu10.54 broke dns

2022-08-30 Thread Matthew Ruffell

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

** Tags added: bionic sts

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

Title:
  Update to systemd 237-3ubuntu10.54 broke dns

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  Two servers today that updated systemd to "systemd 237-3ubuntu10.54" 
  https://ubuntu.com/security/notices/USN-5583-1

  could not resolve dns anymore.
  no dns servers, normally set through dhcp.

  Ubuntu 18.04

  Temp fix.
   1. Edit /etc/systemd/resolved.conf
   1. Add/Uncomment # FallbackDNS=168.63.129.16
   1. Restart systemd-resolved sudo systemctl restart systemd-resolved.service
   1. Confirm dns working with systemd-resolve google.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1988119] Re: Update to systemd 237-3ubuntu10.54 broke dns

2022-08-30 Thread Matthew Ruffell

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

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

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

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

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

Title:
  Update to systemd 237-3ubuntu10.54 broke dns

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress

Bug description:
  Two servers today that updated systemd to "systemd 237-3ubuntu10.54" 
  https://ubuntu.com/security/notices/USN-5583-1

  could not resolve dns anymore.
  no dns servers, normally set through dhcp.

  Ubuntu 18.04

  Temp fix.
   1. Edit /etc/systemd/resolved.conf
   1. Add/Uncomment # FallbackDNS=168.63.129.16
   1. Restart systemd-resolved sudo systemctl restart systemd-resolved.service
   1. Confirm dns working with systemd-resolve google.com

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+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 1913979] Re: misleading error messages when /etc/NetworkManager/system-connections is a cross-filesystem symlink

2022-08-18 Thread Matthew Culler

I think there are multiple bugs in play here.  My system-connections dir
is a symlink within the same filesystem, and whenever I try to save a
new connection I get the "settings plugin does not support adding
connections" message.

Aug 18 17:11:08 workhorse4 NetworkManager[4092654]: 
[1660857068.1365] audit: op="connection-add" pid=4124192 uid=1000
result="fail" reason="failure adding connection: settings plugin does
not support adding connections"

The symlink target dir has the same ownership/permissions as the
original system-connections dir - 0755, root:root.

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

Title:
  misleading error messages when /etc/NetworkManager/system-connections
  is a cross-filesystem symlink

Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  If the /etc/NetworkManager/system-connections directory is a cross-
  filesystem symlink, activating connections will fail with the
  unrelated messages:

  * "failed to create file ...: Read-only file system" (TRACE level)

  * "failure adding connection: settings plugin does not support adding
  connections" (DEBUG level and above)

  * no error message (Gnome UI)

  I suspect moving the systems-connections directory onto a separate
  filesystem is not supported because network manager tries to
  atomically move a connection temp file into place and fails, but this
  is really hard to figure out since the error messages are completely
  unrelated.

  
  Versions:

  Ubuntu 20.10
  network-manager 1.26.2-1ubuntu1
  network-manager-gnome 1.18.0-1ubuntu2

  
  How to reproduce:

  sudo mv /etc/NetworkManager/system-connections 
/some/other/mountpoint/system-connections
  sudo ln -s /some/other/mountpoint/system-connections 
/etc/NetworkManager/system-connections

  Then:
  * select any wifi network via the Gnome UI, or
  * connect to a wifi network via nmcli, or
  * connect to a wifi network via nmtui

  
  Symptoms:

  * "failed to create file ...: Read-only file system" (TRACE level,
  journalctl)

  * "failure adding connection: settings plugin does not support adding
  connections" (DEBUG level and above, journalctl and nmtui/nmcli
  output)

  * no error message (Gnome UI)

  
  Relevant sample logs:

  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4038] 
active-connection[0x56274f6f0a60]: creating
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4039] 
active-connection[0x56274f6f0a60]: set device "wlp61s0" [0x56274f883f00]
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4039] 
device[d62304f9da70d783] (wlp61s0): add_pending_action (1): 'activation-5'
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4040] 
active-connection[0x56274f6f0a60]: constructed (NMActRequest, version-id 5, 
type managed)
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4040] 
auth: call[37]: 
CheckAuthorization(org.freedesktop.NetworkManager.network-control), 
subject=unix-process[pid=1369566, uid=0, start=18908113] (succeeding for root)
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4041] 
auth: call[37]: completed: authorized=1, challenge=0 (simulated)
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4041] 
auth: call[38]: 
CheckAuthorization(org.freedesktop.NetworkManager.settings.modify.system), 
subject=unix-process[pid=1369566, uid=0, start=18908113] (succeeding for root)
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4042] 
auth: call[38]: completed: authorized=1, challenge=0 (simulated)
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4042] 
settings: add-connection: failed to add 
a4e6f563-eb2a-41ff-bc23-986ee3438ed9/'mywifi_2G': settings plugin does not 
support adding connections
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4061] 
keyfile: commit: a4e6f563-eb2a-41ff-bc23-986ee3438ed9 (mywifi_2G) failed to 
add: error writing to file 
'/etc/NetworkManager/system-connections/mywifi_2G.nmconnection': failed to 
create file 
/etc/NetworkManager/system-connections/mywifi_2G.nmconnection.ZE5DY0: Read-only 
file system
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4062] 
settings: add-connection: failed to add 
a4e6f563-eb2a-41ff-bc23-986ee3438ed9/'mywifi_2G': error writing to file 
'/etc/NetworkManager/system-connections/mywifi_2G.nmconnection': failed to 
create file 
/etc/NetworkManager/system-connections/mywifi_2G.nmconnection.ZE5DY0: Read-only 
file system
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4062] 
active-connection[0x56274f6f0a60]: Failed to activate '(null)': failure adding 
connection: settings plugin does not support adding connections
  Feb 01 20:56:04 laptop NetworkManager[1368510]:  [1612230964.4062] 
active-connection[0x56274f6f0a60]: set state deactivated (was unknown)
  Feb 01 20:56:04

[Touch-packages] [Bug 1982885] [NEW] Firefox does not scroll with touch input

2022-07-26 Thread Matthew Lovibond

Public bug reported:

Firefox does not scroll with the usual touch gesture of swiping up or
down on the screen. This action just selects text on the page as though
the left mouse button was depressed and the cursor moved across the
page.

lsb_release -rd
Description:Ubuntu 22.04 LTS
Release:22.04

Snapstore version 103.0-1 latest stable

Possibly related to being packaged as a snap (have noticed this
behaviour on Fedora using the firefox snap).

It's still possible to scroll by dragging the scrollbar but this
essentially breaks firefox on touch systems

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

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

** No longer affects: systemd (Ubuntu)

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

Title:
  Firefox does not scroll with touch input

Status in firefox package in Ubuntu:
  New

Bug description:
  Firefox does not scroll with the usual touch gesture of swiping up or
  down on the screen. This action just selects text on the page as
  though the left mouse button was depressed and the cursor moved across
  the page.

  lsb_release -rd
  Description:  Ubuntu 22.04 LTS
  Release:  22.04

  Snapstore version 103.0-1 latest stable

  Possibly related to being packaged as a snap (have noticed this
  behaviour on Fedora using the firefox snap).

  It's still possible to scroll by dragging the scrollbar but this
  essentially breaks firefox on touch systems

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1982885/+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 1958267] Re: wpa can't connect to servers using TLS 1.1 or older

2022-05-31 Thread Matthew Faigan

I've just installed 2:2.10-9ubuntu1 amd64 and I can confirm that it
works on Kubuntu 22.04 LTS for my university's WPA2 Enterprise network.

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

Title:
  wpa can't connect to servers using TLS 1.1 or older

Status in wpa package in Ubuntu:
  Fix Committed
Status in wpa source package in Jammy:
  Confirmed
Status in wpa package in Debian:
  New

Bug description:
  wpa built with in openssl3 fails to connect to TLS 1.1 or lower server

  those uses MD5-SHA1 as digest in its signature algorithm which no
  longer meets OpenSSL default level of security of 80 bits

  http://lists.infradead.org/pipermail/hostap/2022-May/040563.html

  Workaround are described in #22 and #36 by basically using 
  CipherString = DEFAULT@SECLEVEL=0

  which lowers the security level

  ---

  With the current jammy version of wpasupplicant (2:2.10-1), I cannot
  connect to the WPA Enterprise network eduroam, which is used by
  Universities worldwide. I get a "Connection failed" message or a
  request to re-enter the password.

  - I've re-tried the credentials: no fix ;-)

  - Tried a 21.10 live session on the same machine: works fine!

  - Manually downgraded wpasupplicant to the impish version
  (2:2.9.0-21build1): connected normally.

  - Upgraded wpasupplicant to the latest version: fails to connect
  again.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: wpasupplicant 2:2.10-1
  ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12
  Uname: Linux 5.15.0-17-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.11-0ubuntu75
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jan 18 09:56:23 2022
  InstallationDate: Installed on 2021-11-30 (48 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: wpa
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/+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 1971112] Re: File picker gets bigger more and more each time!

2022-05-17 Thread Matthew Gallagher

As I've noted in my duplicate bug report, this effects snaps (Firefox,
Brave) but not apts (Evince, Thunderbird).

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

Title:
  File picker gets bigger more and more each time!

Status in gtk+3.0 package in Ubuntu:
  Confirmed

Bug description:
  Hello. I've just switched to Ubuntu and ever since day 1 I had this issue 
that whenever I tried to choose a file the file picker window was way too big 
and it was getting bigger and bigger each time. I have posted a video on Reddit 
recording this unusual/unexpected behavior.
  Here is the reddit post link (with video):
  
https://www.reddit.com/r/Ubuntu/comments/ug97qx/annoying_bug_file_picker_gets_bigger_more_and/
  I've also attached the video to this post, in case you don't want to click 
the link above.

  Here is my neofetch output:

  OS: Ubuntu 22.04 LTS x86_64
  Kernel: 5.15.0-27-generic
  Uptime: 13 hours, 13 mins
  Shell: bash 5.1.16
  Resolution: 1440x900, 1920x1080
  DE: GNOME 42.0
  WM: Mutter
  WM Theme: Adwaita
  Theme: Yaru-viridian-dark [GTK2/3]
  Icons: Yaru-viridian [GTK2/3]
  Terminal: gnome-terminal
  CPU: Intel i7-8700K (12) @ 4.700GHz
  GPU: NVIDIA GeForce GTX 1060 3GB
  Memory: 5869MiB / 15936MiB

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1971112/+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 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument

2022-04-30 Thread Matthew D. Mower

This issue is no longer present in Ubuntu 22.04. Wile using Ubuntu 21.10, the 
following workarounds also remedied the issue:
- Run a mainline 5.15.x kernel from 
https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
- Run the Jammy Jellyfish kernel from 
https://packages.ubuntu.com/jammy/linux-image-generic
In both cases, it's necessary to install libssl3 from Jammy Jellyfish as well 
(see https://askubuntu.com/a/1389586/117513).

Ultimately, since Ubuntu 21.10 is rapidly approaching EoL, it makes
sense to upgrade to Ubuntu 22.04.

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

Title:
  amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid
  argument

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 21.10 does not succeed at setting the display brightness after
  booting (either to the GNOME login screen or to a logged-in user's
  desktop). The brightness is at its highest level until I adjust it
  with keyboard shortcuts or a GUI tool.

  The systemd-backlight@backlight:amdgpu_bl0 service seems to fail
  during startup, but I can subsequently run it after startup and it
  succeeds (and restores brightness):

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  [sudo] password for mdmower: 
  × systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: failed (Result: exit-code) since Tue 2021-12-14 13:26:05 PST; 
30s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 962 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=1/FAILURE)
 Main PID: 962 (code=exited, status=1/FAILURE)
  CPU: 3ms

  Dec 14 13:26:05 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:05 T14S systemd-backlight[962]: amdgpu_bl0: Failed to write 
system 'brightness' attribute: Invalid argument
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Failed with result 'exit-code'.
  Dec 14 13:26:05 T14S systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  mdmower@T14S ~ $ sudo systemctl start systemd-
  backlight@backlight:amdgpu_bl0

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  ● systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Tue 2021-12-14 13:26:45 PST; 1s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 5119 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=0/SUCCESS)
 Main PID: 5119 (code=exited, status=0/SUCCESS)
  CPU: 5ms

  Dec 14 13:26:45 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:45 T14S systemd[1]: Finished Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu2
  ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
  Uname: Linux 5.13.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Dec 14 13:29:38 2021
  DistUpgraded: Fresh install
  DistroCodename: impish
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [1002:1638] (rev d1) (prog-if 
00 [VGA controller])
 Subsystem: Lenovo Cezanne [17aa:5095]
  InstallationDate: Installed on 2021-12-12 (2 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  MachineType: LENOVO 20XF004WUS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-22-generic 
root=UUID=859a72cc-a3fe-470f-b525-37b151408289 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.14
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R1NET44W (1.14)
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20XF004WUS
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information

[Touch-packages] [Bug 1963834] Re: openssl 3.0 - SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED]

2022-04-26 Thread Matthew Geier

It's a bit of an 'own goal' if this gets marked as 'won't fix'. As students 
upgrade to 22.04 where I work they will find they can't connect to the 
institutions or research centre wireless network. They won't care that the SSL 
change is protecting them from an old SSL bug, they will just come back 'it 
works in windows but not Ubuntu'. 
Central IT services who run the wireless will just shrug and say 'Linux not 
supported'.
Need to make it easier to find how to turn on the Legacy insecure mode.

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

Title:
  openssl 3.0 - SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED]

Status in openssl package in Ubuntu:
  Won't Fix

Bug description:
  Description:Ubuntu Jammy Jellyfish (development branch)
  Release:22.04

  openssl:
Installé : 3.0.1-0ubuntu1
Candidat : 3.0.1-0ubuntu1
   Table de version :
   *** 3.0.1-0ubuntu1 500
  500 http://ca.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  100 /var/lib/dpkg/status

  Using Ubuntu 22.04, I now get the following error message when
  attempting to connect to our office VPN using "gp-saml-gui
  (https://github.com/dlenski/gp-saml-gui)" :

  #
  dominique@Doombuntu:~$ .local/bin/gp-saml-gui  server_url
  Looking for SAML auth tags in response to 
https://server_url/global-protect/prelogin.esp...
  usage: gp-saml-gui [-h] [--no-verify] [-C COOKIES | -K] [-g | -p] [-c CERT] 
[--key KEY] [-v | -q] [-x | -P | -S] [-u] [--clientos {Windows,Linux,Mac}] [-f 
EXTRA] server [openconnect_extra ...]
  gp-saml-gui: error: SSL error: [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] 
unsafe legacy renegotiation disabled (_ssl.c:997)
  #
  #
  #

  gp-saml-gui uses python module requests.
  Using python ide, I can get the same results  :

  #
  >>> r = requests.get('https://server_url')
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, 
in urlopen
  httplib_response = self._make_request(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 382, 
in _make_request
  self._validate_conn(conn)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 1012, 
in _validate_conn
  conn.connect()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 411, in 
connect
  self.sock = ssl_wrap_socket(
File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 449, in 
ssl_wrap_socket
  ssl_sock = _ssl_wrap_socket_impl(
File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 493, in 
_ssl_wrap_socket_impl
  return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
File "/usr/lib/python3.10/ssl.py", line 512, in wrap_socket
  return self.sslsocket_class._create(
File "/usr/lib/python3.10/ssl.py", line 1070, in _create
  self.do_handshake()
File "/usr/lib/python3.10/ssl.py", line 1341, in do_handshake
  self._sslobj.do_handshake()
  ssl.SSLError: [SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy 
renegotiation disabled (_ssl.c:997)

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in 
send
  resp = conn.urlopen(
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 755, 
in urlopen
  retries = retries.increment(
File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 574, in 
increment
  raise MaxRetryError(_pool, url, error or ResponseError(cause))
  urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='server_url', 
port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, 
'[SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation 
disabled (_ssl.c:997)')))

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/requests/api.py", line 76, in get
  return request('get', url, params=params, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 61, in request
  return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
  resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in 
send
  r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514, in 
send
  raise SSLError(e, request=request)
  requests.exceptions.SSLError: HTTPSConnectionPool(host='server_url', 
port=443): Max retries exceeded with url: / (Caused by SSLError(SSLError(1, 
'[SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy

[Touch-packages] [Bug 1964880] Re: software-properties-gtk crashed with AttributeError in packages_for_modalias(): 'Cache' object has no attribute 'packages'

2022-03-22 Thread Matthew Ruffell

I installed software-properties 0.99.20 from -proposed, and opened
software-properties-gtk, and clicked the "Additional Drivers" tab. The
tab loaded correctly and did not crash.

The package in -proposed fixes the issue, happy to mark verified.

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

Title:
  software-properties-gtk crashed with AttributeError in
  packages_for_modalias(): 'Cache' object has no attribute 'packages'

Status in software-properties package in Ubuntu:
  Fix Committed
Status in software-properties source package in Jammy:
  Fix Committed

Bug description:
  Opened up "Software & Updates" and clicked the "Additional Drivers
  Tab", for the tab to crash.

  ProblemType: Crash
  DistroRelease: Ubuntu 22.04
  Package: software-properties-gtk 0.99.19
  ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
  Uname: Linux 5.15.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 15 19:02:39 2022
  ExecutablePath: /usr/bin/software-properties-gtk
  InstallationDate: Installed on 2022-01-02 (72 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220101)
  InterpreterPath: /usr/bin/python3.10
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/bin/software-properties-gtk
  Python3Details: /usr/bin/python3.10, Python 3.10.2+, python3-minimal, 
3.10.1-0ubuntu2
  PythonArgs: ['/usr/bin/software-properties-gtk']
  PythonDetails: N/A
  SourcePackage: software-properties
  Title: software-properties-gtk crashed with AttributeError in 
packages_for_modalias(): 'Cache' object has no attribute 'packages'
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1964880/+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 1961344] Re: Sound works in LIVE cd but not in Installation

2022-03-22 Thread Matthew Lovibond

*** This bug is a duplicate of bug 1958410 ***
https://bugs.launchpad.net/bugs/1958410

** This bug has been marked a duplicate of bug 1958410
   bytcr_rt5640 sound not working with kernel >= 5.13

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

Title:
  Sound works in LIVE cd but not in Installation

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  Hello, I am using a Nextbook Flexx 10.1 I have attempted to use
  multiple fixes described online to no avail. It seems that when using
  the live mode off of the boot flash drive audio works fine. Alsamixer
  reports bytcr-rt5640 as sound card. however once installed no audio.
  alsamixer reports sof-bytcht rt5640 as card selected

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.13.0-30.33~20.04.1-generic 5.13.19
  Uname: Linux 5.13.0-30-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  delgadb2   1271 F pulseaudio
   /dev/snd/controlC0:  delgadb2   1271 F pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Feb 17 12:51:34 2022
  InstallationDate: Installed on 2022-02-17 (0 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:rt5640 failed
  Symptom_Card: Built-in Audio - sof-bytcht rt5640
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC1:  delgadb2   1271 F pulseaudio
   /dev/snd/controlC0:  delgadb2   1271 F pulseaudio
  Symptom_Type: No sound at all
  Title: [SOF - sof-bytcht rt5640, playback] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/09/2015
  dmi.bios.release: 18.18
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: NX1015.2.02.017
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: NXM1015BFP
  dmi.board.vendor: YIFANG
  dmi.board.version: 1.2
  dmi.chassis.asset.tag: Chassis Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: Chassis Manufacturer
  dmi.chassis.version: Chassis Version
  dmi.ec.firmware.release: 0.0
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvrNX1015.2.02.017:bd11/09/2015:br18.18:efr0.0:svnYIFANG:pnNXW101QC232T:pvrType1-TBDbyOEM:rvnYIFANG:rnNXM1015BFP:rvr1.2:cvnChassisManufacturer:ct10:cvrChassisVersion:skuType1-SKU0:
  dmi.product.family: M1015BFP T10220300
  dmi.product.name: NXW101QC232T
  dmi.product.sku: Type1 - SKU0
  dmi.product.version: Type1 - TBD by OEM
  dmi.sys.vendor: YIFANG

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1961344/+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 1942385] Re: [SOF - sof-bytcht rt5640, playback] fails after a while

2022-03-22 Thread Matthew Lovibond

*** This bug is a duplicate of bug 1958410 ***
https://bugs.launchpad.net/bugs/1958410

** This bug has been marked a duplicate of bug 1958410
   bytcr_rt5640 sound not working with kernel >= 5.13

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

Title:
  [SOF - sof-bytcht rt5640, playback] fails after a while

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  I am experiencing beep sound and audio from zoom, firefox, or vlc. It might 
play media for some seconds then beep. This has something to do with pipewire 
and sof driver and S16_LE format.( I read online).
  If I switch the profile Play HiFi quality Music in pavucontrol it does 
correct the beep sound for some few seconds then it

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: alsa-base 1.0.25+dfsg-0ubuntu7
  ProcVersionSignature: Ubuntu 5.13.0-14.14-generic 5.13.1
  Uname: Linux 5.13.0-14-generic x86_64
  ApportVersion: 2.20.11-0ubuntu68
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  bret   1249 F pulseaudio
   /dev/snd/pcmC0D0c:   bret   1249 F...m pulseaudio
   /dev/snd/pcmC0D0p:   bret   1249 F...m pulseaudio
   /dev/snd/timer:  bret   1249 f pulseaudio
  CasperMD5CheckResult: pass
  CurrentDesktop: XFCE
  Date: Thu Sep  2 05:25:01 2021
  InstallationDate: Installed on 2021-08-29 (3 days ago)
  InstallationMedia: Xubuntu 21.10 "Impish Indri" - Alpha amd64 (20210612)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_Card: Built-in Audio - sof-bytcht rt5640
  Symptom_PulseAudioLog:
   Sep 02 05:24:14 toshiba systemd[826]: pulseaudio.service: Deactivated 
successfully.
   Sep 02 05:24:25 toshiba systemd[826]: pulseaudio.socket: Deactivated 
successfully.
  Symptom_Type: Sound works for a while, then breaks
  Title: [SOF - sof-bytcht rt5640, playback] fails after a while
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/02/2015
  dmi.bios.release: 5.20
  dmi.bios.vendor: INSYDE Corp.
  dmi.bios.version: 5.20
  dmi.board.name: 0700
  dmi.board.vendor: FF50
  dmi.board.version: Type2 - Board Version
  dmi.chassis.asset.tag: No Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: OEM Chassis ManuFacturer
  dmi.chassis.version: OEM Chassis Version
  dmi.ec.firmware.release: 5.20
  dmi.modalias: 
dmi:bvnINSYDECorp.:bvr5.20:bd11/02/2015:br5.20:efr5.20:svnTOSHIBA:pnSATELLITEClickMiniL9W-B:pvrPDW0FE-002005EN:skuINVALID:rvnFF50:rn0700:rvrType2-BoardVersion:cvnOEMChassisManuFacturer:ct10:cvrOEMChassisVersion:
  dmi.product.family: INVALID
  dmi.product.name: SATELLITE Click Mini L9W-B
  dmi.product.sku: INVALID
  dmi.product.version: PDW0FE-002005EN
  dmi.sys.vendor: TOSHIBA

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1942385/+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 1964880] [NEW] software-properties-gtk crashed with AttributeError in packages_for_modalias(): 'Cache' object has no attribute 'packages'

2022-03-15 Thread Matthew Ruffell

Public bug reported:

Opened up "Software & Updates" and clicked the "Additional Drivers Tab",
for the tab to crash.

ProblemType: Crash
DistroRelease: Ubuntu 22.04
Package: software-properties-gtk 0.99.19
ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
Uname: Linux 5.15.0-23-generic x86_64
ApportVersion: 2.20.11-0ubuntu79
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Tue Mar 15 19:02:39 2022
ExecutablePath: /usr/bin/software-properties-gtk
InstallationDate: Installed on 2022-01-02 (72 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220101)
InterpreterPath: /usr/bin/python3.10
PackageArchitecture: all
ProcCmdline: /usr/bin/python3 /usr/bin/software-properties-gtk
Python3Details: /usr/bin/python3.10, Python 3.10.2+, python3-minimal, 
3.10.1-0ubuntu2
PythonArgs: ['/usr/bin/software-properties-gtk']
PythonDetails: N/A
SourcePackage: software-properties
Title: software-properties-gtk crashed with AttributeError in 
packages_for_modalias(): 'Cache' object has no attribute 'packages'
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo

** Affects: software-properties (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: software-properties (Ubuntu Jammy)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-crash jammy need-duplicate-check third-party-packages 
wayland-session

** Also affects: software-properties (Ubuntu Jammy)
   Importance: Undecided
   Status: New

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

Title:
  software-properties-gtk crashed with AttributeError in
  packages_for_modalias(): 'Cache' object has no attribute 'packages'

Status in software-properties package in Ubuntu:
  New
Status in software-properties source package in Jammy:
  New

Bug description:
  Opened up "Software & Updates" and clicked the "Additional Drivers
  Tab", for the tab to crash.

  ProblemType: Crash
  DistroRelease: Ubuntu 22.04
  Package: software-properties-gtk 0.99.19
  ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27
  Uname: Linux 5.15.0-23-generic x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Mar 15 19:02:39 2022
  ExecutablePath: /usr/bin/software-properties-gtk
  InstallationDate: Installed on 2022-01-02 (72 days ago)
  InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220101)
  InterpreterPath: /usr/bin/python3.10
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/bin/software-properties-gtk
  Python3Details: /usr/bin/python3.10, Python 3.10.2+, python3-minimal, 
3.10.1-0ubuntu2
  PythonArgs: ['/usr/bin/software-properties-gtk']
  PythonDetails: N/A
  SourcePackage: software-properties
  Title: software-properties-gtk crashed with AttributeError in 
packages_for_modalias(): 'Cache' object has no attribute 'packages'
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip libvirt lpadmin lxd plugdev sambashare sudo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1964880/+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 1960863] Re: armv8 paca: poly1305 users see segfaults when pointer authentication in use on AWS Graviton 3 instances

2022-02-23 Thread Matthew Ruffell

Performing verification for openssl on Focal.

An affected user performed the verification, due to c7g instance types
being in "Preview" state on Amazon AWS, and not generally accessible.

The user started a c7g instance, and checked they had openssl
1.1.1f-1ubuntu2.10 from -updates.

They attempted to use the poly1035 MAC downloading the file from the
testcase:

$ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 
0Segmentation fault (core dumped)

They can reproduce the issue.

They then enabled -proposed from ports.ubuntu.com mirror, and installed
openssl 1.1.1f-1ubuntu2.11.

They again tried downloading the file:

$ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
  
(note the file doesn't actually download due to curl not automatically 
following 301 redirects):

$ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin --verbose
...
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
...
< HTTP/1.1 301 Moved Permanently
< Location: https://downloads.gradle-dn.com/distributions/gradle-7.2-bin.zip
...

curl does not segfault, and exits successfully. The package in -proposed
fixes the issue. Happy to mark as verified.

** Tags removed: sts-sponsor verification-needed verification-needed-focal
** Tags added: verification-done verification-done-focal

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

Title:
  armv8 paca: poly1305 users see segfaults when pointer authentication
  in use on AWS Graviton 3 instances

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  Support for hardware pointer authentication for armv8 systems was
  merged in openssl 1.1.1f, but it contains a bug in the implementation
  for poly1305 message authenticated code routines, which causes the
  calling program to fail pointer authentication, which causes the
  program to crash with a segmentation fault.

  You can easily test it by accessing any website that uses poly1305.
  There is no workaround except use a different MAC.

  [Testcase]

  This bug applies to armv8 systems which support pointer
  authentication. Start an armv8 instance, such as a c7g graviton 3
  instance on AWS, and make sure the paca flag is present in lscpu:

  $ grep paca /proc/cpuinfo
  Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp 
cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm 
dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng

  Next, attempt to connect to any website that uses poly1305 MAC.

  $ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Segmentation fault (core dumped)

  There is a test package available in the following ppa:

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

  Install it, and poly1305 operations will no longer segfault.

  [Where problems could occur]

  The patch changes the order of operations for loading the SP and
  checking the AUTIASP against it, from checking the AUTIASP against
  nothing then loading the correct SP to check with, to the correct
  loading the SP and then checking the AUTIASP against the SP.

  This only changes one code path for armv8 systems, and other
  architectures are not affected. This is also only limited to poly1305
  MAC.

  If a regression were to occur, it would only affect users of poly1035
  MAC on armv8 with pacs support.

  [Other info]

  The fix landed upstream in openssl 1.1.1i with the following commit:

  commit 5795acffd8706e1cb584284ee5bb3a30986d0e75
  Author: Ard Biesheuvel 
  Date:   Tue Oct 27 18:02:40 2020 +0100
  Subject: crypto/poly1305/asm: fix armv8 pointer authentication
  Link: 
https://github.com/openssl/openssl/commit/5795acffd8706e1cb584284ee5bb3a30986d0e75

  This commit is already present in Impish onward. Only Focal needs the
  fix.

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


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

[Touch-packages] [Bug 1961542] Re: libsmartcols: Revert back to previous behaviour of non-shell parsable column output (lsblk -P)

2022-02-20 Thread Matthew Ruffell

Attached is a debdiff for Jammy util-linux.

** Patch added: "debdiff for util-linux on Jammy"
   
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1961542/+attachment/5562373/+files/lp1961542_jammy.debdiff

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

Title:
  libsmartcols: Revert back to previous behaviour of non-shell parsable
  column output (lsblk -P)

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Jammy:
  In Progress

Bug description:
  [Impact]

  util-linux 2.37 in Jammy has introduced some new behaviour for lsblk
  and similar tools which depend on libsmartcols. This switched the -P /
  --pairs parameter from printing column names as normal, to changing
  the names to shell compatible names instead.

  e.g. lsblk -P now outputs LOG_SEC instead of LOG-SEC.

  The change broke some core tooling which rely on on the output of
  lsblk -P, most notably, curtin and MAAS, but I am sure there will be
  more applications affected.

  Affected MAAS users will see the following traceback when attempting
  to deploy 22.04:

  Traceback (most recent call last):
  File "/curtin/curtin/block/__init__.py", line 785, in get_blockdev_sector_size
  logical = info[parent]['LOG-SEC']
  KeyError: 'LOG-SEC'
  'LOG-SEC'
  curtin: Installation failed with exception: Unexpected error while running 

  This is documented in MAAS bug 1956613.

  MAAS decided to fix it by changing from -P to -J, in the following commit:
  
https://git.launchpad.net/maas/commit/?id=e2c01963430e6837198a54bc1eadf3efc9fdd9a2

  Curtin now checks for MAJ_MIN, and changes it back to MAJ:MIN in:
  
https://github.com/canonical/curtin/commit/ce811db127fe1ce46498b83615f8faed8c7dfeb6

  The issue is that these commits are not tagged to any MAAS release,
  and users would be forced to upgrade MAAS to the latest stable release
  when available if they want to deploy 22.04.

  There are many users out there that don't want to upgrade MAAS, so
  returning to the previous column output is the most desirable
  solution.

  [Testcase]

  On a Jammy install, simply run lsblk with either -P or --pairs:

  $ sudo lsblk -P
  ...
  NAME="sda" MAJ_MIN="8:0" RM="0" SIZE="465.8G" RO="0" TYPE="disk" 
MOUNTPOINTS=""
  ...

  Affected installs will see MAJ_MIN.

  There is a test package available in the following ppa:

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

  If you install it, you will see MAJ:MIN, just like it is on Impish and
  previous.

  [Where problems could occur]

  We are changing the column output for -P and --pairs for the following
  applications:

  * lsblk
  * findmnt
  * lsipc

  If any application has been modified to depend on the new column
  output, it will break. I don't have any examples of something that
  will break, because MAAS and curtin were modified such that they would
  be compatible with both column name formats.

  It should be noted that the manpage documents that lsblk output can
  change at any time:

  > The default output, as well as the default output from options like --fs 
and --topology, is subject to change. 
  > So whenever possible, you should avoid using default outputs in your 
scripts. 
  > Always explicitly define expected columns by using --output columns-list 
and --list in environments where a stable output is required.

  If a regression should occur, we will need to fix up these affected
  packages also.

  [Other info]

  The change came about when a user asked upstream to make -P / --pairs
  shell parsable, in Issue 1201 upstream:

  https://github.com/util-linux/util-linux/issues/1201

  Karel Zak obliged, and it was implemented in the following commit:

  commit 58b510e5805d8350c31bfb81a47bcd38ea9fdd7e
  From: Karel Zak 
  Date: Thu, 3 Dec 2020 12:14:10 +0100
  Subject: libsmartcols: sanitize variable names on export output
  Link: 
https://github.com/util-linux/util-linux/commit/58b510e5805d8350c31bfb81a47bcd38ea9fdd7e

  I wrote to Karel Zak with the regressions introduced by changing the
  format, and asked to revert back, and instead implement the shell
  parsable logic as a new parameter.

  This happened in upstream issue 1594:

  https://github.com/util-linux/util-linux/issues/1594

  Karel Zak was happy to oblige again, and we now have the following
  commits:

  338ad4a93 findmnt: commit missing flag
  0f843ab64 lsblk: update --help output for -y
  eba05f308 lsipc: add -y,--shell
  152c17aa4 findmnt: add -y,--shell
  9c7e81ff1 lslogins: add -y,--shell
  25fb0638a lsblk: add -y/--shell
  39679ea0c lsfd: use new libsmartcols functions
  6fd0e3590 column: use new libsmartcols functions
  0b3c2e80d include/carefulputc: remove unused function
  3b5db50f7 libsmartcols: change "export" behavior, add "shellvar" flag

  While we got the intended behaviour, these commits won't land until

[Touch-packages] [Bug 1961542] [NEW] libsmartcols: Revert back to previous behaviour of non-shell parsable column output (lsblk -P)

2022-02-20 Thread Matthew Ruffell

Public bug reported:

[Impact]

util-linux 2.37 in Jammy has introduced some new behaviour for lsblk and
similar tools which depend on libsmartcols. This switched the -P /
--pairs parameter from printing column names as normal, to changing the
names to shell compatible names instead.

e.g. lsblk -P now outputs LOG_SEC instead of LOG-SEC.

The change broke some core tooling which rely on on the output of lsblk
-P, most notably, curtin and MAAS, but I am sure there will be more
applications affected.

Affected MAAS users will see the following traceback when attempting to
deploy 22.04:

Traceback (most recent call last):
File "/curtin/curtin/block/__init__.py", line 785, in get_blockdev_sector_size
logical = info[parent]['LOG-SEC']
KeyError: 'LOG-SEC'
'LOG-SEC'
curtin: Installation failed with exception: Unexpected error while running 

This is documented in MAAS bug 1956613.

MAAS decided to fix it by changing from -P to -J, in the following commit:
https://git.launchpad.net/maas/commit/?id=e2c01963430e6837198a54bc1eadf3efc9fdd9a2

Curtin now checks for MAJ_MIN, and changes it back to MAJ:MIN in:
https://github.com/canonical/curtin/commit/ce811db127fe1ce46498b83615f8faed8c7dfeb6

The issue is that these commits are not tagged to any MAAS release, and
users would be forced to upgrade MAAS to the latest stable release when
available if they want to deploy 22.04.

There are many users out there that don't want to upgrade MAAS, so
returning to the previous column output is the most desirable solution.

[Testcase]

On a Jammy install, simply run lsblk with either -P or --pairs:

$ sudo lsblk -P
...
NAME="sda" MAJ_MIN="8:0" RM="0" SIZE="465.8G" RO="0" TYPE="disk" MOUNTPOINTS=""
...

Affected installs will see MAJ_MIN.

There is a test package available in the following ppa:

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

If you install it, you will see MAJ:MIN, just like it is on Impish and
previous.

[Where problems could occur]

We are changing the column output for -P and --pairs for the following
applications:

* lsblk
* findmnt
* lsipc

If any application has been modified to depend on the new column output,
it will break. I don't have any examples of something that will break,
because MAAS and curtin were modified such that they would be compatible
with both column name formats.

It should be noted that the manpage documents that lsblk output can
change at any time:

> The default output, as well as the default output from options like --fs and 
> --topology, is subject to change. 
> So whenever possible, you should avoid using default outputs in your scripts. 
> Always explicitly define expected columns by using --output columns-list and 
> --list in environments where a stable output is required.

If a regression should occur, we will need to fix up these affected
packages also.

[Other info]

The change came about when a user asked upstream to make -P / --pairs
shell parsable, in Issue 1201 upstream:

https://github.com/util-linux/util-linux/issues/1201

Karel Zak obliged, and it was implemented in the following commit:

commit 58b510e5805d8350c31bfb81a47bcd38ea9fdd7e
From: Karel Zak 
Date: Thu, 3 Dec 2020 12:14:10 +0100
Subject: libsmartcols: sanitize variable names on export output
Link: 
https://github.com/util-linux/util-linux/commit/58b510e5805d8350c31bfb81a47bcd38ea9fdd7e

I wrote to Karel Zak with the regressions introduced by changing the
format, and asked to revert back, and instead implement the shell
parsable logic as a new parameter.

This happened in upstream issue 1594:

https://github.com/util-linux/util-linux/issues/1594

Karel Zak was happy to oblige again, and we now have the following
commits:

338ad4a93 findmnt: commit missing flag
0f843ab64 lsblk: update --help output for -y
eba05f308 lsipc: add -y,--shell
152c17aa4 findmnt: add -y,--shell
9c7e81ff1 lslogins: add -y,--shell
25fb0638a lsblk: add -y/--shell
39679ea0c lsfd: use new libsmartcols functions
6fd0e3590 column: use new libsmartcols functions
0b3c2e80d include/carefulputc: remove unused function
3b5db50f7 libsmartcols: change "export" behavior, add "shellvar" flag

While we got the intended behaviour, these commits won't land until
util-linux 2.38, which will be after Jammy releases, and the other issue
is that this changes a significant amount of code, like nearly 1k lines,
and is spread over 10+ commits.

I wrote to ubuntu-devel asking for advice, on either 1) not changing
anything 2) backporting the 10+ new commits, or 3) simply reverting the
commit which changed the behaviour.

https://lists.ubuntu.com/archives/ubuntu-devel/2022-February/041870.html

ubuntu-devel had strong support for option (3).

Hence, we will revert the below commit to ensure Jammy can be deployed on all 
existing MAAS releases.
58b510e580 libsmartcols: sanitize variable names on export output

** Affects: util-linu

[Touch-packages] [Bug 1960863] Re: armv8 paca: poly1305 users see segfaults when pointer authentication in use on AWS Graviton 3 instances

2022-02-14 Thread Matthew Ruffell

** Tags added: sts-sponsor

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

Title:
  armv8 paca: poly1305 users see segfaults when pointer authentication
  in use on AWS Graviton 3 instances

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  In Progress

Bug description:
  [Impact]

  Support for hardware pointer authentication for armv8 systems was
  merged in openssl 1.1.1f, but it contains a bug in the implementation
  for poly1305 message authenticated code routines, which causes the
  calling program to fail pointer authentication, which causes the
  program to crash with a segmentation fault.

  You can easily test it by accessing any website that uses poly1305.
  There is no workaround except use a different MAC.

  [Testcase]

  This bug applies to armv8 systems which support pointer
  authentication. Start an armv8 instance, such as a c7g graviton 3
  instance on AWS, and make sure the paca flag is present in lscpu:

  $ grep paca /proc/cpuinfo
  Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp 
cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm 
dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng

  Next, attempt to connect to any website that uses poly1305 MAC.

  $ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Segmentation fault (core dumped)

  There is a test package available in the following ppa:

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

  Install it, and poly1305 operations will no longer segfault.

  [Where problems could occur]

  The patch changes the order of operations for loading the SP and
  checking the AUTIASP against it, from checking the AUTIASP against
  nothing then loading the correct SP to check with, to the correct
  loading the SP and then checking the AUTIASP against the SP.

  This only changes one code path for armv8 systems, and other
  architectures are not affected. This is also only limited to poly1305
  MAC.

  If a regression were to occur, it would only affect users of poly1035
  MAC on armv8 with pacs support.

  [Other info]

  The fix landed upstream in openssl 1.1.1i with the following commit:

  commit 5795acffd8706e1cb584284ee5bb3a30986d0e75
  Author: Ard Biesheuvel 
  Date:   Tue Oct 27 18:02:40 2020 +0100
  Subject: crypto/poly1305/asm: fix armv8 pointer authentication
  Link: 
https://github.com/openssl/openssl/commit/5795acffd8706e1cb584284ee5bb3a30986d0e75

  This commit is already present in Impish onward. Only Focal needs the
  fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1960863/+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 1960863] Re: armv8 paca: poly1305 users see segfaults when pointer authentication in use on AWS Graviton 3 instances

2022-02-14 Thread Matthew Ruffell

Attached is a debdiff for openssl on Focal

** Patch added: "debdiff for openssl on Focal"
   
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1960863/+attachment/5560898/+files/lp1960863_focal.debdiff

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

Title:
  armv8 paca: poly1305 users see segfaults when pointer authentication
  in use on AWS Graviton 3 instances

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  In Progress

Bug description:
  [Impact]

  Support for hardware pointer authentication for armv8 systems was
  merged in openssl 1.1.1f, but it contains a bug in the implementation
  for poly1305 message authenticated code routines, which causes the
  calling program to fail pointer authentication, which causes the
  program to crash with a segmentation fault.

  You can easily test it by accessing any website that uses poly1305.
  There is no workaround except use a different MAC.

  [Testcase]

  This bug applies to armv8 systems which support pointer
  authentication. Start an armv8 instance, such as a c7g graviton 3
  instance on AWS, and make sure the paca flag is present in lscpu:

  $ grep paca /proc/cpuinfo
  Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp 
cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm 
dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng

  Next, attempt to connect to any website that uses poly1305 MAC.

  $ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Segmentation fault (core dumped)

  There is a test package available in the following ppa:

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

  Install it, and poly1305 operations will no longer segfault.

  [Where problems could occur]

  The patch changes the order of operations for loading the SP and
  checking the AUTIASP against it, from checking the AUTIASP against
  nothing then loading the correct SP to check with, to the correct
  loading the SP and then checking the AUTIASP against the SP.

  This only changes one code path for armv8 systems, and other
  architectures are not affected. This is also only limited to poly1305
  MAC.

  If a regression were to occur, it would only affect users of poly1035
  MAC on armv8 with pacs support.

  [Other info]

  The fix landed upstream in openssl 1.1.1i with the following commit:

  commit 5795acffd8706e1cb584284ee5bb3a30986d0e75
  Author: Ard Biesheuvel 
  Date:   Tue Oct 27 18:02:40 2020 +0100
  Subject: crypto/poly1305/asm: fix armv8 pointer authentication
  Link: 
https://github.com/openssl/openssl/commit/5795acffd8706e1cb584284ee5bb3a30986d0e75

  This commit is already present in Impish onward. Only Focal needs the
  fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1960863/+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 1960863] [NEW] armv8 paca: poly1305 users see segfaults when pointer authentication in use on AWS Graviton 3 instances

2022-02-14 Thread Matthew Ruffell

Public bug reported:

[Impact]

Support for hardware pointer authentication for armv8 systems was merged
in openssl 1.1.1f, but it contains a bug in the implementation for
poly1305 message authenticated code routines, which causes the calling
program to fail pointer authentication, which causes the program to
crash with a segmentation fault.

You can easily test it by accessing any website that uses poly1305.
There is no workaround except use a different MAC.

[Testcase]

This bug applies to armv8 systems which support pointer authentication.
Start an armv8 instance, such as a c7g graviton 3 instance on AWS, and
make sure the paca flag is present in lscpu:

$ grep paca /proc/cpuinfo
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp 
cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm 
dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng

Next, attempt to connect to any website that uses poly1305 MAC.

$ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Segmentation fault (core dumped)

There is a test package available in the following ppa:

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

Install it, and poly1305 operations will no longer segfault.

[Where problems could occur]

The patch changes the order of operations for loading the SP and
checking the AUTIASP against it, from checking the AUTIASP against
nothing then loading the correct SP to check with, to the correct
loading the SP and then checking the AUTIASP against the SP.

This only changes one code path for armv8 systems, and other
architectures are not affected. This is also only limited to poly1305
MAC.

If a regression were to occur, it would only affect users of poly1035
MAC on armv8 with pacs support.

[Other info]

The fix landed upstream in openssl 1.1.1i with the following commit:

commit 5795acffd8706e1cb584284ee5bb3a30986d0e75
Author: Ard Biesheuvel 
Date:   Tue Oct 27 18:02:40 2020 +0100
Subject: crypto/poly1305/asm: fix armv8 pointer authentication
Link: 
https://github.com/openssl/openssl/commit/5795acffd8706e1cb584284ee5bb3a30986d0e75

This commit is already present in Impish onward. Only Focal needs the
fix.

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

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


** Tags: focal sts

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

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

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

** Changed in: openssl (Ubuntu Focal)
   Importance: Undecided => High

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

** Tags added: focal sts

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

Title:
  armv8 paca: poly1305 users see segfaults when pointer authentication
  in use on AWS Graviton 3 instances

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Focal:
  In Progress

Bug description:
  [Impact]

  Support for hardware pointer authentication for armv8 systems was
  merged in openssl 1.1.1f, but it contains a bug in the implementation
  for poly1305 message authenticated code routines, which causes the
  calling program to fail pointer authentication, which causes the
  program to crash with a segmentation fault.

  You can easily test it by accessing any website that uses poly1305.
  There is no workaround except use a different MAC.

  [Testcase]

  This bug applies to armv8 systems which support pointer
  authentication. Start an armv8 instance, such as a c7g graviton 3
  instance on AWS, and make sure the paca flag is present in lscpu:

  $ grep paca /proc/cpuinfo
  Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp 
cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm 
dit uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng

  Next, attempt to connect to any website that uses poly1305 MAC.

  $ curl https://services.gradle.org/distributions/gradle-7.2-bin.zip --output 
gradle-7.2.bin
  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0Segmentation fault (core dumped)

  There is a test package available in the following ppa:

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

  Install it, and poly1305 operations will no longer segfault.

  [Where problems could occur]

[Touch-packages] [Bug 1954724] Re: Removing unattended-upgrades removes ubuntu-server-minimal

2022-01-30 Thread Matthew Ruffell

This has been fixed as of ubuntu-meta 1.474
https://launchpad.net/ubuntu/+source/ubuntu-meta/1.474

$ sudo apt rdepends unattended-upgrades
unattended-upgrades
Reverse Depends:
  Recommends: python3-software-properties
  Recommends: ubuntu-mate-desktop
  Recommends: ubuntu-mate-core
  Depends: freedombox
  Recommends: fbx-all
  Recommends: ubuntu-server-minimal
  Recommends: ubuntu-server

** Changed in: ubuntu-meta (Ubuntu Jammy)
   Status: Confirmed => Fix Released

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

Title:
  Removing unattended-upgrades removes ubuntu-server-minimal

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-meta source package in Impish:
  Confirmed
Status in ubuntu-meta source package in Jammy:
  Fix Released

Bug description:
  On Impish and later, removing unattended-upgrades also removes ubuntu-
  server-minimal due to ubuntu-server-minimal depending on unattended-
  upgrades

  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
    ubuntu-server-minimal unattended-upgrades
  0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

  This behaviour has changed since ubuntu-meta 1.471 [1] when the
  ubuntu-server-minimal metapackage was introduced, declaring
  unattended-upgrades as Depends.

  [1] https://launchpadlibrarian.net/550345392/ubuntu-
  meta_1.470_1.471.diff.gz

  On Focal, there was no such behaviour on a fresh ubuntu-server
  install:

  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
    unattended-upgrades
  0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.

  Removing unattended-upgrades is quite popular amongst our users, and
  they should be allowed to remove the package without removing the
  ubuntu-server-minimal metapackage.

  Looking at the source package for ubuntu-meta, unattended-upgrades is
  only Depends for ubuntu-server-minimal, maybe we should simply remove
  it, or instead, change to recommends?

  $ grep -Rin "unattended-upgrades" .
  ./server-minimal-armhf:23:unattended-upgrades
  ./server-minimal-riscv64:23:unattended-upgrades
  ./server-minimal-arm64:23:unattended-upgrades
  ./server-minimal-ppc64el:23:unattended-upgrades
  ./server-minimal-s390x:24:unattended-upgrades
  ./server-minimal-amd64:23:unattended-upgrades

  $ sudo apt rdepends unattended-upgrades
  unattended-upgrades
  Reverse Depends:
    Recommends: python3-software-properties
    Recommends: ubuntu-mate-desktop
    Recommends: ubuntu-mate-core
    Depends: freedombox
    Recommends: fbx-all
    Depends: ubuntu-server-minimal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724/+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 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument

2022-01-30 Thread Matthew D. Mower

I compiled several Ubuntu-5.13.0-x.x tags from 
https://kernel.ubuntu.com/git/ubuntu/ubuntu-impish.git/refs/ but the backlight 
issue seems to go far back in time. I tested:
- Ubuntu-5.13.0-25.26
- Ubuntu-5.13.0-21.21
- Ubuntu-5.13.0-20.20
- Ubuntu-5.13.0-19.19
- Ubuntu-5.13.0-16.16

In Ubuntu-5.13.0-16.16, there are some 400ish commits by Ubuntu on top
of upstream v5.13.13. I haven't been able to identify which could be
responsible, yet.

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

Title:
  amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid
  argument

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 21.10 does not succeed at setting the display brightness after
  booting (either to the GNOME login screen or to a logged-in user's
  desktop). The brightness is at its highest level until I adjust it
  with keyboard shortcuts or a GUI tool.

  The systemd-backlight@backlight:amdgpu_bl0 service seems to fail
  during startup, but I can subsequently run it after startup and it
  succeeds (and restores brightness):

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  [sudo] password for mdmower: 
  × systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: failed (Result: exit-code) since Tue 2021-12-14 13:26:05 PST; 
30s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 962 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=1/FAILURE)
 Main PID: 962 (code=exited, status=1/FAILURE)
  CPU: 3ms

  Dec 14 13:26:05 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:05 T14S systemd-backlight[962]: amdgpu_bl0: Failed to write 
system 'brightness' attribute: Invalid argument
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Failed with result 'exit-code'.
  Dec 14 13:26:05 T14S systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  mdmower@T14S ~ $ sudo systemctl start systemd-
  backlight@backlight:amdgpu_bl0

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  ● systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Tue 2021-12-14 13:26:45 PST; 1s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 5119 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=0/SUCCESS)
 Main PID: 5119 (code=exited, status=0/SUCCESS)
  CPU: 5ms

  Dec 14 13:26:45 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:45 T14S systemd[1]: Finished Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu2
  ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
  Uname: Linux 5.13.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Dec 14 13:29:38 2021
  DistUpgraded: Fresh install
  DistroCodename: impish
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [1002:1638] (rev d1) (prog-if 
00 [VGA controller])
 Subsystem: Lenovo Cezanne [17aa:5095]
  InstallationDate: Installed on 2021-12-12 (2 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  MachineType: LENOVO 20XF004WUS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-22-generic 
root=UUID=859a72cc-a3fe-470f-b525-37b151408289 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.14
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R1NET44W (1.14)
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20XF004WUS
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None

[Touch-packages] [Bug 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument

2022-01-29 Thread Matthew D. Mower

I just tested signed Ubuntu kernel 5.13.0-28-generic which is in
Proposed right now, but it does not fix the issue. Brightness
adjustments work, but service fails during startup and screen is at full
brightness every boot (at gdm and at GNOME 3 desktop).

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

Title:
  amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid
  argument

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 21.10 does not succeed at setting the display brightness after
  booting (either to the GNOME login screen or to a logged-in user's
  desktop). The brightness is at its highest level until I adjust it
  with keyboard shortcuts or a GUI tool.

  The systemd-backlight@backlight:amdgpu_bl0 service seems to fail
  during startup, but I can subsequently run it after startup and it
  succeeds (and restores brightness):

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  [sudo] password for mdmower: 
  × systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: failed (Result: exit-code) since Tue 2021-12-14 13:26:05 PST; 
30s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 962 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=1/FAILURE)
 Main PID: 962 (code=exited, status=1/FAILURE)
  CPU: 3ms

  Dec 14 13:26:05 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:05 T14S systemd-backlight[962]: amdgpu_bl0: Failed to write 
system 'brightness' attribute: Invalid argument
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Failed with result 'exit-code'.
  Dec 14 13:26:05 T14S systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  mdmower@T14S ~ $ sudo systemctl start systemd-
  backlight@backlight:amdgpu_bl0

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  ● systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Tue 2021-12-14 13:26:45 PST; 1s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 5119 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=0/SUCCESS)
 Main PID: 5119 (code=exited, status=0/SUCCESS)
  CPU: 5ms

  Dec 14 13:26:45 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:45 T14S systemd[1]: Finished Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu2
  ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
  Uname: Linux 5.13.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Dec 14 13:29:38 2021
  DistUpgraded: Fresh install
  DistroCodename: impish
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [1002:1638] (rev d1) (prog-if 
00 [VGA controller])
 Subsystem: Lenovo Cezanne [17aa:5095]
  InstallationDate: Installed on 2021-12-12 (2 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  MachineType: LENOVO 20XF004WUS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-22-generic 
root=UUID=859a72cc-a3fe-470f-b525-37b151408289 ro quiet splash vt.handoff=7
  SourcePackage: xorg
  Symptom: display
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.14
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R1NET44W (1.14)
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20XF004WUS
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0J40697 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.14
  dmi.modalias:

[Touch-packages] [Bug 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument

2022-01-29 Thread Matthew D. Mower

I tested some mainline 5.13.x kernels from
https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D and was able to
find a point release where this issue is resolved. Testing results:

Signed Ubuntu kernel 5.13.0-27-generic: brightness adjustments work, but
service fails during startup and screen is at full brightness every boot
(at gdm and at GNOME 3 desktop)

Unsigned mainline kernels:
- 5.13.19 - fixed, service starts successfully automatically
- 5.13.15 - fixed, service starts successfully automatically
- 5.13.12 - fixed, service starts successfully automatically
- 5.13.11 - fixed, service starts successfully automatically
- 5.13.9  - stuck at max brightness, adjustments don't work at all, service 
starts successfully but is ineffective
- 5.13.0  - stuck at max brightness, adjustments don't work at all (forgot to 
check whether service started)

The service I was looking at for status on bootup is: systemd-
backlight@backlight:amdgpu_bl0

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

Title:
  amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid
  argument

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 21.10 does not succeed at setting the display brightness after
  booting (either to the GNOME login screen or to a logged-in user's
  desktop). The brightness is at its highest level until I adjust it
  with keyboard shortcuts or a GUI tool.

  The systemd-backlight@backlight:amdgpu_bl0 service seems to fail
  during startup, but I can subsequently run it after startup and it
  succeeds (and restores brightness):

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  [sudo] password for mdmower: 
  × systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: failed (Result: exit-code) since Tue 2021-12-14 13:26:05 PST; 
30s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 962 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=1/FAILURE)
 Main PID: 962 (code=exited, status=1/FAILURE)
  CPU: 3ms

  Dec 14 13:26:05 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:05 T14S systemd-backlight[962]: amdgpu_bl0: Failed to write 
system 'brightness' attribute: Invalid argument
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Failed with result 'exit-code'.
  Dec 14 13:26:05 T14S systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  mdmower@T14S ~ $ sudo systemctl start systemd-
  backlight@backlight:amdgpu_bl0

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  ● systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Tue 2021-12-14 13:26:45 PST; 1s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 5119 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=0/SUCCESS)
 Main PID: 5119 (code=exited, status=0/SUCCESS)
  CPU: 5ms

  Dec 14 13:26:45 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:45 T14S systemd[1]: Finished Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu2
  ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
  Uname: Linux 5.13.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Dec 14 13:29:38 2021
  DistUpgraded: Fresh install
  DistroCodename: impish
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Advanced Micro Devices, Inc. [AMD/ATI] Cezanne [1002:1638] (rev d1) (prog-if 
00 [VGA controller])
 Subsystem: Lenovo Cezanne [17aa:5095]
  InstallationDate: Installed on 2021-12-12 (2 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  MachineType: LENOVO 20XF004WUS
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-22-generic 
root=UUID=859a72cc-a3fe-470f-b525-37b151408289 ro quiet

[Touch-packages] [Bug 1958572] [NEW] kernel bug causing screen corruption on AMD GPU

2022-01-20 Thread Matthew Bradley

Public bug reported:

Hi,

I'm running Ubuntu MATE 18.04.6 LTS. The bug information was sadly
collected from the working configuration of the system after dropping to
an earlier kernel.

This bug is a display bug where 1-pixel horizontal lines of multicolored
corruption or occasionally incorrect screen contents appear across the
screen, particularly during scrolling or moving the mouse. They appear
intermittently, being more common near the top of the screen.

My GPU is the built-in one on the AMD A10-5750M APU, the Radeon HD
8650G. (Laptop: G505s)

I have found that this bug occurs on vmlinuz-5.4.0-96-generic but does
not appear to occur on vmlinuz-5.4.0-91-generic when booting with that
option in GRUB.

I have not yet been able to capture an image of the issue as it becomes
difficult to use the system when the bug occurs (though it appears to be
fully functional, graphics aside). If very important I can try again
later.

-Matt

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: xorg 1:7.7+19ubuntu7.1
ProcVersionSignature: Ubuntu 5.4.0-91.102~18.04.1-generic 5.4.151
Uname: Linux 5.4.0-91-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.9-0ubuntu7.27
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: None
CurrentDesktop: MATE
Date: Thu Jan 20 14:05:30 2022
DistUpgraded: Fresh install
DistroCodename: bionic
DistroVariant: ubuntu
DkmsStatus:
 bcmwl, 6.30.223.271+bdcom, 5.4.0-91-generic, x86_64: installed
 bcmwl, 6.30.223.271+bdcom, 5.4.0-94-generic, x86_64: installed
 bcmwl, 6.30.223.271+bdcom, 5.4.0-96-generic, x86_64: installed
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G] [1002:990b] 
(prog-if 00 [VGA controller])
   Subsystem: Lenovo Richland [Radeon HD 8650G] [17aa:397c]
InstallationDate: Installed on 2019-12-28 (754 days ago)
InstallationMedia: Ubuntu-MATE 18.04.3 LTS "Bionic Beaver" - Release amd64 
(20190805)
MachineType: LENOVO 20255
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-91-generic 
root=UUID=3e3ee235-a725-4a35-a01f-8c156ee072f1 ro quiet splash vt.handoff=1
SourcePackage: xorg
Symptom: display
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 01/08/2014
dmi.bios.vendor: LENOVO
dmi.bios.version: 83CN53WW(V3.00)
dmi.board.asset.tag: No Asset Tag
dmi.board.name: Lenovo G505s
dmi.board.vendor: LENOVO
dmi.board.version: 3193Std
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Lenovo G505s
dmi.modalias: 
dmi:bvnLENOVO:bvr83CN53WW(V3.00):bd01/08/2014:svnLENOVO:pn20255:pvrLenovoG505s:rvnLENOVO:rnLenovoG505s:rvr3193Std:cvnLENOVO:ct10:cvrLenovoG505s:
dmi.product.family: IDEAPAD
dmi.product.name: 20255
dmi.product.sku: LENOVO_MT_20255
dmi.product.version: Lenovo G505s
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1
version.libdrm2: libdrm2 2.4.101-2~18.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~18.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx 20.0.8-0ubuntu1~18.04.1
version.xserver-xorg-core: xserver-xorg-core N/A
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

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


** Tags: amd64 apport-bug bionic corruption kernel-bug ubuntu

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

Title:
  kernel bug causing screen corruption on AMD GPU

Status in xorg package in Ubuntu:
  New

Bug description:
  Hi,

  I'm running Ubuntu MATE 18.04.6 LTS. The bug information was sadly
  collected from the working configuration of the system after dropping
  to an earlier kernel.

  This bug is a display bug where 1-pixel horizontal lines of
  multicolored corruption or occasionally incorrect screen contents
  appear across the screen, particularly during scrolling or moving the
  mouse. They appear intermittently, being more common near the top of
  the screen.

  My GPU is the built-in one on the AMD A10-5750M APU, the Radeon HD
  8650G. (Laptop: G505s)

  I have found that this bug occurs on vmlinuz-5.4.0-96-generic but does
  not appear to occur on vmlinuz-5.4.0-91-generic when booting with that
  option in GRUB.

  I have not yet been able to capture an image of the issue as it
  becomes difficult to use the system when the bug occurs (though it
  appears to be fully functional, graphics aside). If very important I
  can try again later.

  -Matt

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: xorg 1:7.7+19ubuntu7.1

[Touch-packages] [Bug 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument

2021-12-18 Thread Matthew D. Mower

I enabled debug logging for systemd with kernel cmdline:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on

New log attached to bug report is the output of 'journalctl -b':
systemd-debug.log

Filtering on "backlight" and omitting systemd-logind, this portion looks
interesting to my novice eyes. Does it imply the device loads after
systemd-backlight attempts to load the brightness value?

Dec 18 11:03:31 T14S systemd-backlight[1131]: amdgpu_bl0: Maximum brightness is 
255
Dec 18 11:03:31 T14S systemd-backlight[1131]: sd-device-enumerator: Scan all 
dirs
Dec 18 11:03:31 T14S systemd-backlight[1131]: sd-device-enumerator: Scanning 
/sys/bus
Dec 18 11:03:31 T14S systemd-backlight[1131]: sd-device-enumerator: Scanning 
/sys/class
Dec 18 11:03:31 T14S systemd-backlight[1131]: Using saved brightness 78.
Dec 18 11:03:31 T14S systemd-backlight[1131]: amdgpu_bl0: Failed to write 
system 'brightness' attribute: Invalid argument
Dec 18 11:03:31 T14S systemd[1217]: 
sys-devices-pci:00-:00:08.1-:05:00.0-backlight-amdgpu_bl0.device: 
Changed dead -> plugged
Dec 18 11:03:31 T14S systemd[1217]: 
sys-devices-platform-thinkpad_acpi-leds-tpacpi::kbd_backlight.device: Changed 
dead -> plugged
Dec 18 11:03:37 T14S systemd[3633]: 
sys-devices-pci:00-:00:08.1-:05:00.0-backlight-amdgpu_bl0.device: 
Changed dead -> plugged
Dec 18 11:03:37 T14S systemd[3633]: 
sys-devices-platform-thinkpad_acpi-leds-tpacpi::kbd_backlight.device: Changed 
dead -> plugged

** Attachment added: "journalctl -b with debug-level systemd logging"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1954843/+attachment/5548522/+files/systemd-debug.log

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

Title:
  amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid
  argument

Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  Ubuntu 21.10 does not succeed at setting the display brightness after
  booting (either to the GNOME login screen or to a logged-in user's
  desktop). The brightness is at its highest level until I adjust it
  with keyboard shortcuts or a GUI tool.

  The systemd-backlight@backlight:amdgpu_bl0 service seems to fail
  during startup, but I can subsequently run it after startup and it
  succeeds (and restores brightness):

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  [sudo] password for mdmower: 
  × systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: failed (Result: exit-code) since Tue 2021-12-14 13:26:05 PST; 
30s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 962 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=1/FAILURE)
 Main PID: 962 (code=exited, status=1/FAILURE)
  CPU: 3ms

  Dec 14 13:26:05 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:05 T14S systemd-backlight[962]: amdgpu_bl0: Failed to write 
system 'brightness' attribute: Invalid argument
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Main process exited, 
code=exited, status=1/FAILURE
  Dec 14 13:26:05 T14S systemd[1]: 
systemd-backlight@backlight:amdgpu_bl0.service: Failed with result 'exit-code'.
  Dec 14 13:26:05 T14S systemd[1]: Failed to start Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  mdmower@T14S ~ $ sudo systemctl start systemd-
  backlight@backlight:amdgpu_bl0

  mdmower@T14S ~ $ sudo systemctl status systemd-backlight@backlight:amdgpu_bl0
  ● systemd-backlight@backlight:amdgpu_bl0.service - Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0
   Loaded: loaded (/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Tue 2021-12-14 13:26:45 PST; 1s ago
 Docs: man:systemd-backlight@.service(8)
  Process: 5119 ExecStart=/lib/systemd/systemd-backlight load 
backlight:amdgpu_bl0 (code=exited, status=0/SUCCESS)
 Main PID: 5119 (code=exited, status=0/SUCCESS)
  CPU: 5ms

  Dec 14 13:26:45 T14S systemd[1]: Starting Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0...
  Dec 14 13:26:45 T14S systemd[1]: Finished Load/Save Screen Backlight 
Brightness of backlight:amdgpu_bl0.

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: xorg 1:7.7+22ubuntu2
  ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
  Uname: Linux 5.13.0-22-generic x86_64
  ApportVersion: 2.20.11-0ubuntu71
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop:

[Touch-packages] [Bug 1954724] Re: Removing unattended-upgrades removes ubuntu-server-minimal

2021-12-13 Thread Matthew Ruffell

** Description changed:

  On Impish and later, removing unattended-upgrades also removes ubuntu-
  server-minimal due to ubuntu-server-minimal depending on unattended-
  upgrades
  
  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
-   ubuntu-server-minimal unattended-upgrades
+   ubuntu-server-minimal unattended-upgrades
  0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
  
  This behaviour has changed since ubuntu-meta 1.471 [1] when the ubuntu-
  server-minimal metapackage was introduced, declaring unattended-upgrades
  as Depends.
  
  [1] https://launchpadlibrarian.net/550345392/ubuntu-
  meta_1.470_1.471.diff.gz
  
  On Focal, there was no such behaviour on a fresh ubuntu-server install:
  
  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
-   unattended-upgrades
+   unattended-upgrades
  0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.
  
  Removing unattended-upgrades is quite popular amongst our users, and
  they should be allowed to remove the package without removing the
  ubuntu-server-minimal metapackage.
  
  Looking at the source package for ubuntu-meta, unattended-upgrades is
  only Depends for ubuntu-server-minimal, maybe we should simply remove
- it?
+ it, or instead, change to recommends?
  
  $ grep -Rin "unattended-upgrades" .
  ./server-minimal-armhf:23:unattended-upgrades
  ./server-minimal-riscv64:23:unattended-upgrades
  ./server-minimal-arm64:23:unattended-upgrades
  ./server-minimal-ppc64el:23:unattended-upgrades
  ./server-minimal-s390x:24:unattended-upgrades
  ./server-minimal-amd64:23:unattended-upgrades
  
  $ sudo apt rdepends unattended-upgrades
  unattended-upgrades
  Reverse Depends:
-   Recommends: python3-software-properties
-   Recommends: ubuntu-mate-desktop
-   Recommends: ubuntu-mate-core
-   Depends: freedombox
-   Recommends: fbx-all
-   Depends: ubuntu-server-minimal
+   Recommends: python3-software-properties
+   Recommends: ubuntu-mate-desktop
+   Recommends: ubuntu-mate-core
+   Depends: freedombox
+   Recommends: fbx-all
+   Depends: ubuntu-server-minimal

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

Title:
  Removing unattended-upgrades removes ubuntu-server-minimal

Status in ubuntu-meta package in Ubuntu:
  New
Status in ubuntu-meta source package in Impish:
  New
Status in ubuntu-meta source package in Jammy:
  New

Bug description:
  On Impish and later, removing unattended-upgrades also removes ubuntu-
  server-minimal due to ubuntu-server-minimal depending on unattended-
  upgrades

  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
    ubuntu-server-minimal unattended-upgrades
  0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

  This behaviour has changed since ubuntu-meta 1.471 [1] when the
  ubuntu-server-minimal metapackage was introduced, declaring
  unattended-upgrades as Depends.

  [1] https://launchpadlibrarian.net/550345392/ubuntu-
  meta_1.470_1.471.diff.gz

  On Focal, there was no such behaviour on a fresh ubuntu-server
  install:

  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
    unattended-upgrades
  0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.

  Removing unattended-upgrades is quite popular amongst our users, and
  they should be allowed to remove the package without removing the
  ubuntu-server-minimal metapackage.

  Looking at the source package for ubuntu-meta, unattended-upgrades is
  only Depends for ubuntu-server-minimal, maybe we should simply remove
  it, or instead, change to recommends?

  $ grep -Rin "unattended-upgrades" .
  ./server-minimal-armhf:23:unattended-upgrades
  ./server-minimal-riscv64:23:unattended-upgrades
  ./server-minimal-arm64:23:unattended-upgrades
  ./server-minimal-ppc64el:23:unattended-upgrades
  ./server-minimal-s390x:24:unattended-upgrades
  ./server-minimal-amd64:23:unattended-upgrades

  $ sudo apt rdepends unattended-upgrades
  unattended-upgrades
  Reverse Depends:
    Recommends: python3-software-properties
    Recommends: ubuntu-mate-desktop
    Recommends: ubuntu-mate-core
    Depends: freedombox
    Recommends: fbx-all
    Depends: ubuntu-server-minimal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724/+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 1954724] [NEW] Removing unattended-upgrades removes ubuntu-server-minimal

2021-12-13 Thread Matthew Ruffell

Public bug reported:

On Impish and later, removing unattended-upgrades also removes ubuntu-
server-minimal due to ubuntu-server-minimal depending on unattended-
upgrades

$ sudo apt remove unattended-upgrades
...
The following packages will be REMOVED:
  ubuntu-server-minimal unattended-upgrades
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

This behaviour has changed since ubuntu-meta 1.471 [1] when the ubuntu-
server-minimal metapackage was introduced, declaring unattended-upgrades
as Depends.

[1] https://launchpadlibrarian.net/550345392/ubuntu-
meta_1.470_1.471.diff.gz

On Focal, there was no such behaviour on a fresh ubuntu-server install:

$ sudo apt remove unattended-upgrades
...
The following packages will be REMOVED:
  unattended-upgrades
0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.

Removing unattended-upgrades is quite popular amongst our users, and
they should be allowed to remove the package without removing the
ubuntu-server-minimal metapackage.

Looking at the source package for ubuntu-meta, unattended-upgrades is
only Depends for ubuntu-server-minimal, maybe we should simply remove
it?

$ grep -Rin "unattended-upgrades" .
./server-minimal-armhf:23:unattended-upgrades
./server-minimal-riscv64:23:unattended-upgrades
./server-minimal-arm64:23:unattended-upgrades
./server-minimal-ppc64el:23:unattended-upgrades
./server-minimal-s390x:24:unattended-upgrades
./server-minimal-amd64:23:unattended-upgrades

$ sudo apt rdepends unattended-upgrades
unattended-upgrades
Reverse Depends:
  Recommends: python3-software-properties
  Recommends: ubuntu-mate-desktop
  Recommends: ubuntu-mate-core
  Depends: freedombox
  Recommends: fbx-all
  Depends: ubuntu-server-minimal

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: ubuntu-meta (Ubuntu Impish)
 Importance: Undecided
 Status: New

** Affects: ubuntu-meta (Ubuntu Jammy)
 Importance: Undecided
 Status: New

** Also affects: ubuntu-meta (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Impish)
   Importance: Undecided
   Status: New

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

Title:
  Removing unattended-upgrades removes ubuntu-server-minimal

Status in ubuntu-meta package in Ubuntu:
  New
Status in ubuntu-meta source package in Impish:
  New
Status in ubuntu-meta source package in Jammy:
  New

Bug description:
  On Impish and later, removing unattended-upgrades also removes ubuntu-
  server-minimal due to ubuntu-server-minimal depending on unattended-
  upgrades

  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
ubuntu-server-minimal unattended-upgrades
  0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

  This behaviour has changed since ubuntu-meta 1.471 [1] when the
  ubuntu-server-minimal metapackage was introduced, declaring
  unattended-upgrades as Depends.

  [1] https://launchpadlibrarian.net/550345392/ubuntu-
  meta_1.470_1.471.diff.gz

  On Focal, there was no such behaviour on a fresh ubuntu-server
  install:

  $ sudo apt remove unattended-upgrades
  ...
  The following packages will be REMOVED:
unattended-upgrades
  0 upgraded, 0 newly installed, 1 to remove and 9 not upgraded.

  Removing unattended-upgrades is quite popular amongst our users, and
  they should be allowed to remove the package without removing the
  ubuntu-server-minimal metapackage.

  Looking at the source package for ubuntu-meta, unattended-upgrades is
  only Depends for ubuntu-server-minimal, maybe we should simply remove
  it?

  $ grep -Rin "unattended-upgrades" .
  ./server-minimal-armhf:23:unattended-upgrades
  ./server-minimal-riscv64:23:unattended-upgrades
  ./server-minimal-arm64:23:unattended-upgrades
  ./server-minimal-ppc64el:23:unattended-upgrades
  ./server-minimal-s390x:24:unattended-upgrades
  ./server-minimal-amd64:23:unattended-upgrades

  $ sudo apt rdepends unattended-upgrades
  unattended-upgrades
  Reverse Depends:
Recommends: python3-software-properties
Recommends: ubuntu-mate-desktop
Recommends: ubuntu-mate-core
Depends: freedombox
Recommends: fbx-all
Depends: ubuntu-server-minimal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1954724/+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 1944060] Re: Black Screen after Session Unlock from Suspend

2021-09-22 Thread Matthew Wendel

*** This bug is a duplicate of bug 1911055 ***
https://bugs.launchpad.net/bugs/1911055

This bug was discovered as duplicate - the issue persisted while the P50
was suspended & resumed while in a docking station (probably prime-
select using 'ondemand'). This is GPU driver related.

** This bug has been marked a duplicate of bug 1911055
   [modeset][nvidia] suspend/resume broken in nvidia-460 : Display engine push 
buffer channel allocation failed

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

Title:
  Black Screen after Session Unlock from Suspend

Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  Ubuntu Release: Ubuntu 20.04.3 LTS
  Installation Style: Minimal (selected during GUI install) (Untested against 
full installation style)
  Patient System Hardware Information: Lenovo ThinkPad P50 (Xenon) - Intel HD 
Graphics + NVIDIA Quadro M2000M (NVIDIA Prime enabled w/proprietary drivers) 
(GPU is not suspected to be the issue)

  Expected Behavior:
  1) Suspend the system into sleep mode. 2) Awake the system to be greeted by 
lock screen. 3) Type in password, press enter. 4)GNOME validates password 
successfully. 5) Resume user desktop session.

  Actual Behavior:
  1) Suspend the system into sleep mode. 2) Awake the system to be greeted by 
lock screen. 3) Type in password, press enter. 4)GNOME validates password 
successfully. 5) GNOME lock screen freezes - spinner stops moving but mouse 
cursor and keyboard are responsive (can switch TTYs). After GNOME lock screen 
freeze, if you switch out of TTY2 (default for GUI), and back into it, a black 
screen is shown. If you attempt to login via TTY1, you are switched to the 
black screen session in TTY2.

  Solution / Workaround:
  This behavior can be avoided by installing the "gnome-scrensaver" package. 
Something in this package is required by GNOME in order to successfully resume 
this system from suspend, even though no screen saver settings were configured 
after installing it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1944060/+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 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start

2021-07-13 Thread Matthew Ruffell

Performing verification for Focal.

I will first reproduce the problem with glib2.0 2.64.6-1~ubuntu20.04.3
from -security with the libglib2.0-0 libglib2.0-bin libglib2.0-data
packages.

I deleted all existing schemas from /usr/share/glib-2.0/schemas and
replaced them with a set of schemas which reproduce the problem easily
from my customer.

$ cd /usr/share/glib-2.0/schemas/
$ sudo rm *
$ sudo cp ~/schemas/* .

The gsettings.compiled from the customer has been corrupted, and when I
reboot, gdm fails to start and I get a blank screen with a blinking
insertion pointer.

The sha256 of the customers corrupted gsettings.compiled is:

$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)= 
2c98dc9a7fdbac858a8d5ca7e4dd813f16058a46dba2c54b5239cd8cdba5bb3e

When I ssh back in, and recompile the file:

$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema 
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file 
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can 
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)= 
78163b5fefbd6320ce0d355c9531bf657a4f4dc15f057d95ef144323cd56

The sha256 has changed. Doing a bindiff, I see:

$ sudo cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 4F
3771 A4 C2

We see two bytes different. These bytes are the uninitialised memory
this bug is about. When I reboot, gdm starts fine, but that is because
this time I got lucky and the parser for the gschema.compiled file
thinks 4F and C2 are okay. But there are combinations which aren't okay,
and will end up with a corrupted gschema.compiled file.

Re-compiling the file again:

$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema 
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file 
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can 
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)= 
460c70faca7afc26fa88a0e5918d312478e15f20ad84f4afaa5d17627a823e01

The sha256 changed, and if we bindiff, the bytes have changed:

$ sudo cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 A6
3771 A4 A1

If we run glib-compile-schemas through valgrind, it reports that we are
writing to uninitialised memory:

https://paste.ubuntu.com/p/sxrQtbswpw/

I then enabled -proposed and installed libglib2.0-0 libglib2.0-bin
libglib2.0-data version 2.64.6-1~ubuntu20.04.4.

Now, when I re-compile the gschemas.compiled file, the sha256 matches
every time, meaning no more non-deterministic behaviour caused by
writing unitialised memory to disk:

$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema 
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file 
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can 
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)= 
cd9132d18b596a304251cd1eb50b64aa6fd7511a312906f9a49e1975a319fbf1

$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema 
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file 
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can 
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)= 
cd9132d18b596a304251cd1eb50b64aa6fd7511a312906f9a49e1975a319fbf1

Doing a bindiff, I see the changed bytes from before are now all zeros,
which is what the patch initialises the buffer to:

$ sudo cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 00
3771 A4 00
3772 55 00

Doing a run through valgrind, we no longer get a report about writing to
uninitialised memory:

https://paste.ubuntu.com/p/z52DGZcdz3/

Rebooting, the VM comes up and GDM starts properly, so glib can parse
the gsettings.compiled file without any issues.

Wonderful. The problem is fixed by the package in -proposed, happy to
mark as verified.

** Tags removed: sts-sponsor verification-needed verification-needed-focal
** Tags added:

[Touch-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start

2021-07-11 Thread Matthew Ruffell

Attached is a debdiff for glib2.0 on Focal which fixes this problem.

** Patch added: "Debdiff for glib2.0 for Focal"
   
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1930359/+attachment/5510466/+files/lp1930359_focal.debdiff

** Tags removed: regression-update
** Tags added: sts-sponsor

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

Title:
  glib2.0: Uninitialised memory is written to gschema.compiled, failure
  to parse this file leads to gdm, gnome-shell failing to start

Status in glib2.0 package in Ubuntu:
  Fix Released
Status in glib2.0 source package in Focal:
  In Progress

Bug description:
  [Impact]

  A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
  user with 300 VDIs running Focal, where GNOME applications would fail
  to start, and if you reboot, gdm and gnome-shell both fail to start,
  and you are left with a black screen and a blinking cursor.

  After much investigation, mutter was not at fault. Instead, mutter-
  common calls the libglib2.0-0 hook on upgrade:

  Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
  ...

  This in turn calls glib-compile-schemas to recompile the gsettings
  gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
  result is a binary gschemas.compiled file, which is loaded by
  libglib2.0 on every invocation of a GNOME application, or gdm or
  gnome-shell to fetch application default settings.

  Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
  deterministic behaviour when calling glib-compile-schemas, causing
  generated gschemas.compiled files to have differing contents on each
  run:

  # glib-compile-schemas /usr/share/glib-2.0/schemas
  # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
  376F E3 D0
  3771 A4 DB

  # glib-compile-schemas /usr/share/glib-2.0/schemas
  # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
  376F E3 C3
  3771 A4 98

  # glib-compile-schemas /usr/share/glib-2.0/schemas
  # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
  376F E3 68
  3771 A4 30
  3772 55 56

  The bytes on the left are from a corrupted gschemas.compiled provided
  by an affected user. The changing bytes on the right are non-
  deterministic.

  I ran valgrind over glib-compile-schemas, and found that we are
  writing to uninitialised memory.

  https://paste.ubuntu.com/p/hvZccwdzxz/

  What is happening is that a submodule of glib, gvdb, contains the
  logic for serialising the gschema data structures, and when it
  allocates a buffer to store the eventual gschemas.compiled file, it
  does not initialise it.

  When we populate the fields in the buffer, some bytes are never
  overwritten, and these junk bytes find themselves written to
  gschemas.compiled.

  On boot, when gdm and gnome-shell attempt to parse and load this
  corrupted gschemas.compiled file, it can't parse the junk bytes, and
  raises and error, which propagates up to a breakpoint in glib logging,
  but no debugger is present, so the kernel traps the breakpoint, and
  terminates the library, and the calling application, e.g. gdm.

  The result is that the user is left starting at a black screen with a
  blinking pointer.

  [Testcase]

  On a Focal system, simply run valgrind over glib-compile-schemas:

  # valgrind glib-compile-schemas /usr/share/glib-2.0/schemas

  You will get output like this, with the warning "Syscall param
  write(buf) points to uninitialised byte(s)":

  https://paste.ubuntu.com/p/hvZccwdzxz/

  If you happen to have a large amount of gschema overrides present on
  your system, like my affected user does, you can save a copy of a
  generated gschema.compiled to your home directory and bindiff it
  against recompiles:

  # glib-compile-schemas /usr/share/glib-2.0/schemas
  # cp /usr/share/glib-2.0/schemas/gschema.compiled 
/home/ubuntu/schemas/gschemas.compiled
  # glib-compile-schemas /usr/share/glib-2.0/schemas
  # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
  376F E3 C3
  3771 A4 98

  If you install the test package from the following ppa:

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

  When you run valgrind, it will report a clean run with no writing to
  uninitialised buffers, and all invocations of glib-compile-schemas
  will be deterministic, and generate the file same with the same sha256
  hash every time. The unwritten bytes if you do a

[Touch-packages] [Bug 1930359] Re: gdm fails to start in a VMware Horizon VDI environment with latest mutter 3.36.9-0ubuntu0.20.04.1 in focal-updates

2021-07-11 Thread Matthew Ruffell

** No longer affects: mutter (Ubuntu)

** No longer affects: mutter (Ubuntu Focal)

** Changed in: glib2.0 (Ubuntu)
   Status: New => Fix Released

** Changed in: glib2.0 (Ubuntu Focal)
   Status: New => In Progress

** Changed in: glib2.0 (Ubuntu Focal)
   Importance: Undecided => High

** Summary changed:

- gdm fails to start in a VMware Horizon VDI environment with latest mutter 
3.36.9-0ubuntu0.20.04.1 in focal-updates
+ glib2.0: Uninitialised memory is written to gschema.compiled, failure to 
parse this file leads to gdm, gnome-shell failing to start

** Description changed:

  [Impact]
  
- gdm fails to start in a VMware Horizon VDI environment, with Nvidia GRID
- gpus passed into the VDIs.
+ A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
+ user with 300 VDIs running Focal, where GNOME applications would fail to
+ start, and if you reboot, gdm and gnome-shell both fail to start, and
+ you are left with a black screen and a blinking cursor.
  
- Downgrading mutter from 3.36.9-0ubuntu0.20.04.1 to 3.36.1-3ubuntu3 in
- -release fixes the issue, and the issue does not occur with
- 3.36.7+git20201123-0.20.04.1.
+ After much investigation, mutter was not at fault. Instead, mutter-
+ common calls the libglib2.0-0 hook on upgrade:
  
- Currently looking into what landed in bug 1919143 and bug 1905825.
+ Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3) ...
+ 
+ This in turn calls glib-compile-schemas to recompile the gsettings
+ gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
+ result is a binary gschemas.compiled file, which is loaded by libglib2.0
+ on every invocation of a GNOME application, or gdm or gnome-shell to
+ fetch application default settings.
+ 
+ Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-deterministic
+ behaviour when calling glib-compile-schemas, causing generated
+ gschemas.compiled files to have differing contents on each run:
+ 
+ # glib-compile-schemas /usr/share/glib-2.0/schemas
+ # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
+ 376F E3 D0
+ 3771 A4 DB
+ 
+ # glib-compile-schemas /usr/share/glib-2.0/schemas
+ # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
+ 376F E3 C3
+ 3771 A4 98
+ 
+ # glib-compile-schemas /usr/share/glib-2.0/schemas
+ # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
+ 376F E3 68
+ 3771 A4 30
+ 3772 55 56
+ 
+ The bytes on the left are from a corrupted gschemas.compiled provided by
+ an affected user. The changing bytes on the right are non-deterministic.
+ 
+ I ran valgrind over glib-compile-schemas, and found that we are writing
+ to uninitialised memory.
+ 
+ https://paste.ubuntu.com/p/hvZccwdzxz/
+ 
+ What is happening is that a submodule of glib, gvdb, contains the logic
+ for serialising the gschema data structures, and when it allocates a
+ buffer to store the eventual gschemas.compiled file, it does not
+ initialise it.
+ 
+ When we populate the fields in the buffer, some bytes are never
+ overwritten, and these junk bytes find themselves written to
+ gschemas.compiled.
+ 
+ On boot, when gdm and gnome-shell attempt to parse and load this
+ corrupted gschemas.compiled file, it can't parse the junk bytes, and
+ raises and error, which propagates up to a breakpoint in glib logging,
+ but no debugger is present, so the kernel traps the breakpoint, and
+ terminates the library, and the calling application, e.g. gdm.
+ 
+ The result is that the user is left starting at a black screen with a
+ blinking pointer.
  
  [Testcase]
  
+ On a Focal system, simply run valgrind over glib-compile-schemas:
+ 
+ # valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
+ 
+ You will get output like this, with the warning "Syscall param
+ write(buf) points to uninitialised byte(s)":
+ 
+ https://paste.ubuntu.com/p/hvZccwdzxz/
+ 
+ If you happen to have a large amount of gschema overrides present on
+ your system, like my affected user does, you can save a copy of a
+ generated gschema.compiled to your home directory and bindiff it against
+ recompiles:
+ 
+ # glib-compile-schemas /usr/share/glib-2.0/schemas
+ # cp /usr/share/glib-2.0/schemas/gschema.compiled 
/home/ubuntu/schemas/gschemas.compiled
+ # glib-compile-schemas /usr/share/glib-2.0/schemas
+ # cmp -l /home/ubuntu/schemas/gschemas.compiled 
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X 
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
+ 376F E3 C3
+ 3771 A4 98
+ 
+ If you install the test package from the following ppa:
+ 
+ https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
+ 
+ When you run valgrind, it will

[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix

Performing verification for Groovy

I enabled -proposed and installed libpam-modules libpam-modules-bin
libpam-runtime libpam0g version 1.3.1-5ubuntu6.20.10.1

>From there, I set the pam_faillock configuration in:

/etc/security/faillock.conf:
deny = 3
unlock_time = 120

and also:

/etc/pam.d/common-auth:

# here are the per-package modules (the "Primary" block)
authrequisite   pam_faillock.so preauth
auth[success=1 default=ignore]  pam_unix.so nullok_secure
auth[default=die]   pam_faillock.so authfail
authsufficient  pam_faillock.so authsucc
# here's the fallback if no module succeeds
authrequisite   pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
authrequiredpam_permit.so
# and here are more per-package modules (the "Additional" block)
authoptionalpam_cap.so
# end of pam-auth-update config

>From there, I created a new user "dave", and rebooted the system.

I connected via ssh with the "dave" user and used the wrong password 5 times.
I then tried with the correct password and found the account to be locked.

I waited 2 minutes, and tried again with the correct password, and I was logged
in.

When the account was locked, I logged in as the "ubuntu" user and ran:

$ sudo faillock --user dave
dave:
WhenType  Source   Valid
2021-05-19 02:08:53 RHOST 192.168.122.1V
2021-05-19 02:08:58 RHOST 192.168.122.1V
2021-05-19 02:09:02 RHOST 192.168.122.1V

And I could see the times that "dave" was locked.

I also tested resetting via:

$ sudo faillock --user dave --reset

and "dave" was allowed to log in again.

My tests agree with what Richard sees. Marking as verified for Groovy.

** Tags removed: verification-needed verification-needed-groovy
** Tags added: verification-done verification-done-groovy

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

Title:
  [SRU]pam_tally2 can cause accounts to be locked by correct password.
  pam_faillock use is the recommended fix

Status in pam package in Ubuntu:
  Fix Committed
Status in pam source package in Bionic:
  Fix Committed
Status in pam source package in Focal:
  Fix Committed
Status in pam source package in Groovy:
  Fix Committed
Status in pam source package in Hirsute:
  Fix Committed
Status in pam source package in Impish:
  Fix Committed

Bug description:
  [IMPACT]
  There is a known issue in pam_tally2 which may cause an account to be lock 
down even with correct password, in a busy node environment where simultaneous 
logins takes place (https://github.com/linux-pam/linux-pam/issues/71).

  There are already two customer cases from Canonical clients
  complaining about this behavior (00297697 and 00303806).

  Also, potentially, this will cause further problems in the future,
  since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to
  lock accounts when wrong passwords are used. And both benchmarks - but
  specially STIG - requires use of a lot of audit rules, which can lead
  to the busy node environment.

  The issue impacts all pam_tally2 versions distributed in all currently
  supported Ubuntu versions and also the next unreleased one. Note that,
  according to https://github.com/linux-pam/linux-pam/issues/71, there
  is no plan to fix this issue!

  [FIX]
  This fix proposes to add pam_faillock module to the PAM package, so users of 
pam_tally2 having issues can migrate to pam_faillock. We also plan to modify 
the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but 
in order to do so, we need the pam_faillock module to be available.

  Note that we don't propose to remove pam_tally2, since not every user
  of this module is affected.

  [TEST]
  Tested on a VM installed with Focal server iso and on another with Bionic 
server iso. Enabled pam_faillock module as recommeded by its man page. Then 
tried to log over ssh with an incorrect password, until the account got locked. 
Waited for the configured grace time to unlock and logged in using the correct 
password.

  Note that, since the pam_tally2 issue is caused by a racing condition,
  with a hard to recreate environment (we could not even reproduce it
  with pam_tally2), we could not reproduce the conditions to test
  pam_faillock with.

  [REGRESSION POTENTIAL]
  The regression potential for this is small, since we're not removing the old 
pam_tally2 module, just adding another one. So anyone still using pam_tally2 
will be able to do so.

To manage

[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix

Performing verification for Hirsute

I enabled -proposed and installed libpam-modules libpam-modules-bin
libpam-runtime libpam0g version 1.3.1-5ubuntu6.21.04.1

>From there, I set the pam_faillock configuration in:

/etc/security/faillock.conf:
deny = 3
unlock_time = 120

and also:

/etc/pam.d/common-auth:

# here are the per-package modules (the "Primary" block)
authrequisite   pam_faillock.so preauth
auth[success=1 default=ignore]  pam_unix.so nullok_secure
auth[default=die]   pam_faillock.so authfail
authsufficient  pam_faillock.so authsucc
# here's the fallback if no module succeeds
authrequisite   pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
authrequiredpam_permit.so
# and here are more per-package modules (the "Additional" block)
authoptionalpam_cap.so
# end of pam-auth-update config

>From there, I created a new user "dave", and rebooted the system.

I connected via ssh with the "dave" user and used the wrong password 5 times.
I then tried with the correct password and found the account to be locked.

I waited 2 minutes, and tried again with the correct password, and I was logged
in.

When the account was locked, I logged in as the "ubuntu" user and ran:

$ sudo faillock --user dave
dave:
WhenType  Source   Valid
2021-05-19 01:50:25 RHOST 192.168.122.1V
2021-05-19 01:50:28 RHOST 192.168.122.1V
2021-05-19 01:50:31 RHOST 192.168.122.1V

And I could see the times that "dave" was locked.

I also tested resetting via:

$ sudo faillock --user dave --reset

and "dave" was allowed to log in again.

My tests agree with what Richard sees. Marking as verified for Hirsute.

** Tags removed: verification-needed-hirsute
** Tags added: verification-done-hirsute

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

Title:
  [SRU]pam_tally2 can cause accounts to be locked by correct password.
  pam_faillock use is the recommended fix

Status in pam package in Ubuntu:
  Fix Committed
Status in pam source package in Bionic:
  Fix Committed
Status in pam source package in Focal:
  Fix Committed
Status in pam source package in Groovy:
  Fix Committed
Status in pam source package in Hirsute:
  Fix Committed
Status in pam source package in Impish:
  Fix Committed

Bug description:
  [IMPACT]
  There is a known issue in pam_tally2 which may cause an account to be lock 
down even with correct password, in a busy node environment where simultaneous 
logins takes place (https://github.com/linux-pam/linux-pam/issues/71).

  There are already two customer cases from Canonical clients
  complaining about this behavior (00297697 and 00303806).

  Also, potentially, this will cause further problems in the future,
  since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to
  lock accounts when wrong passwords are used. And both benchmarks - but
  specially STIG - requires use of a lot of audit rules, which can lead
  to the busy node environment.

  The issue impacts all pam_tally2 versions distributed in all currently
  supported Ubuntu versions and also the next unreleased one. Note that,
  according to https://github.com/linux-pam/linux-pam/issues/71, there
  is no plan to fix this issue!

  [FIX]
  This fix proposes to add pam_faillock module to the PAM package, so users of 
pam_tally2 having issues can migrate to pam_faillock. We also plan to modify 
the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but 
in order to do so, we need the pam_faillock module to be available.

  Note that we don't propose to remove pam_tally2, since not every user
  of this module is affected.

  [TEST]
  Tested on a VM installed with Focal server iso and on another with Bionic 
server iso. Enabled pam_faillock module as recommeded by its man page. Then 
tried to log over ssh with an incorrect password, until the account got locked. 
Waited for the configured grace time to unlock and logged in using the correct 
password.

  Note that, since the pam_tally2 issue is caused by a racing condition,
  with a hard to recreate environment (we could not even reproduce it
  with pam_tally2), we could not reproduce the conditions to test
  pam_faillock with.

  [REGRESSION POTENTIAL]
  The regression potential for this is small, since we're not removing the old 
pam_tally2 module, just adding another one. So anyone still using pam_tally2 
will be able to do so.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix

Performing verification for Focal

I enabled -proposed and installed libpam-modules libpam-modules-bin
libpam-runtime libpam0g version 1.3.1-5ubuntu4.2

>From there, I set the pam_faillock configuration in:

/etc/security/faillock.conf:
deny = 3
unlock_time = 120

and also:

/etc/pam.d/common-auth:

# here are the per-package modules (the "Primary" block)
authrequisite   pam_faillock.so preauth
auth[success=1 default=ignore]  pam_unix.so nullok_secure
auth[default=die]   pam_faillock.so authfail
authsufficient  pam_faillock.so authsucc
# here's the fallback if no module succeeds
authrequisite   pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
authrequiredpam_permit.so
# and here are more per-package modules (the "Additional" block)
authoptionalpam_cap.so
# end of pam-auth-update config

>From there, I created a new user "dave", and rebooted the system.

I connected via ssh with the "dave" user and used the wrong password 5 times.
I then tried with the correct password and found the account to be locked.

I waited 2 minutes, and tried again with the correct password, and I was logged
in.

When the account was locked, I logged in as the "ubuntu" user and ran:

$ sudo faillock --user dave
dave:
WhenType  Source   Valid
2021-05-19 00:31:08 RHOST 192.168.122.1V
2021-05-19 00:31:13 RHOST 192.168.122.1V
2021-05-19 00:31:17 RHOST 192.168.122.1V

And I could see the times that "dave" was locked.

I also tested resetting via:

$ sudo faillock --user dave --reset

and "dave" was allowed to log in again.

My tests agree with what Richard sees. Marking 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 Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1927796

Title:
  [SRU]pam_tally2 can cause accounts to be locked by correct password.
  pam_faillock use is the recommended fix

Status in pam package in Ubuntu:
  Fix Committed
Status in pam source package in Bionic:
  Fix Committed
Status in pam source package in Focal:
  Fix Committed
Status in pam source package in Groovy:
  Fix Committed
Status in pam source package in Hirsute:
  Fix Committed
Status in pam source package in Impish:
  Fix Committed

Bug description:
  [IMPACT]
  There is a known issue in pam_tally2 which may cause an account to be lock 
down even with correct password, in a busy node environment where simultaneous 
logins takes place (https://github.com/linux-pam/linux-pam/issues/71).

  There are already two customer cases from Canonical clients
  complaining about this behavior (00297697 and 00303806).

  Also, potentially, this will cause further problems in the future,
  since both STIG benchmarks and CIS benchmarks rely on pam_tally2 to
  lock accounts when wrong passwords are used. And both benchmarks - but
  specially STIG - requires use of a lot of audit rules, which can lead
  to the busy node environment.

  The issue impacts all pam_tally2 versions distributed in all currently
  supported Ubuntu versions and also the next unreleased one. Note that,
  according to https://github.com/linux-pam/linux-pam/issues/71, there
  is no plan to fix this issue!

  [FIX]
  This fix proposes to add pam_faillock module to the PAM package, so users of 
pam_tally2 having issues can migrate to pam_faillock. We also plan to modify 
the current STIG benchmarks to rely on pam_faillock instead of pam_tally2, but 
in order to do so, we need the pam_faillock module to be available.

  Note that we don't propose to remove pam_tally2, since not every user
  of this module is affected.

  [TEST]
  Tested on a VM installed with Focal server iso and on another with Bionic 
server iso. Enabled pam_faillock module as recommeded by its man page. Then 
tried to log over ssh with an incorrect password, until the account got locked. 
Waited for the configured grace time to unlock and logged in using the correct 
password.

  Note that, since the pam_tally2 issue is caused by a racing condition,
  with a hard to recreate environment (we could not even reproduce it
  with pam_tally2), we could not reproduce the conditions to test
  pam_faillock with.

  [REGRESSION POTENTIAL]
  The regression potential for this is small, since we're not removing the old 
pam_tally2 module, just adding another one. So anyone still using pam_tally2 
will be able to do so.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1927796] Re: [SRU]pam_tally2 can cause accounts to be locked by correct password. pam_faillock use is the recommended fix