[Touch-packages] [Bug 2077741] Re: No default background set for GNOME-Greeter
Tested version 24.04.5 from https://launchpad.net/ubuntu/+source/ubuntu- settings/24.04.5 Following the first few steps in the testplan https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeInitialSetup I: - Created a 24.04.1 VM and preformed normal installation - Installed ubuntu-settings 24.04.5 - Removed the user created during installation - Rebooted the VM I landed on the Gnome-Initial-Setup session, but now including the wallpaper, fixing my issue. I was able to complete the setup flow as per normal. ** Tags removed: verification-needed-noble ** Tags added: verification-done-noble -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/2077741 Title: No default background set for GNOME-Greeter Status in ubuntu-settings package in Ubuntu: Fix Released Status in ubuntu-settings source package in Noble: Fix Committed Bug description: [ Impact ] While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Gnome-Initial-Setup is currently used on OEM shipped devices to provide a first user setup flow. We plan to also use it for a Raspberry Pi first user flow. We have received lots of feedback that the solid blue background is not in line with the Flutter installer and looks like an error occurred / the wallpaper failed to load. By updating /usr/share/glib-2.0/schemas/10_ubuntu- settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 and the OEMs ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS [ Test Plan ] To test this change, you can follow the test plan for Gnome-Initial- Setup up to the point where you have launched the GDM Gnome-Initial- Setup session and Gnome-Initial-Setup has appeared. You should see the default Ubuntu wallpaper, not a solid blue wallpaper, behind Gnome- Initial-Setup. https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeInitialSetup [ Where problems could occur ] If the path to the wallpaper is invalid, the session reverts to its blue background, returning to its current state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+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 2077741] Re: No default background set for GNOME-Greeter
** Description changed: [ Impact ] While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Gnome-Initial-Setup is currently used on OEM shipped devices to provide a first user setup flow. We plan to also use it for a Raspberry Pi first user flow. We have received lots of feedback that the solid blue background is not in line with the Flutter installer and looks like an error occurred / the wallpaper failed to load. By updating /usr/share/glib-2.0/schemas/10_ubuntu- settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 and the OEMs ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS [ Test Plan ] To test this change, you can follow the test plan for Gnome-Initial- Setup up to the point where you have launched the GDM Gnome-Initial- Setup session and Gnome-Initial-Setup has appeared. You should see the default Ubuntu wallpaper, not a solid blue wallpaper, behind Gnome- Initial-Setup. https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeInitialSetup + + + [ Where problems could occur ] + + If the path to the wallpaper is invalid, the session reverts to its blue + background, returning to its current state. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/2077741 Title: No default background set for GNOME-Greeter Status in ubuntu-settings package in Ubuntu: Fix Released Status in ubuntu-settings source package in Noble: Fix Committed Bug description: [ Impact ] While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Gnome-Initial-Setup is currently used on OEM shipped devices to provide a first user setup flow. We plan to also use it for a Raspberry Pi first user flow. We have received lots of feedback that the solid blue background is not in line with the Flutter installer and looks like an error occurred / the wallpaper failed to load. By updating /usr/share/glib-2.0/schemas/10_ubuntu- settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 and the OEMs ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS [ Test Plan ] To test this change, you can follow the test plan for Gnome-Initial- Setup up to the point where you have launched the GDM Gnome-Initial- Setup session and Gnome-Initial-Setup has appeared. You should see the default Ubuntu wallpaper, not a solid blue wallpaper, behind Gnome- Initial-Setup. https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeInitialSetup [ Where problems could occur ] If the path to the wallpaper is invalid, the session reverts to its blue background, returning to its current state. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+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 2077741] Re: No default background set for GNOME-Greeter
** Description changed: + [ Impact ] + While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. - Could we set the background here to the Ubuntu default? By updating - /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override with: + Gnome-Initial-Setup is currently used on OEM shipped devices to provide + a first user setup flow. We plan to also use it for a Raspberry Pi first + user flow. We have received lots of feedback that the solid blue + background is not in line with the Flutter installer and looks like an + error occurred / the wallpaper failed to load. + + By updating /usr/share/glib-2.0/schemas/10_ubuntu- + settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow - for Raspberry Pi we plan to support in 24.10 + for Raspberry Pi we plan to support in 24.10 and the OEMs ubuntu-settings: - Installed: 24.04.3 + Installed: 24.04.3 Ubuntu version: 24.04 LTS + + [ Test Plan ] + + To test this change, you can follow the test plan for Gnome-Initial- + Setup up to the point where you have launched the GDM Gnome-Initial- + Setup session and Gnome-Initial-Setup has appeared. You should see the + default Ubuntu wallpaper, not a solid blue wallpaper, behind Gnome- + Initial-Setup. + + https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeInitialSetup -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/2077741 Title: No default background set for GNOME-Greeter Status in ubuntu-settings package in Ubuntu: Fix Released Status in ubuntu-settings source package in Noble: Fix Committed Bug description: [ Impact ] While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Gnome-Initial-Setup is currently used on OEM shipped devices to provide a first user setup flow. We plan to also use it for a Raspberry Pi first user flow. We have received lots of feedback that the solid blue background is not in line with the Flutter installer and looks like an error occurred / the wallpaper failed to load. By updating /usr/share/glib-2.0/schemas/10_ubuntu- settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 and the OEMs ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS [ Test Plan ] To test this change, you can follow the test plan for Gnome-Initial- Setup up to the point where you have launched the GDM Gnome-Initial- Setup session and Gnome-Initial-Setup has appeared. You should see the default Ubuntu wallpaper, not a solid blue wallpaper, behind Gnome- Initial-Setup. https://wiki.ubuntu.com/DesktopTeam/TestPlans/GnomeInitialSetup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, Yes, we are still planning to get this released for focal. To be able to release, it needs to pass all of its autopkgtests. If you have a look here: https://ubuntu-archive-team.ubuntu.com/proposed- migration/focal/update_excuses.html#e2fsprogs Its failing on a few of them for some architectures. I probably need to retry them a few times. I don't have permissions to trigger the tests though, so I will ask around. I'll try get the update released soon. I do understand this has been in the works for a very long time, sorry about that. Thanks, Matthew -- 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Released Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Released Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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 2077741] Re: No default background set for GNOME-Greeter
** Changed in: ubuntu-settings (Ubuntu) Milestone: None => ubuntu-24.10 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/2077741 Title: No default background set for GNOME-Greeter Status in ubuntu-settings package in Ubuntu: New Bug description: While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Could we set the background here to the Ubuntu default? By updating /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+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 2077741] [NEW] No default background set for GNOME-Greeter
Public bug reported: While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Could we set the background here to the Ubuntu default? By updating /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS ** Affects: ubuntu-settings (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-settings in Ubuntu. https://bugs.launchpad.net/bugs/2077741 Title: No default background set for GNOME-Greeter Status in ubuntu-settings package in Ubuntu: New Bug description: While using Gnome-Initial-Setup launched from GDM (when no user > 1000 is present on the machine), no background is set on GNOME-Greeter, leading to a solid blue background wallpaper. Could we set the background here to the Ubuntu default? By updating /usr/share/glib-2.0/schemas/10_ubuntu-settings.gschema.override with: ``` # for GDM/DM # FIXME: move to :Ubuntu-Greeter once upstream supports this, see LP: #1788 [org.gnome.desktop.interface:GNOME-Greeter] gtk-theme = 'Yaru' icon-theme = 'Yaru' cursor-theme = 'Yaru' font-name = 'Ubuntu 11' monospace-font-name = 'Ubuntu Mono 13' font-antialiasing = 'rgba' [org.gnome.login-screen] logo='/usr/share/plymouth/ubuntu-logo.png' + [org.gnome.desktop.background:GNOME-Greeter] + picture-uri = 'file:///usr/share/backgrounds/warty-final-ubuntu.png' + picture-uri-dark = 'file:///usr/share/backgrounds/ubuntu-wallpaper-d.png' + show-desktop-icons = false ``` I was able to add in one. This will help improve the GIS installer flow for Raspberry Pi we plan to support in 24.10 ubuntu-settings: Installed: 24.04.3 Ubuntu version: 24.04 LTS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-settings/+bug/2077741/+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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Performing verification for Jammy. So, I had forgotten all about these instances, so let's check them now. The instance with -updates: It failed with: + resize2fs /dev/nvme1n1p1 resize2fs 1.46.5 (30-Dec-2021) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. the timestamp is Thu Aug 1 06:59:14 UTC 2024 I started it on... Thu Aug 1 06:02:48 UTC 2024 58 minutes! I was expecting a couple of days for Jammy -updates to be honest. I really should have checked earlier. So we can reproduce the issue. I then logged into the -proposed instance, with resize2fs 1.46.5-2ubuntu1.2: It is still running, as of Mon Aug 12 10:54:06 UTC 2024. This is fantastic. It survived 11 days and 5 hours in the high EBS traffic us-west-2. The package in -proposed fixes the issue. Happy to mark verified for Jammy. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Committed Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Committed Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Performing verification for Noble. So, I had forgotten all about these instances, so let's check them now. The instance with -updates: It failed with: + resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. the timestamp is Wed Aug 7 06:42:15 UTC 2024 I started it on... Thu Aug 1 05:46:34 UTC 2024 Okay, this is better than Focal, we lasted 6 days 1 hour. So we can reproduce the issue. I then logged into the -proposed instance, with resize2fs 1.47.0-2.4~exp1ubuntu4.1: It is still running, as of Mon Aug 12 10:49:00 UTC 2024. This is fantastic. It survived 11 days and 5 hours in the high EBS traffic us-west-2. I have terminated the instances now. The package in -proposed fixes the issue. Happy to mark verified for Noble. ** Tags removed: verification-needed-noble ** Tags added: verification-done-noble -- 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Committed Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Committed Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Performing verification for Focal. So, I had forgotten all about these instances, so let's check them now. The instance with -updates: It failed with: + resize2fs /dev/nvme1n1p1 resize2fs 1.45.5 (07-Jan-2020) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. the timestamp is Thu Aug 1 05:57:54 UTC 2024 I started it on... Thu Aug 1 05:46:34 UTC 2024 What! It only lasted 11 minutes! I should have checked on it earlier... So we can reproduce the issue. I then logged into the -proposed instance, with resize2fs 1.45.5-2ubuntu1.2: It is still running, as of Mon Aug 12 10:41:35 UTC 2024. This is fantastic. It survived 11 days and 5 hours in the high EBS traffic us-west-2. I have terminated these instances now. The package in -proposed fixes the issue. Happy to mark 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 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Committed Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Committed Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Beginning verification for noble I started two c5.large instances on us-west-2 on AWS, the same parameters that we used in previous tests. Each has a 60gb GP3 volume attached to it. Each instance is running the GA kernel, 6.8.0-1012-aws. One is -updates, the other is e2fsprogs from -proposed: -updates: $ apt-cache policy e2fsprogs | grep Installed Installed: 1.47.0-2.4~exp1ubuntu4 -proposed: $ apt-cache policy e2fsprogs | grep Installed Installed: 1.47.0-2.4~exp1ubuntu4.1 Each is running the same script from the testcase. I will leave these instances running for the next 7-14 days. We will consider this bug verified if the -updates instance is broken, and the -proposed instance still functioning correctly at the end of this time. The timestamp of starting both tests is: Thu Aug 1 06:10:40 UTC 2024 -- 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Committed Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Committed Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Beginning verification for jammy I started two c5.large instances on us-west-2 on AWS, the same parameters that we used in previous tests. Each has a 60gb GP3 volume attached to it. I downgraded the HWE kernels down to GA kernels, and each is running 5.15.0-1066-aws. One is -updates, the other is e2fsprogs from -proposed: -updates: $ apt-cache policy e2fsprogs | grep Installed Installed: 1.46.5-2ubuntu1.1 -proposed: $ apt-cache policy e2fsprogs | grep Installed Installed: 1.46.5-2ubuntu1.2 Each is running the same script from the testcase. I will leave these instances running for the next 7-14 days. We will consider this bug verified if the -updates instance is broken, and the -proposed instance still functioning correctly at the end of this time. The timestamp of starting both tests is: Thu Aug 1 06:02:48 UTC 2024 -- 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Committed Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Committed Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Beginning verification for focal I started two c5.large instances on us-west-2 on AWS, the same parameters that we used in previous tests. Each has a 60gb GP3 volume attached to it. I downgraded the HWE kernels down to GA kernels, and each is running 5.4.0-1129-aws. One is -updates, the other is e2fsprogs from -proposed: -updates: $ apt-cache policy e2fsprogs | grep Installed Installed: 1.45.5-2ubuntu1.1 -proposed: $ apt-cache policy e2fsprogs | grep Installed Installed: 1.45.5-2ubuntu1.2 Each is running the same script from the testcase. I will leave these instances running for the next 7-14 days. We will consider this bug verified if the -updates instance is broken, and the -proposed instance still functioning correctly at the end of this time. The timestamp of starting both tests is: Thu Aug 1 05:46:34 UTC 2024 -- 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: Fix Released Status in e2fsprogs source package in Trusty: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix Status in e2fsprogs source package in Focal: Fix Committed Status in e2fsprogs source package in Jammy: Fix Committed Status in e2fsprogs source package in Lunar: Won't Fix Status in e2fsprogs source package in Mantic: Won't Fix Status in e2fsprogs source package in Noble: Fix Committed Status in e2fsprogs source package in Oracular: Fix Released 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Attached is a V2 patch for Noble for e2fsprogs. ** Patch added: "Debdiff for e2fsprogs on noble V2" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5772258/+files/lp2036467_noble_V2.debdiff ** Patch removed: "Debdiff for e2fsprogs on noble" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5738302/+files/lp2036467_noble.debdiff ** Patch removed: "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: 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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: Won't Fix Status in e2fsprogs source package in Mantic: In Progress Status in e2fsprogs source package in Noble: 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, Thanks for the heads up about 1.47.1 upstream, it does indeed look like a release is coming soon. It seems Debian unstable already has 1.7.1-rc1: https://packages.debian.org/sid/e2fsprogs When the Ubuntu archive opens for OO, we will merge 1.47.1~rc1-1 from debian unstable, and then submit the patches for SRU to noble, mantic, jammy and focal. Should be a few days. Thanks, Matthew -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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: Won't Fix Status in e2fsprogs source package in Mantic: In Progress Status in e2fsprogs source package in Noble: 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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 1949723] Re: systemd-resolved segfault in hashmap_iterate_entry
** Changed in: systemd (Ubuntu Focal) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Importance: Low => Medium ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Matthew Ruffell (mruffell) ** Tags added: 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/1949723 Title: systemd-resolved segfault in hashmap_iterate_entry Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: installed libnss-resolve that put "resolve" in nsswitch.conf. $ lsb_release -rd Description: Ubuntu 20.04.3 LTS Release: 20.04 $ dpkg -l systemd | grep systemd ii systemd245.4-4ubuntu3.13 amd64system and service manager $ grep ^hosts /etc/nsswitch.conf hosts: files libvirt mdns4_minimal resolve [NOTFOUND=return] dns mymachines systemd-resolved crashed once with segmentation fault. (gdb) bt #0 0x7f119c67693a in hashmap_iterate_entry (h=h@entry=0x706f746b73656465, i=i@entry=0x7ffc4ef515d0) at ../src/basic/hashmap.c:705 #1 0x7f119c6789d6 in internal_hashmap_iterate (h=0x706f746b73656465, i=i@entry=0x7ffc4ef515d0, value=value@entry=0x7ffc4ef515c8, key=key@entry=0x0) at ../src/basic/hashmap.c:714 #2 0x7f119c678a8b in set_iterate (s=, i=i@entry=0x7ffc4ef515d0, value=value@entry=0x7ffc4ef515c8) at ../src/basic/hashmap.c:735 #3 0x55ba5e0ea917 in dns_query_candidate_go (c=c@entry=0x55ba5f353180) at ../src/resolve/resolved-dns-query.c:152 #4 0x55ba5e0e9f0c in dns_query_candidate_notify (c=c@entry=0x55ba5f353180) at ../src/resolve/resolved-dns-query.c:312 #5 0x55ba5e0ea178 in dns_transaction_complete (t=0x55ba5f37a9d0, state=) at ../src/resolve/resolved-dns-transaction.c:351 #6 0x55ba5e0e27cd in dns_transaction_process_dnssec (t=t@entry=0x55ba5f37a9d0) at ../src/resolve/resolved-dns-transaction.c:838 #7 0x55ba5e0e3649 in dns_transaction_process_reply (t=t@entry=0x55ba5f37a9d0, p=p@entry=0x55ba5f39dce0) at ../src/resolve/resolved-dns-transaction.c:1210 #8 0x55ba5e0e40ab in on_dns_packet (s=, fd=, revents=, userdata=0x55ba5f37a9d0) at ../src/resolve/resolved-dns-transaction.c:1264 #9 0x7f119c5e6c77 in source_dispatch (s=s@entry=0x55ba5f346780) at ../src/libsystemd/sd-event/sd-event.c:3193 #10 0x7f119c5e6f11 in sd_event_dispatch (e=e@entry=0x55ba5f320430) at ../src/libsystemd/sd-event/sd-event.c:3634 #11 0x7f119c5e8948 in sd_event_run (e=e@entry=0x55ba5f320430, timeout=timeout@entry=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3692 #12 0x7f119c5e8b6f in sd_event_loop (e=0x55ba5f320430) at ../src/libsystemd/sd-event/sd-event.c:3714 #13 0x55ba5e0c326a in run (argv=, argc=) at ../src/resolve/resolved.c:84 #14 main (argc=, argv=) at ../src/resolve/resolved.c:91 This seems to have been reported upstream https://github.com/systemd/systemd/issues/16168 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949723/+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 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Thank you for the help sorting autopkgtests Mauricio. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released Bug description: [Impact] Issuing a 'ls -l' or a 'stat' on an autofs share when you have set --ghost in the auto.master file, or browse_mode=yes in autofs.conf will lead to the shares being mounted, when they didn't previously. Disks / shares may not be present and the mounts may fail, leading to errors in your output. This is a behaviour change in autofs 8.32, which occurred in the transition to using statx() instead of stat()/lstat() in previous releases. There doesn't seem to be any workarounds, apart from not running a 'ls -l' in your autofs share directory. [Testcase] Start two Jammy VMs. One will be a NFS server, the other, the client. NFS server: Server VM: $ sudo hostnamectl set-hostname jammy-nfs-server $ sudo apt update && sudo apt upgrade -y $ sudo apt install nfs-kernel-server $ sudo mkdir /export $ sudo mkdir /export/users $ sudo vi /etc/exports # add the following lines: /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ sudo systemctl restart nfs-server.service AutoFS Client: $ sudo apt update $ sudo apt install autofs $ sudo vim /etc/autofs.conf browse_mode = yes $ sudo mkdir /mnt2 $ sudo vim /etc/auto.master /mnt2 /etc/auto.indirect $ sudo vim /etc/auto.indirect export 192.168.122.18:/export export-missing 192.168.122.18:/export-missing $ sudo reboot $ cd /mnt2 $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Feb 12 21:48 export d? ? ?? ?? export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) We see the mount for export occurred, and export-missing was attempted, but it was either bogus or the disk was not present, leading to a "No such file or directory" error. There are test packages available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test If you install them, this is what should occur: $ ls -l total 0 drwxr-xr-x 2 root root 0 Feb 12 22:01 export drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) No mounts happen, and no errors either. [Where problems could occur] We are changing the behaviour of core utilities, ls and stat, such that they no longer attempt to mount autofs shares when --ghost option is present or browse_mode is enabled. This is the intended behaviour in the first place, and has been this way for at least a decade prior, and was changed to return to this behaviour shortly after the release of coreutils that introduced statx() that caused automounts to occur. It is unlikely any system administrators are relying on the behaviour found in jammy in any scripts or day to day operations that would be adversely affected by the change. The worst case scenario is that a user doing an 'ls -l' on an unmounted disk finds the mount doesn't automatically occur, and they have to attach the disk and issue the mount themselves. If a regression were to occur, it would be limited to the ls and stat commands, specifically when listing directories linked to autofs mountpoints. [Other info] The automount behaviour change was introduced upstream in version 8.32, with the introduction of the statx() call. This means only Jammy is affected. It was quickly reverted back to how it was originally in version 9.1, which is already available in Mantic and onward. The commits that solve the issue are: commit 85c975df2c25bd799370b04bb294e568e001102f From: Rohan Sable Date: Mon, 7 Mar 2022 14:14:13 + Subject: ls: avoid triggering automounts Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 commit 92cb8427c537f37edd43c5cef1909585201372ab From: Pádraig Brady Date: Mon, 7 Mar 2022 23:29:20 + Subject: stat: only automount with --cach
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Performing verification for Jammy I set up two Jammy VMs, one a nfs-server and the other an autofs/nfs- client. The client is using coreutils 8.32-4.1ubuntu1.1 from -updates. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.1 I set up the nfs server and autofs mounts as the Testcase indicates. $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Mar 20 22:16 export d? ? ?? ?? export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=692,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21588) 192.168.122.65:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.65,mountvers=3,mountport=47718,mountproto=udp,local_lock=none,addr=192.168.122.65) The mounts were previously unmounted, but when I issue 'ls -l', the mounts occur, which is not wanted, and we error out on the non-existant export-missing mount. I then enabled -proposed, and installed coreutils 8.32-4.1ubuntu1.2. $ apt-cache policy coreutils | grep Installed Installed: 8.32-4.1ubuntu1.2 From there, lets try the 'ls -l': $ ls -l total 0 drwxr-xr-x 2 root root 0 Mar 20 22:25 export drwxr-xr-x 2 root root 0 Mar 20 22:25 export-missing $ mount -l | grep mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=648,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=16856) This time the mounts do not occur, we just get a listing of the possible autofs mounts. We can confirm with 'mount -l' that nothing was actually actioned. The package in -proposed fixes the issues. Happy to mark verified for Jammy. ** Tags removed: verification-needed verification-needed-jammy ** Tags added: verification-done-jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: Fix Committed Status in coreutils package in Fedora: Fix Released Bug description: [Impact] Issuing a 'ls -l' or a 'stat' on an autofs share when you have set --ghost in the auto.master file, or browse_mode=yes in autofs.conf will lead to the shares being mounted, when they didn't previously. Disks / shares may not be present and the mounts may fail, leading to errors in your output. This is a behaviour change in autofs 8.32, which occurred in the transition to using statx() instead of stat()/lstat() in previous releases. There doesn't seem to be any workarounds, apart from not running a 'ls -l' in your autofs share directory. [Testcase] Start two Jammy VMs. One will be a NFS server, the other, the client. NFS server: Server VM: $ sudo hostnamectl set-hostname jammy-nfs-server $ sudo apt update && sudo apt upgrade -y $ sudo apt install nfs-kernel-server $ sudo mkdir /export $ sudo mkdir /export/users $ sudo vi /etc/exports # add the following lines: /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) $ sudo systemctl restart nfs-server.service AutoFS Client: $ sudo apt update $ sudo apt install autofs $ sudo vim /etc/autofs.conf browse_mode = yes $ sudo mkdir /mnt2 $ sudo vim /etc/auto.master /mnt2 /etc/auto.indirect $ sudo vim /etc/auto.indirect export 192.168.122.18:/export export-missing 192.168.122.18:/export-missing $ sudo reboot $ cd /mnt2 $ ls -l ls: cannot access 'export-missing': No such file or directory total 4 drwxr-xr-x 3 root root 4096 Feb 12 21:48 export d? ? ?? ?? export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) We see the mount for export occurred, and export-missing was attempted, but it was either bogus or the disk was not present, leading to a "No such file or directory" error. There are test packages available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test If you install them, this is what should occur: $ ls -l total 0 drwxr-xr-x 2 root root 0 Feb 12 22:01 export drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing $ mount -l | grep /mnt2 /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,
[Touch-packages] [Bug 2044420] Re: gtkpod segfaults when attempting to display songs
Attached is a debdiff for mantic which fixes this issue. ** Patch added: "Debdiff for gtkpod on mantic" https://bugs.launchpad.net/ubuntu/+source/gtkpod/+bug/2044420/+attachment/5757356/+files/lp2044420_mantic.debdiff ** Changed in: glib2.0 (Ubuntu Noble) Status: Triaged => Fix Released ** No longer affects: gtkpod (Ubuntu Noble) -- 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/2044420 Title: gtkpod segfaults when attempting to display songs Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: Triaged Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: Fix Released Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+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 2044420] Re: gtkpod segfaults when attempting to display songs
gtkpod has been removed from debian, and thus removed from noble, so no need to fix there. -- 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/2044420 Title: gtkpod segfaults when attempting to display songs Status in GLib: Fix Released Status in glib2.0 package in Ubuntu: Fix Released Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: Triaged Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: Fix Released Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/glib/+bug/2044420/+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 2054716] Re: package polkitd 124-1 failed to install/upgrade: installed polkitd package post-installation script subprocess returned error exit status 1
I came across this after being offered an upgrade prematurely (which appears to be another bug). Please note #9 in https://answers.launchpad.net/ubuntu/+question/709594 if you are fettling the postinst for polkitd. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/2054716 Title: package polkitd 124-1 failed to install/upgrade: installed polkitd package post-installation script subprocess returned error exit status 1 Status in policykit-1 package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I was working on recreating bug 2054319 and did so by modifying my /etc/apt/sources.list file from jammy to noble and installing polkit and all its dependencies. bdmurray@clean-jammy-amd64:~$ sudo apt-get install gir1.2-polkit-1.0 libpolkit-agent-1-0:amd64 libpolkit-gobject-1-0:amd64 pkexec policykit-1 polkitd Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: linux-headers-6.2.0-26-generic linux-headers-6.2.0-36-generic linux-headers-6.5.0-14-generic linux-hwe-6.2-headers-6.2.0-26 linux-hwe-6.2-headers-6.2.0-36 linux-hwe-6.5-headers-6.5.0-14 linux-image-6.2.0-26-generic linux-image-6.2.0-36-generic linux-image-6.5.0-14-generic linux-modules-6.2.0-26-generic linux-modules-6.2.0-36-generic linux-modules-6.5.0-14-generic linux-modules-extra-6.2.0-26-generic linux-modules-extra-6.2.0-36-generic linux-modules-extra-6.5.0-14-generic Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: libc-bin libc-dev-bin libc-devtools libc6 libc6-dbg libc6-dev libduktape207 libgcrypt20 libglib2.0-0 libglib2.0-bin libnss-systemd libpam-systemd libsystemd-shared libsystemd0 libudev1 libzstd1 locales systemd systemd-dev systemd-oomd systemd-resolved systemd-sysv systemd-timesyncd udev Suggested packages: glibc-doc rng-tools low-memory-monitor polkitd-pkla systemd-container systemd-homed systemd-userdbd systemd-boot libqrencode4 libtss2-rc0 Recommended packages: libnss-nis libnss-nisplus The following NEW packages will be installed: libduktape207 libsystemd-shared systemd-dev systemd-resolved The following packages will be upgraded: gir1.2-polkit-1.0 libc-bin libc-dev-bin libc-devtools libc6 libc6-dbg libc6-dev libgcrypt20 libglib2.0-0 libglib2.0-bin libnss-systemd libpam-systemd libpolkit-agent-1-0 libpolkit-gobject-1-0 libsystemd0 libudev1 libzstd1 locales pkexec policykit-1 polkitd systemd systemd-oomd systemd-sysv systemd-timesyncd udev 26 upgraded, 4 newly installed, 0 to remove and 1407 not upgraded. Need to get 34.9 MB of archives. ProblemType: Package DistroRelease: Ubuntu 22.04 Package: polkitd 124-1 ProcVersionSignature: Ubuntu 6.5.0-18.18~22.04.1-generic 6.5.8 Uname: Linux 6.5.0-18-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail Date: Thu Feb 22 08:46:48 2024 ErrorMessage: installed polkitd package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2023-11-02 (112 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) Python3Details: /usr/bin/python3.10, Python 3.10.12, python3-minimal, 3.10.6-1~22.04 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.21.1ubuntu2.2 apt 2.4.11 SourcePackage: policykit-1 Title: package polkitd 124-1 failed to install/upgrade: installed polkitd package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/2054716/+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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
I have been running the test packages on AWS with the reproducer running for 20 days now, and they are still running great. The change to direct IO really does fix this issue, and my testing has removed any and all concerns of causing a regression. Previously focal wouldn't last more than 20 minutes, and jammy onward, a week. I will get these patches sponsored now. Sorry for the delay Krister. -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
** Description changed: - Release: 22.04.3 LTS - coreutils 8.32-4.1ubuntu1 + [Impact] - ls triggers unwanted mounts of autofs filesystems + Issuing a 'ls -l' or a 'stat' on an autofs share when you have set + --ghost in the auto.master file, or browse_mode=yes in autofs.conf will + lead to the shares being mounted, when they didn't previously. - cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the - AT_NO_AUTOMOUNT flag + Disks / shares may not be present and the mounts may fail, leading to + errors in your output. - This bug is also known (and fixed) at Redhat - https://bugzilla.redhat.com/show_bug.cgi?id=2044981 + This is a behaviour change in autofs 8.32, which occurred in the + transition to using statx() instead of stat()/lstat() in previous + releases. - upstream commits: - https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 - https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 + There doesn't seem to be any workarounds, apart from not running a 'ls + -l' in your autofs share directory. - fedora commit - https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 + [Testcase] + + Start two Jammy VMs. One will be a NFS server, the other, the client. + + NFS server: + + Server VM: + $ sudo hostnamectl set-hostname jammy-nfs-server + $ sudo apt update && sudo apt upgrade -y + $ sudo apt install nfs-kernel-server + $ sudo mkdir /export + $ sudo mkdir /export/users + $ sudo vi /etc/exports # add the following lines: + /export 192.168.122.0/24(rw,fsid=0,no_subtree_check,sync) + /export/users 192.168.122.0/24(rw,nohide,insecure,no_subtree_check,sync) + $ sudo systemctl restart nfs-server.service + + AutoFS Client: + $ sudo apt update + $ sudo apt install autofs + $ sudo vim /etc/autofs.conf + browse_mode = yes + $ sudo mkdir /mnt2 + $ sudo vim /etc/auto.master + /mnt2 /etc/auto.indirect + $ sudo vim /etc/auto.indirect + export 192.168.122.18:/export + export-missing 192.168.122.18:/export-missing + $ sudo reboot + $ cd /mnt2 + $ ls -l + ls: cannot access 'export-missing': No such file or directory + total 4 + drwxr-xr-x 3 root root 4096 Feb 12 21:48 export + d? ? ?? ?? export-missing + $ mount -l | grep /mnt2 + /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=634,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=21561) + 192.168.122.18:/export on /mnt2/export type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.122.18,mountvers=3,mountport=35786,mountproto=udp,local_lock=none,addr=192.168.122.18) + + We see the mount for export occurred, and export-missing was attempted, + but it was either bogus or the disk was not present, leading to a "No + such file or directory" error. + + There are test packages available in the following ppa: + + https://launchpad.net/~mruffell/+archive/ubuntu/sf378489-test + + If you install them, this is what should occur: + + $ ls -l + total 0 + drwxr-xr-x 2 root root 0 Feb 12 22:01 export + drwxr-xr-x 2 root root 0 Feb 12 22:01 export-missing + $ mount -l | grep /mnt2 + /etc/auto.indirect on /mnt2 type autofs (rw,relatime,fd=6,pgrp=636,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=18346) + + No mounts happen, and no errors either. + + [Where problems could occur] + + We are changing the behaviour of core utilities, ls and stat, such that + they no longer attempt to mount autofs shares when --ghost option is + present or browse_mode is enabled. + + This is the intended behaviour in the first place, and has been this way + for at least a decade prior, and was changed to return to this behaviour + shortly after the release of coreutils that introduced statx() that + caused automounts to occur. + + It is unlikely any system administrators are relying on the behaviour + found in jammy in any scripts or day to day operations that would be + adversely affected by the change. The worst case scenario is that a user + doing an 'ls -l' on an unmounted disk finds the mount doesn't + automatically occur, and they have to attach the disk and issue the + mount themselves. + + If a regression were to occur, it would be limited to the ls and stat + commands, specifically when listing directories linked to autofs + mountpoints. + + [Other info] + + The automount behaviour change was introduced upstream in version 8.32, + with the introduction of the statx() call. This means only Jammy is + affected. + + It was quickly reverted back to how it was originally in version 9.1, + which is already available in Mantic and onward. + + The commits that solve the issue are: + + commit 85c975df2c25bd799370b04bb294e568e001102f + From: Rohan Sable + Date: Mon, 7 Mar 2022 14:14:13 + + Subject: ls: avoid triggering automounts + Link: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2
[Touch-packages] [Bug 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
Attached is a debdiff that solves this issue on Jammy. ** Patch added: "Debdiff for coreutils on Jammy" https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+attachment/5745181/+files/lp2033892_jammy.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+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 2033892] Re: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled
** Also affects: coreutils (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: coreutils (Ubuntu Jammy) Status: New => In Progress ** Changed in: coreutils (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: coreutils (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 coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2033892 Title: ls -l triggers mount of autofs shares when --ghost option is present or browse_mode is enabled Status in coreutils package in Ubuntu: Fix Released Status in coreutils source package in Jammy: In Progress Status in coreutils package in Fedora: Fix Released Bug description: Release: 22.04.3 LTS coreutils 8.32-4.1ubuntu1 ls triggers unwanted mounts of autofs filesystems cause: coreutils 8.32.4.1ubuntu1 uses statx which not pass the AT_NO_AUTOMOUNT flag This bug is also known (and fixed) at Redhat https://bugzilla.redhat.com/show_bug.cgi?id=2044981 upstream commits: https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-177-g85c975df2c2 https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v9.0-178-g92cb8427c53 fedora commit https://src.fedoraproject.org/rpms/coreutils/c/d736cafa20f13eeb037a3950bdbb4b63dc39b7e3?branch=f35 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/2033892/+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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, Fascinating. I'm in New Zealand, so I use ap-southeast-2 in Sydney, Australia for all my instances, and I never gave it any thought that this could depend on how busy EBS is on the availability zone. I'll move my instances to us-west-2. Thanks, Matthew -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, I have finally seen this occur in real life with my own two eyes! You are absolutely correct, the 4-retry doesn't seem to be sufficient sometimes. The reproducer works on Focal and previous in about 20 minutes, so its easy to see the issue trigger on Focal. But Focal and previous doesn't retry at all. On Jammy, Mantic and noble, it took about a week straight, but I managed to get it to trigger for each of them. Start Tue Jan 16 01:57:20 UTC 2024 Tue Jan 16 02:18:53 UTC 2024 End Tue Jan 23 20:12:28 UTC 2024 Tue Jan 23 14:32:08 UTC 2024 The 4-retry does help, and helps quite a lot really. Anyway, I upgraded my test environment to the test packages, and I will leave them running for a week. If things look good then, I'll get these patches sponsored for SRU. Sorry for the delay, but I really wanted to see it fail on Jammy, Mantic and Noble before we go patching them. Thanks, Matthew -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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 2051234] [NEW] old version of e2fsck causes issues on boot
Public bug reported: As of writing, the current provided version of e2fsck (provided by e2fsprogs) is 1.46.5 (2021-12-30). The latest version of e2fsck is 1.47.0 (2023-02-05), which I believe contains a few updates to supported features. My older version of fsck failed to run successfully during systemd init after trying to check a partition in my fstab, which caused the whole boot process to fail and it dropping me in a root terminal. Upon manually running `fsck -f /dev/sdxy`, an unsupported FS feature error was thrown. Upon downloading and `make install`ing the latest release's source, I was able to successfully run fsck and further boots completed successfully. OS: 22.04.3 LTS (jammy) ** Affects: e2fsprogs (Ubuntu) Importance: Undecided Status: New -- 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/2051234 Title: old version of e2fsck causes issues on boot Status in e2fsprogs package in Ubuntu: New Bug description: As of writing, the current provided version of e2fsck (provided by e2fsprogs) is 1.46.5 (2021-12-30). The latest version of e2fsck is 1.47.0 (2023-02-05), which I believe contains a few updates to supported features. My older version of fsck failed to run successfully during systemd init after trying to check a partition in my fstab, which caused the whole boot process to fail and it dropping me in a root terminal. Upon manually running `fsck -f /dev/sdxy`, an unsupported FS feature error was thrown. Upon downloading and `make install`ing the latest release's source, I was able to successfully run fsck and further boots completed successfully. OS: 22.04.3 LTS (jammy) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2051234/+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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Hi Krister, I apologise for the delay. The main issue I have been having with testing is that it reproduces significantly faster on some releases than others, and I still haven't managed to reproduce once on some releases. I'll set up some fresh reproducers now, and leave them running. If you want to help test, there are test packages for all releases in: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test Regardless, I'll try move this forwards. Thanks, Matthew -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Attached is a patch for noble that solves this issue. ** Patch added: "Debdiff for e2fsprogs on noble" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5738302/+files/lp2036467_noble.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: 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
Attached is a V2 patch for mantic with a different version number, due to it no longer being the devel release. ** Patch removed: "Debdiff for e2fsprogs on mantic" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5707893/+files/lp2036467_mantic.debdiff ** Patch added: "Debdiff for e2fsprogs on mantic V2" https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2036467/+attachment/5738301/+files/lp2036467_mantic_v2.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: 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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 2044420] Re: gtkpod segfaults when attempting to display songs
Upstream bug: https://gitlab.gnome.org/GNOME/glib/-/issues/3185 ** Bug watch added: gitlab.gnome.org/GNOME/glib/-/issues #3185 https://gitlab.gnome.org/GNOME/glib/-/issues/3185 -- 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/2044420 Title: gtkpod segfaults when attempting to display songs Status in glib2.0 package in Ubuntu: New Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: New Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: New Status in gtkpod source package in Noble: New Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2044420/+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 2044420] Re: gtkpod segfaults when attempting to display songs
** Also affects: glib2.0 (Ubuntu) Importance: Undecided Status: New -- 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/2044420 Title: gtkpod segfaults when attempting to display songs Status in glib2.0 package in Ubuntu: New Status in gtkpod package in Ubuntu: New Status in glib2.0 source package in Mantic: New Status in gtkpod source package in Mantic: New Status in glib2.0 source package in Noble: New Status in gtkpod source package in Noble: New Bug description: Open gtkpod, and select your ipod from the list. If it has more than one screenfull of songs to display in the list, gtkpod will immediately segfault. I haven't found a workaround yet. Broken on Mantic, works on Lunar. Thread 1 "gtkpod" received signal SIGSEGV, Segmentation fault. __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 685 ../string/strxfrm_l.c: No such file or directory. (gdb) bt #0 __GI___wcsxfrm_l (dest=0x0, src=0x0, n=0, l=0x76fff5a0 <_nl_global_locale>) at ../string/strxfrm_l.c:685 #1 0x770c5a5e in g_utf8_collate_key () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x77f852ec in fuzzy_skip_prefix () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #3 0x7fffa80980ca in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #4 0x7fffa80997fd in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #5 0x7fffa8099526 in normal_sort_tab_page_add_track () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #6 0x7fffa809f196 in sorttab_display_select_playlist_cb () at /usr/lib/x86_64-linux-gnu/gtkpod/libsorttab_display.so #7 0x7718d130 in g_closure_invoke () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x771ba4ac in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x771ab9b1 in ??? () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x771abbd6 in g_signal_emit_valist () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x771abc93 in g_signal_emit () at /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x77f67e4b in gtkpod_set_current_playlist () at /lib/x86_64-linux-gnu/libgtkpod.so.1 #13 0x7fffa807cce0 in ??? () at /usr/lib/x86_64-linux-gnu/gtkpod/libplaylist_display.so #14 0x7708ba11 in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x770e746f in ??? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7708c46f in g_main_loop_run () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #17 0x777f61ed in gtk_main () at /lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0xea1f in main () To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2044420/+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 2035385] Re: update-initramfs fails: /usr/share/initramfs-tools/hooks/fuse failed with return 1.
There is a workaround described at https://groups.google.com/g/linux.debian.bugs.dist/c/g1OZeZ_wWAU/m/eE0XZBWoBgAJ copy_exec /sbin/mount.fuse3 /sbin || true However the upstream maintainer should probably address this. Affects the AWS Focal AMI, so a lot of people may be impacted but just not know. -- 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/2035385 Title: update-initramfs fails: /usr/share/initramfs-tools/hooks/fuse failed with return 1. Status in initramfs-tools package in Ubuntu: Incomplete Bug description: The system is not fully updated and gives the following error Setting up initramfs-tools (0.136ubuntu6.7) ... update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools (0.136ubuntu6.7) ... update-initramfs: Generating /boot/initrd.img-5.4.0-162-generic E: /usr/share/initramfs-tools/hooks/fuse failed with return 1. update-initramfs: failed for /boot/initrd.img-5.4.0-162-generic with 1. dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.7 ProcVersionSignature: Ubuntu 5.4.0-162.179-generic 5.4.246 Uname: Linux 5.4.0-162-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.27 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Sep 13 19:39:18 2023 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python3.8, Python 3.8.10, python-is-python3, 3.8.2-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.9 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to focal on 2023-09-13 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2035385/+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 2035385] Re: update-initramfs fails: /usr/share/initramfs-tools/hooks/fuse failed with return 1.
Possibly related to DEBIAN Bug#1022252. -- 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/2035385 Title: update-initramfs fails: /usr/share/initramfs-tools/hooks/fuse failed with return 1. Status in initramfs-tools package in Ubuntu: Incomplete Bug description: The system is not fully updated and gives the following error Setting up initramfs-tools (0.136ubuntu6.7) ... update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools (0.136ubuntu6.7) ... update-initramfs: Generating /boot/initrd.img-5.4.0-162-generic E: /usr/share/initramfs-tools/hooks/fuse failed with return 1. update-initramfs: failed for /boot/initrd.img-5.4.0-162-generic with 1. dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools ProblemType: Package DistroRelease: Ubuntu 20.04 Package: initramfs-tools 0.136ubuntu6.7 ProcVersionSignature: Ubuntu 5.4.0-162.179-generic 5.4.246 Uname: Linux 5.4.0-162-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.27 Architecture: amd64 CasperMD5CheckResult: skip Date: Wed Sep 13 19:39:18 2023 ErrorMessage: installed initramfs-tools package post-installation script subprocess returned error exit status 1 PackageArchitecture: all Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: /usr/bin/python3.8, Python 3.8.10, python-is-python3, 3.8.2-4 RelatedPackageVersions: dpkg 1.19.7ubuntu3.2 apt 2.0.9 SourcePackage: initramfs-tools Title: package initramfs-tools 0.136ubuntu6.7 failed to install/upgrade: installed initramfs-tools package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to focal on 2023-09-13 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2035385/+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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
** Description changed: [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. + $ resize2fs /dev/nvme1n1p1 + resize2fs 1.47.0 (5-Feb-2023) + resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 + Couldn't find valid filesystem superblock. + 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 + #!/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 + 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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: + 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 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 + 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. ** Changed in: e2fsprogs (Ubuntu Bionic) Status: In Progress => Won't Fix -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix Status in e2fsprogs source package in Bionic: Won't Fix 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. $ resize2fs /dev/nvme1n1p1 resize2fs 1.47.0 (5-Feb-2023) resize2fs: Superblock checksum does not match superblock while trying to open /dev/nvme1n1p1 Couldn't find valid filesystem superblock. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
@juliank I'm just doing a little bit more testing for the moment, as I really want to make sure this isn't going to cause any issues in the cloud images. It would be nice to have this bug fixed though, I have seen a few cases related to it over the years. I'll ask my SEG colleagues for help with sponsoring in a day or two. -- 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: Won't Fix Status in e2fsprogs source package in Xenial: Won't Fix 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 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 Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp2036467-test If you install the test packages, the race no longer occurs. [Where problems could occur] 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 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. 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: Resizing cloud-images occasionally fails due to superblock checksum mismatch in resize2fs
** 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 scr
[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
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
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
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_
[Touch-packages] [Bug 1930914] Re: ubuntu-minimal depends on ubuntu-advantage-tools
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
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'
[Touch-packages] [Bug 1987631] Re: Screencast only records one second
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
T for 192.168.42.100 on veth1 to 255.255.255.255 port 67 (xid=0x3b5ed313) + DHCPACK of 192.168.42.100 from 192.168.42.1 (xid=0x13d35e3b) + [Detaching 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
[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received
** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1926139 Title: dhclient: thread concurrency race leads to DHCPOFFER packets not being received Status in bind9-libs package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Invalid Status in bind9-libs source package in Focal: In Progress Status in bind9-libs source package in Jammy: In Progress Bug description: [Impact] Occasionally, during instance boot or machine start-up, dhclient will attempt to acquire a dhcp lease and fail, leaving the instance with no IP address and making it unreachable. This happens about once every 100 reboots on bare metal, or Chris Patterson in comment #2 describes it as affecting between ~0.3% to 2% of deployments on Microsoft Azure. Azure uses dhclient called from cloud-init instead of systemd-networkd, and this is causing issues with larger deployments. The logs of an affected dhclient produce the following: Listening on LPF/enp1s0/52:54:00:1c:d7:00 Sending on LPF/enp1s0/52:54:00:1c:d7:00 Sending on Socket/fallback DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f) DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f) ... (omitting 20 similar lines) ... DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f) DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f) DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f) No DHCPOFFERS received. No working leases in persistent database - sleeping. Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/ Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/ The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER packets being replied to with DHCPOFFER packets, but the got_one() callback is never called, dhclient does not read these DHCPOFFER packets, and continues sending DHCPDISCOVER packets. Once it reaches 25 DHCPDISCOVER packets sent, it gives up. tcpdump: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641810/+files/test.pcap Screenshot of Wireshark: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png This behaviour led several bug reporters to believe it was a kernel issue, with the kernel not pushing DHCPOFFER packets to dhclient. This is not the case, the actual problem is dhclient containing a thread concurrency race condition, and when the race occurs, the read socket is closed prematurely, and dhclient does not read any of the DHCPOFFER replies. The full explanation is in the "Other Info" section, but the fix for this is to change bind9-libs from being built multithreaded, back to single threaded as intended by dhclient maintainers. In Focal and Jammy, isc-dhcp links against bind9 libraries provided in bind9-libs, while in Kinetic onward isc-dhcp has an in-tree bind9 library it uses, which is already configured properly to --disable- threads. Change the Focal and Jammy bind9-libs to --disable-threads and update symbol files to reflect the library is single threaded again. [Testcase] Start a fresh Focal or Jammy instance. Download and set executable test-parallel.sh, and edit some lines: 1) wget https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5593045/+files/test-parallel.sh 2) chmod +x test-parallel.sh 3) vim test-parallel.sh Change iface="enp5s0" to your interface, likely iface="enp1s0". Comment out the line "# cp bionic-dhclient $workdir/dhclient". 4) sudo ./test-parallel.sh After five minutes, if you issue reproduces, you will see "TEST FAILED". You can watch the output with: 5) cat /tmp/dhclient-* | less Next, for instrumented runs, you need to build dhclient from source. 1) sudo apt install build-essential devscripts 2) apt source isc-dhcp 3) sudo apt build-dep isc-dhcp 4) cd isc-dhcp Apply the below patch: https://paste.ubuntu.com/p/hGsssrVyG4/ 5) patch -p1 < ~/patch.patch 6) debuild -b -uc -us 7) cd .. 8) sudo dpkg -i isc-dhcp-client-* 9) sudo ./test-parallel.sh 10) cat /tmp/dhclient-* | less Look for the race, as described in "Other Info", namely: mruffell: registering with socket manager mruffell: callback called mruffell: omapi object is NULL mruffell: omapi object is NULL mruffell: Adding obj to linked list mruffell: Obj added to list The issue has reproduced. If you install the test package from the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf337873-test Instructions to install (on a Focal or Jammy system): 1) sudo add-apt-repository ppa:mruffell/sf337873-te
[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received
Screenshot of wireshark. ** Attachment added: "Screenshot of wireshark" https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png ** Description changed: [Impact] Occasionally, during instance boot or machine start-up, dhclient will attempt to acquire a dhcp lease and fail, leaving the instance with no IP address and making it unreachable. This happens about once every 100 reboots on bare metal, or Chris Patterson in comment #2 describes it as affecting between ~0.3% to 2% of deployments on Microsoft Azure. Azure uses dhclient called from cloud- init instead of systemd-networkd, and this is causing issues with larger deployments. The logs of an affected dhclient produce the following: Listening on LPF/enp1s0/52:54:00:1c:d7:00 Sending on LPF/enp1s0/52:54:00:1c:d7:00 Sending on Socket/fallback DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 3 (xid=0xd222950f) DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 5 (xid=0xd222950f) ... (omitting 20 similar lines) ... DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 13 (xid=0xd222950f) DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 8 (xid=0xd222950f) DHCPDISCOVER on enp1s0 to 255.255.255.255 port 67 interval 6 (xid=0xd222950f) No DHCPOFFERS received. No working leases in persistent database - sleeping. Full log: https://paste.ubuntu.com/p/8yBfw2KR5h/ Log of a working run: https://paste.ubuntu.com/p/N3ZgqrxyQD/ The bizarre thing is when you tcpdump dhclient, we see all DHCPDISOVER packets being replied to with DHCPOFFER packets, but the got_one() callback is never called, dhclient does not read these DHCPOFFER packets, and continues sending DHCPDISCOVER packets. Once it reaches 25 DHCPDISCOVER packets sent, it gives up. - tcpdump: - Screenshot of Wireshark: + tcpdump: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641810/+files/test.pcap + Screenshot of Wireshark: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5641811/+files/Screenshot_2023-01-17-16-14-21_1920x1200%250A1920x1080%250A1920x1080.png This behaviour led several bug reporters to believe it was a kernel issue, with the kernel not pushing DHCPOFFER packets to dhclient. This is not the case, the actual problem is dhclient containing a thread concurrency race condition, and when the race occurs, the read socket is closed prematurely, and dhclient does not read any of the DHCPOFFER replies. The full explanation is in the "Other Info" section, but the fix for this is to change bind9-libs from being built multithreaded, back to single threaded as intended by dhclient maintainers. In Focal and Jammy, isc-dhcp links against bind9 libraries provided in bind9-libs, while in Kinetic onward isc-dhcp has an in-tree bind9 library it uses, which is already configured properly to --disable- threads. Change the Focal and Jammy bind9-libs to --disable-threads and update symbol files to reflect the library is single threaded again. [Testcase] Start a fresh Focal or Jammy instance. Download and set executable test-parallel.sh, and edit some lines: 1) wget https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1926139/+attachment/5593045/+files/test-parallel.sh 2) chmod +x test-parallel.sh 3) vim test-parallel.sh Change iface="enp5s0" to your interface, likely iface="enp1s0". Comment out the line "# cp bionic-dhclient $workdir/dhclient". 4) sudo ./test-parallel.sh After five minutes, if you issue reproduces, you will see "TEST FAILED". You can watch the output with: 5) cat /tmp/dhclient-* | less Next, for instrumented runs, you need to build dhclient from source. 1) sudo apt install build-essential devscripts 2) apt source isc-dhcp 3) sudo apt build-dep isc-dhcp 4) cd isc-dhcp Apply the below patch: https://paste.ubuntu.com/p/hGsssrVyG4/ 5) patch -p1 < ~/patch.patch 6) debuild -b -uc -us 7) cd .. 8) sudo dpkg -i isc-dhcp-client-* 9) sudo ./test-parallel.sh 10) cat /tmp/dhclient-* | less Look for the race, as described in "Other Info", namely: mruffell: registering with socket manager mruffell: callback called mruffell: omapi object is NULL mruffell: omapi object is NULL mruffell: Adding obj to linked list mruffell: Obj added to list The issue has reproduced. If you install the test package from the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf337873-test Instructions to install (on a Focal or Jammy system): 1) sudo add-apt-repository ppa:mruffell/sf337873-test 2) sudo apt update 3) sudo apt install libdns-export1109 libisc-export1105 4) sudo apt-cache policy libisc-export1105 | grep Installed Installed: 1:9.11.16+dfsg-3~ub
[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received
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: O
[Touch-packages] [Bug 1926139] Re: dhclient: thread concurrency race leads to DHCPOFFER packets not being received
** 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
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
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
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
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 install
[Touch-packages] [Bug 1987631] Re: Screencast only records one second
@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 Integrated_Webcam_
[Touch-packages] [Bug 1987631] Re: Screencast only records one second
@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 : https://laun
[Touch-packages] [Bug 1987631] Re: Screencast only records one second
@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
** 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: sysprof
[Touch-packages] [Bug 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort
** 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: linux-azure-tool
[Touch-packages] [Bug 1999104] Re: libunwind causes crashes on arm64
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
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
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
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] 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
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) ... Processing
[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/K5
[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 res
[Touch-packages] [Bug 1988119] Re: Update to systemd 237-3ubuntu10.54 broke dns
** 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
** 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
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 la
[Touch-packages] [Bug 1982885] [NEW] Firefox does not scroll with touch input
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
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!
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
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 d
[Touch-packages] [Bug 1963834] Re: openssl 3.0 - SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED]
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'
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
*** 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
*** 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'
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
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 Unsubscr
[Touch-packages] [Bug 1961542] Re: libsmartcols: Revert back to previous behaviour of non-shell parsable column output (lsblk -P)
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 uti
[Touch-packages] [Bug 1961542] [NEW] libsmartcols: Revert back to previous behaviour of non-shell parsable column output (lsblk -P)
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
[Touch-packages] [Bug 1960863] Re: armv8 paca: poly1305 users see segfaults when pointer authentication in use on AWS Graviton 3 instances
** 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
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
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
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
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 dmi.ec.firmware.re
[Touch-packages] [Bug 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument
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: dmi:bvnLENOVO:bvrR1NET44W(1.14):bd11/08/2021:br1.14:efr1.14:svnLENOVO:pn20XF004WUS:pvrThinkPadT14sGen2a:rvnLENOVO:rn20XF004WUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:
[Touch-packages] [Bug 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument
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 spla
[Touch-packages] [Bug 1958572] [NEW] kernel bug causing screen corruption on AMD GPU
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 ProcVersi
[Touch-packages] [Bug 1954843] Re: amdgpu_bl0: Failed to write system 'brightness' attribute: Invalid argument
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: ubun
[Touch-packages] [Bug 1954724] Re: Removing unattended-upgrades removes ubuntu-server-minimal
** 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
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
*** 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