[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** No longer affects: udisks2 (Ubuntu) ** No longer affects: udisks2 (Ubuntu Bionic) ** No longer affects: udisks2 (Ubuntu Cosmic) ** No longer affects: udisks2 (Ubuntu Disco) ** No longer affects: udisks2 (Ubuntu Eoan) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Committed Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: systemd (Debian) Status: Unknown => New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Committed Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
Hello Dimitri, or anyone else affected, Accepted systemd into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/237-3ubuntu10.22 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: systemd (Ubuntu Bionic) Status: In Progress => Fix Committed ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: Fix Committed Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Committed Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
Hello Dimitri, or anyone else affected, Accepted systemd into disco-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/240-6ubuntu5.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-disco to verification-done-disco. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-disco. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: systemd (Ubuntu Disco) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-disco ** Changed in: systemd (Ubuntu Cosmic) Status: In Progress => Fix Committed ** Tags added: verification-needed-cosmic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: Fix Committed Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: Fix Committed Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Tags removed: ddstreet-next ** Description changed: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. + + -- + sru template for systemd upload: + + [impact] + buffer overflow can cause memory corruption; this is seen in failed autopkgtests + + [test case] + see comment 6 + + [regression potential] + the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. -- sru template for systemd upload: [impact] buffer overflow can cause memory corruption; this is seen in failed autopkgtests [test case] see comment 6 [regression potential] the patch is minimal and clearly correct; however the regression potential is around invalid/corrupted keys read from the keyring. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Committed Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: Fix Committed Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Bug watch added: Debian Bug tracker #929726 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929726 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929726 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: In Progress Status in udisks2 source package in Eoan: Invalid Status in systemd package in Debian: Unknown Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: udisks2 (Ubuntu Cosmic) Status: New => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: In Progress Status in udisks2 source package in Eoan: Invalid Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Also affects: linux (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: udisks2 (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Eoan) Status: New => In Progress ** Changed in: systemd (Ubuntu Eoan) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Disco) Status: New => In Progress ** Changed in: systemd (Ubuntu Disco) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Cosmic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Cosmic) Status: New => In Progress ** Changed in: systemd (Ubuntu Cosmic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Tags added: ddstreet-next -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: In Progress Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in udisks2 source package in Bionic: Invalid Status in linux source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in udisks2 source package in Cosmic: New Status in linux source package in Disco: New Status in systemd source package in Disco: In Progress Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: In Progress Status in udisks2 source package in Eoan: Invalid Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
https://github.com/systemd/systemd/pull/12566 thnx @cascardo! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: Invalid Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: udisks2 (Ubuntu Bionic) Status: New => Invalid ** Changed in: udisks2 (Ubuntu Disco) Status: New => Invalid ** Changed in: udisks2 (Ubuntu Eoan) Status: New => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: Invalid Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: Invalid Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: Invalid Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: Invalid Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
https://lists.freedesktop.org/archives/systemd- devel/2019-May/042570.html -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: udisks2 (Ubuntu Eoan) Importance: Undecided => High -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
After applying the two fixes, I managed to get the test running on a loop for more than 24 hours on disco. Will review the case with someone on the team before attaching the fix. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
It goes back to xenial. I think I found the cause on systemd, will test a fix and report back soon. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Status in linux source package in Bionic: New Status in systemd source package in Bionic: New Status in udisks2 source package in Bionic: New Status in linux source package in Disco: New Status in systemd source package in Disco: New Status in udisks2 source package in Disco: New Status in linux source package in Eoan: Confirmed Status in systemd source package in Eoan: New Status in udisks2 source package in Eoan: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
So, I tested with a 4.18 kernel and I could still reproduce the issue on
eoan. Then, I tested on a bionic system, 4.15 kernel, systemd 237, glibc
2.27, and I see a failure on malloc, also memory corruption.
This appears on the backtrace.
3738malloc_printerr ("malloc(): memory corruption");
I am going back to xenial.
Cascardo.
** Also affects: linux (Ubuntu Eoan)
Importance: Undecided
Status: Confirmed
** Also affects: systemd (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: udisks2 (Ubuntu Eoan)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: udisks2 (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: udisks2 (Ubuntu Bionic)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to udisks2 in Ubuntu.
https://bugs.launchpad.net/bugs/1814373
Title:
storage / luks / dmsetup regressed (or got better) on ppc64le
Status in linux package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
New
Status in udisks2 package in Ubuntu:
New
Status in linux source package in Bionic:
New
Status in systemd source package in Bionic:
New
Status in udisks2 source package in Bionic:
New
Status in linux source package in Disco:
New
Status in systemd source package in Disco:
New
Status in udisks2 source package in Disco:
New
Status in linux source package in Eoan:
Confirmed
Status in systemd source package in Eoan:
New
Status in udisks2 source package in Eoan:
New
Bug description:
in disco proposed with new systemd and v4.19 kernel it appears that
dmsetup / cryptsetup storage either got better or worse.
Devices take very long to activate, and sometimes remain in use during
test clean up.
This leads to udisks autopkgtest failing on ppc64le and systemd's
"storage" autopkgtest is also failing.
I've tried to make ppc64le test more resilient, but it's still odd
that it became unstable in disco, and used to be rock solid on
ppc64le.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
Still need to fix it so it will exit when unit is failed, and maybe
after some timeout.
---
debian/tests/storage | 2 ++
1 file changed, 2 insertions(+)
diff --git a/debian/tests/storage b/debian/tests/storage
index 04d11c8..47fbe81 100755
--- a/debian/tests/storage
+++ b/debian/tests/storage
@@ -73,6 +73,8 @@ class CryptsetupTest(FakeDriveTestBase):
subprocess.call(['umount', self.plaintext_dev],
stderr=subprocess.DEVNULL)
subprocess.call(['systemctl', 'start', '--no-ask-password',
'systemd-cryptsetup@%s.service' % self.plaintext_name],
stderr=subprocess.STDOUT)
+while subprocess.call(['systemctl', 'is-active',
'systemd-cryptsetup@%s.service' % self.plaintext_name],
stderr=subprocess.STDOUT) != 0:
+pass
subprocess.call(['systemctl', 'stop', 'systemd-cryptsetup@%s.service'
% self.plaintext_name],
stderr=subprocess.STDOUT)
if os.path.exists('/etc/crypttab'):
--
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to udisks2 in Ubuntu.
https://bugs.launchpad.net/bugs/1814373
Title:
storage / luks / dmsetup regressed (or got better) on ppc64le
Status in linux package in Ubuntu:
Confirmed
Status in systemd package in Ubuntu:
New
Status in udisks2 package in Ubuntu:
New
Bug description:
in disco proposed with new systemd and v4.19 kernel it appears that
dmsetup / cryptsetup storage either got better or worse.
Devices take very long to activate, and sometimes remain in use during
test clean up.
This leads to udisks autopkgtest failing on ppc64le and systemd's
"storage" autopkgtest is also failing.
I've tried to make ppc64le test more resilient, but it's still odd
that it became unstable in disco, and used to be rock solid on
ppc64le.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
With systemd storage test, I got two different situations: Also on amd64, the test is still flaky, it needs to wait for the unit to be active before stopping it, otherwise it's canceled. I will send a comment with a preview of a fix. On ppc64el, however, even after that fix, the patch will fail once in a while, with /lib/systemd/systemd-cryptsetup crashing on an invalid free. I started investigating that, but still can't figure what the real problem is. Maybe some corruption going on, but really hard to catch when, as running under valgrind doesn't allow the bug to be reproduced. Cascardo. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
got a few more tweaks to the storage test, and it's now more consistently passing on all other architectures but ppc64le. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
Laney got an udisks fix proposed/accepted upstream on https://github.com /storaged-project/udisks/pull/630 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Branch linked: lp:~xnox/britney/udisks2-ppc64el -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1814373] Re: storage / luks / dmsetup regressed (or got better) on ppc64le
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed ** Tags added: bot-stop-nagging ** Package changed: udisks (Ubuntu) => udisks2 (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to udisks2 in Ubuntu. https://bugs.launchpad.net/bugs/1814373 Title: storage / luks / dmsetup regressed (or got better) on ppc64le Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udisks2 package in Ubuntu: New Bug description: in disco proposed with new systemd and v4.19 kernel it appears that dmsetup / cryptsetup storage either got better or worse. Devices take very long to activate, and sometimes remain in use during test clean up. This leads to udisks autopkgtest failing on ppc64le and systemd's "storage" autopkgtest is also failing. I've tried to make ppc64le test more resilient, but it's still odd that it became unstable in disco, and used to be rock solid on ppc64le. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1814373/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
