[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
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 1825420] Re: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned
Upgrading a cloud image, I couldn't reproduce it. I also tried installing mate-desktop-environment-core + mate-dock-applet (because it depends on bamfdaemon) before upgrading, and still couldn't reproduce. I will install a cosmic mate desktop and see if I can reproduce this problem when upgrading. However, the dpkg terminal log mentions bamfdaemon and mime-support as possible culprits on the trigger loop. So I am adding these and dpkg as well to the bug. In my opinion, this sounds more like a symptom of some trigger loop not caused by the kernel that causes dpkg to stop, which leaves the kernel unconfigured. ** Also affects: bamf (Ubuntu) Importance: Undecided Status: New ** Also affects: mime-support (Ubuntu) Importance: Undecided Status: New ** Also affects: dpkg (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to bamf in Ubuntu. https://bugs.launchpad.net/bugs/1825420 Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned Status in Ubuntu MATE: New Status in bamf package in Ubuntu: New Status in dpkg package in Ubuntu: New Status in initramfs-tools package in Ubuntu: Confirmed Status in linux package in Ubuntu: In Progress Status in linux-firmware package in Ubuntu: Confirmed Status in mime-support package in Ubuntu: New Bug description: Steps to reproduce: 1. Have Ubuntu 18.10 installed 2. Install all updates to it 3. Switch to Main server 4. Launch update-manager 5. Confirm upgrading to 19.04 6. Wait for upgrade process to finish Expected results: * upgrade process ended without errors Actual results: * upgrade process ended with warning message: Could not install 'linux-image-5.0.0-13-generic' The upgrade will continue but the 'linux-image-5.0.0-13-generic' package may not be in a working state. Please consider submitting a bug report about it. triggers looping, abandoned Workaround: Run recommended `dpkg --configure -a` before actual reboot. System info: running VirtualBox guest with virtualbox-guest-x11 (6.0.6-dfsg-1) inside VirtualBox 5.1.38 host. ProblemType: Package DistroRelease: Ubuntu 19.04 Package: linux-image-5.0.0-13-generic 5.0.0-13.14 ProcVersionSignature: Ubuntu 4.18.0-17.18-generic 4.18.20 Uname: Linux 4.18.0-17-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: mate 1542 F pulseaudio Date: Thu Apr 18 22:56:56 2019 ErrorMessage: triggers looping, abandoned InstallationDate: Installed on 2019-02-17 (60 days ago) InstallationMedia: Ubuntu-MATE 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.2) IwConfig: lono wireless extensions. enp0s3no wireless extensions. Lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 80ee:0021 VirtualBox USB Tablet Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub MachineType: innotek GmbH VirtualBox ProcFB: 0 vboxdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.18.0-17-generic root=UUID=01417e27-d554-4ce8-91bc-1dda8392c976 ro quiet splash PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied No PulseAudio daemon running, or not running as session daemon. Python3Details: /usr/bin/python3.7, Python 3.7.3, python3-minimal, 3.7.3-1 PythonDetails: /usr/bin/python2.7, Python 2.7.16, python-minimal, 2.7.16-1 RelatedPackageVersions: grub-pc 2.02+dfsg1-12ubuntu2 RfKill: SourcePackage: linux StagingDrivers: vboxvideo Title: package linux-image-5.0.0-13-generic 5.0.0-13.14 failed to install/upgrade: triggers looping, abandoned UpgradeStatus: Upgraded to disco on 2019-04-18 (0 days ago) dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1825420/+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 1821863] Re: Need to add Intel CML related pci-id's
** Also affects: mesa (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: libdrm (Ubuntu Disco) Importance: Undecided Status: Fix Released ** Also affects: xorg-server (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: Incomplete ** Also affects: linux-oem (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux-oem (Ubuntu Disco) Status: New => Fix Committed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1821863 Title: Need to add Intel CML related pci-id's Status in libdrm package in Ubuntu: Fix Released Status in linux package in Ubuntu: Incomplete Status in linux-oem package in Ubuntu: Fix Committed Status in mesa package in Ubuntu: New Status in xorg-server package in Ubuntu: New Status in libdrm source package in Bionic: New Status in linux source package in Bionic: Invalid Status in linux-oem source package in Bionic: New Status in mesa source package in Bionic: New Status in xorg-server source package in Bionic: New Status in libdrm source package in Disco: Fix Released Status in linux source package in Disco: Incomplete Status in linux-oem source package in Disco: Fix Committed Status in mesa source package in Disco: New Status in xorg-server source package in Disco: New Bug description: [Impact] Please make it happen in the coming oem-kernel as there will be a flood of Intel Comet Lake (CML) platforms that would need it. Thank you. The same is needed for the rest of the stack. CML is basically another iteration of Skylake/Kabylake/Coffee Lake, and doesn't need other changes than pci-id's and support for the PCH (similar to Cannon point, already supported by the kernel). [Test case] Test that i915 graphics works on CML. [Regression potential] None really, these only add a bunch of new pci-id's across the stack. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1821863/+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
