Bug#1037126: ansible-core: Patch to fix URI Module find json sub type
Am 08.06.23 um 18:37 schrieb Lee Garrett: I acknowledge this bug, and will issue a point release update once it has been merged upstream. Hello Lee, meanwhile, upstream has merged the change also in stable-2.14, see [1]. After successful registering with salsa, I also opened a MR in ansible-core repo [2]. [1] https://github.com/ansible/ansible/pull/80870 [2] https://salsa.debian.org/debian/ansible-core/-/merge_requests/2 Thanks for efforts maintaining ansible in debian! Grüße Berni
Bug#1037126: ansible-core: Patch to fix URI Module find json sub type
Source: ansible-core
Source-Version: 2.14.3-1
Severity: important
Tags: fixed-upstream, patch, upstream
Dear Maintainer,
the attached patch applied in upstream commit [0] will fix ansible-core
2.14.3-1 in Debian 12 Bookworm having an issue with the URI module
recognizing JSON with some API endpoints correctly.
I am using this module in many tasks with the CEPH Dashboard API and
confirm the patch is fixing it successfully. Without the patch, all
these tasks are failing after installing a fresh Debian Bookworm.
Note:
The ansible version in Bullseye was working fine in this regard.
Upstream has an open PR [1] against stable-2.14, but not merged yet.
I would have opened a Merge Request on Salsa, but I just registered and
waiting for approval.
[0]
https://github.com/ansible/ansible/commit/0c7361d9acf7c8966a09f67de2a8679ef86fd856
[1] https://github.com/ansible/ansible/pull/80870
With Best Regards
Berni--- /usr/lib/python3/dist-packages/ansible/modules/uri.py 2023-03-01 21:06:21.0 +0100
+++ /tmp/uri.py 2023-06-03 16:51:49.224330090 +0200
@@ -699,7 +699,14 @@
sub_type = 'octet-stream'
content_encoding = 'utf-8'
-maybe_json = content_type and sub_type.lower() in JSON_CANDIDATES
+if sub_type and '+' in sub_type:
+# https://www.rfc-editor.org/rfc/rfc6839#section-3.1
+sub_type_suffix = sub_type.partition('+')[2]
+maybe_json = content_type and sub_type_suffix.lower() in JSON_CANDIDATES
+elif sub_type:
+maybe_json = content_type and sub_type.lower() in JSON_CANDIDATES
+else:
+maybe_json = False
maybe_output = maybe_json or return_content or info['status'] not in status_code
if maybe_output:
Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them
Paul, Ondřej, you mentioned bug 1004729 which is marked as done. That might be indeed the case for unstable/testing. Unfortunately, this is not the case for the version bind-dyndb-ldap/11.6-3 in bullseye stable after several newer bind9 releases merged into stable with 9.16.27 being the latest. Means, currently, bind-dyndb-ldap is broken in stable. What is the correct way to get this resolved and maintain it like that? For now, I use apt mark of older bind9 9.16.15 as an emergency workaround until a solution is found. Thanks Berni
Bug#961481: ceph: Protocol incompatibility between armhf and amd64
Hello Val, hello Ard, I am not sure, but the issue might be fixed. There is an interesting comment in the upstream changelog [1] of Ceph Pacific v16.2.5: A long-standing bug that prevented 32-bit and 64-bit client/server interoperability under msgr v2 has been fixed. In particular, mixing armv7l (armhf) and x86_64 or aarch64 servers in the same cluster now works. Ceph version 16.2.7 is now in sid/unstable which also passed autopkgtest for armhf. Many Thanks to Thomas, Bernd et al for their work, much appreciated. [1]:https://ceph.com/en/news/blog/2021/v16-2-5-pacific-released/ Best Regards Berni
Bug#961481: ceph: Protocol incompatibility between armhf and amd64
Hello Val, hello Ard, I am not sure, but the issue might be fixed. There is an interesting comment in the upstream changelog [1] of Ceph Pacific v16.2.5: A long-standing bug that prevented 32-bit and 64-bit client/server interoperability under msgr v2 has been fixed. In particular, mixing armv7l (armhf) and x86_64 or aarch64 servers in the same cluster now works. Ceph version 16.2.7 is now in sid/unstable which also passed autopkgtest for armhf. Many Thanks to Thomas, Bernd et al for their work, much appreciated. [1]: https://ceph.com/en/news/blog/2021/v16-2-5-pacific-released/ Best Regards Berni
Bug#964734: reopened / test with 5.12.0-11146-g8ca5297e7e3
Hello Salvatore, Am 17.10.21 um 14:56 schrieb Salvatore Bonaccorso: Is this issue still present with a recent kernel from unstable or bullseye-backports? Yes, unfortunately, I just tested with 5.14.9-2~bpo11+1 and can confirm the same issue. (using "options ddbridge msi=1" still works as a workaround) With Regards Berni
Bug#964734: reopened / test with 5.12.0-11146-g8ca5297e7e3
Hallo Salvatore, Am 02.05.21 um 15:00 schrieb Salvatore Bonaccorso: Reopened until the resolution is clarified upstream. Was there some further progress/clarification from upstream? I just tested with 5.12.0-11146-g8ca5297e7e3 to no avail and reported the result upstream / asked for any update, if available. Other than that, I am not much of any help here, I am afraid. Regards Berni
Bug#964734: reopened
Reopened until the resolution is clarified upstream.
Bug#964734: Confirmed workaround: enable MSI
After enabling MSI within /etc/modprobe.d/ the card is working as expected: options ddbridge msi=1 Upstream bug report has been updated accordingly. Regards Berni
Bug#964734: same problem with newer kernel versions
FTR, the problem stays the same also with newer upstream kernel
versions, tested:
- 5.8.0-rc4
- 5.7.8
It always works with reverted commit b88bf6c3b6ff ("PCI: Add boot
interrupt quirk mechanism for Xeon chipsets")
See more details in the upstream bug report.
Regards
Berni
Bug#964734: Patch to revert bad commit
Tags: patch
Attached is a patch to revert the mentioned commit
It is based on kernel v4.19.131.
From: Berni Turmann
Date: Thu, 9 Jul 2020 13:00:00 +0200
Subject: Revert: PCI: Add boot interrupt quirk mechanism for Xeon chipsets
Fixes: commit d2345d1231d80ecbea5fb764eb43123440861462
("PCI: Add boot interrupt quirk mechanism for Xeon chipsets")
With the above mentioned commit included, the ddbridge module is loading,
but dmesg reports i2c timeouts and the dvb card is not working.
This patch fixes the regression introduced with kernel v4.19.116.
Loading of dvb kernel module ddbridge fails.
Affected Hardware: Supermicro Super Server / X10SDV-TLN4F
CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
Affected DVB adapter: Digital Devices Cine S2 V7 Advanced
Index: linux/drivers/pci/quirks.c
===
--- linux.orig/drivers/pci/quirks.c
+++ linux/drivers/pci/quirks.c
@@ -1947,92 +1947,26 @@ DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_I
/*
* IO-APIC1 on 6300ESB generates boot interrupts, see Intel order no
* 300641-004US, section 5.7.3.
- *
- * Core IO on Xeon E5 1600/2600/4600, see Intel order no 326509-003.
- * Core IO on Xeon E5 v2, see Intel order no 329188-003.
- * Core IO on Xeon E7 v2, see Intel order no 329595-002.
- * Core IO on Xeon E5 v3, see Intel order no 330784-003.
- * Core IO on Xeon E7 v3, see Intel order no 332315-001US.
- * Core IO on Xeon E5 v4, see Intel order no 333810-002US.
- * Core IO on Xeon E7 v4, see Intel order no 332315-001US.
- * Core IO on Xeon D-1500, see Intel order no 332051-001.
- * Core IO on Xeon Scalable, see Intel order no 610950.
*/
-#define INTEL_6300_IOAPIC_ABAR 0x40 /* Bus 0, Dev 29, Func 5 */
+#define INTEL_6300_IOAPIC_ABAR 0x40
#define INTEL_6300_DISABLE_BOOT_IRQ (1<<14)
-#define INTEL_CIPINTRC_CFG_OFFSET 0x14C /* Bus 0, Dev 5, Func 0 */
-#define INTEL_CIPINTRC_DIS_INTX_ICH (1<<25)
-
static void quirk_disable_intel_boot_interrupt(struct pci_dev *dev)
{
u16 pci_config_word;
- u32 pci_config_dword;
if (noioapicquirk)
return;
- switch (dev->device) {
- case PCI_DEVICE_ID_INTEL_ESB_10:
- pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR,
- _config_word);
- pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
- pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR,
- pci_config_word);
- break;
- case 0x3c28: /* Xeon E5 1600/2600/4600 */
- case 0x0e28: /* Xeon E5/E7 V2 */
- case 0x2f28: /* Xeon E5/E7 V3,V4 */
- case 0x6f28: /* Xeon D-1500 */
- case 0x2034: /* Xeon Scalable Family */
- pci_read_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
- _config_dword);
- pci_config_dword |= INTEL_CIPINTRC_DIS_INTX_ICH;
- pci_write_config_dword(dev, INTEL_CIPINTRC_CFG_OFFSET,
- pci_config_dword);
- break;
- default:
- return;
- }
+ pci_read_config_word(dev, INTEL_6300_IOAPIC_ABAR, _config_word);
+ pci_config_word |= INTEL_6300_DISABLE_BOOT_IRQ;
+ pci_write_config_word(dev, INTEL_6300_IOAPIC_ABAR, pci_config_word);
+
pci_info(dev, "disabled boot interrupts on device [%04x:%04x]\n",
dev->vendor, dev->device);
}
-/*
- * Device 29 Func 5 Device IDs of IO-APIC
- * containing ABAR—APIC1 Alternate Base Address Register
- */
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10,
- quirk_disable_intel_boot_interrupt);
-
-/*
- * Device 5 Func 0 Device IDs of Core IO modules/hubs
- * containing Coherent Interface Protocol Interrupt Control
- *
- * Device IDs obtained from volume 2 datasheets of commented
- * families above.
- */
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x3c28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0e28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x6f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2034,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x3c28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x0e28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x6f28,
- quirk_disable_intel_boot_interrupt);
-DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, 0x2034,
- quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
+DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ESB_10, quirk_disable_intel_boot_interrupt);
/* Disable boot interrupts on HT-1000 */
#define BC_HT1000_FEATURE_REG 0x64
Bug#964734: linux-image-4.19.0-9-amd64: [bisected] i2c timeout loading module ddbridge
Package: src:linux Version: 4.19.118-2+deb10u1 Severity: normal Tags: upstream Dear Maintainer, loading kernel module ddbridge fails with i2c timeouts. The dvb media adapter is unusable. This happened after Linux kernel upgrade from 4.19.98-1+deb10u1 to 4.19.118-2+deb10u1. Git bisect based on the Debian kernel repo on branch buster identified as first bad commit: [1fb0eb795661ab9e697c3a053b35aa4dc3b81165] Update to 4.19.116. Git bisect based on upstream Linux kernel repo on branch v4.19.y identified as first bad commit: [d2345d1231d80ecbea5fb764eb43123440861462] PCI: Add boot interrupt quirk mechanism for Xeon chipsets. Other affected Debian kernel version: 5.6.14+2~bpo10+1 I tested this version via buster-backports, because so far I was unable to build my own kernel from 5.6.y or even 5.7.y. Following kernel from buster backports is working OK: linux-image-5.5.0-0.bpo.2-amd64 (5.5.17-1~bpo10+1) Workaround: == Reverting the mentioned commit d2345d1231d80ecbea5fb764eb43123440861462 on top of 4.19.132 is fixing the problem. Reverting the same commit on 4.19.118 or 4.19.116 is also fixing the problem. I already reported upstream: https://bugzilla.kernel.org/show_bug.cgi?id=208507 Thanks and Regards Berni -- Package-specific info: ** Version: Linux version 4.19.0-9-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) ** Command line: BOOT_IMAGE=/vmlinuz-4.19.0-9-amd64 root=/dev/mapper/vg0-root ro intel_iommu=on amd_iommu=on ** Not tainted ** Kernel log: [ 11.504445] device eno3 entered promiscuous mode [ 11.532466] device bond0 entered promiscuous mode [ 11.533970] device eno1 entered promiscuous mode [ 11.535680] device eno4 entered promiscuous mode [ 11.619334] device mgmt0 entered promiscuous mode [ 11.702681] device ceph_cluster entered promiscuous mode [ 11.776108] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 11.776114] ddbridge :05:00.0: DDBridge IRS 00f1 [ 12.800112] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 12.801865] ddbridge :05:00.0: DDBridge IRS 00f1 [ 13.824139] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 13.825849] ddbridge :05:00.0: DDBridge IRS 00f1 [ 14.241947] igb :06:00.1 eno2: igb: eno2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 14.245736] IPv6: ADDRCONF(NETDEV_CHANGE): eno2: link becomes ready [ 14.848109] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 14.849845] ddbridge :05:00.0: DDBridge IRS 00f1 [ 14.909953] igb :06:00.0 eno1: igb: eno1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 14.913760] IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes ready [ 15.872149] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 15.873934] ddbridge :05:00.0: DDBridge IRS 00f1 [ 16.896087] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 16.897888] ddbridge :05:00.0: DDBridge IRS 00f1 [ 17.920092] ddbridge :05:00.0: I2C timeout, card 0, port 0, link 0 [ 17.920167] ddbridge :05:00.0: DDBridge IRS 00f1 [ 17.920222] ddbridge :05:00.0: Port 0: Link 0, Link Port 0 (TAB 1): NO MODULE [ 18.944076] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 18.944151] ddbridge :05:00.0: DDBridge IRS 00f2 [ 18.944205] ddbridge :05:00.0: I2C cmd=00018001 mon=0803004f [ 19.968101] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 19.968174] ddbridge :05:00.0: DDBridge IRS 00f2 [ 19.968228] ddbridge :05:00.0: I2C cmd=00012001 mon=0803001f [ 20.992082] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 20.992154] ddbridge :05:00.0: DDBridge IRS 00f2 [ 20.992209] ddbridge :05:00.0: I2C cmd=0001dc02 mon=0801002f [ 22.016099] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 22.016172] ddbridge :05:00.0: DDBridge IRS 00f2 [ 22.016226] ddbridge :05:00.0: I2C cmd=0001d201 mon=0803002f [ 23.111415] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 23.111487] ddbridge :05:00.0: DDBridge IRS 00f2 [ 23.111541] ddbridge :05:00.0: I2C cmd=0001d001 mon=0803002f [ 24.228517] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 24.228590] ddbridge :05:00.0: DDBridge IRS 00f2 [ 24.228644] ddbridge :05:00.0: I2C cmd=00015203 mon=0802001f [ 25.345584] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 25.345656] ddbridge :05:00.0: DDBridge IRS 00f2 [ 25.345710] ddbridge :05:00.0: I2C cmd=00013c01 mon=0803002f [ 26.407869] ddbridge :05:00.0: I2C timeout, card 0, port 1, link 0 [ 26.407941] ddbridge :05:00.0: DDBridge IRS 00f2 [ 26.407995] ddbridge :05:00.0: I2C cmd=00014001 mon=0803001f [ 26.408055] ddbridge :05:00.0: Port 1: Link 0, Link Port 1 (TAB 2): NO MODULE [
Bug#878299: libvirt: Live migration with qemu not working with copy-storage-xx on stretch
Dear Maintainer, it seems this bug is related to: #878299 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873012 After fixing qemu (by removing two CVE-2017-9524 patches), libvirt 3.0.0-4+deb9u3 is successfully able to migrate including storage. Regards Berni
Bug#873012: not working live migration in qemu / libvirt
Dear Maintainer, during the last days I did some testing around this bug and hope that my findings help to fix it. Root Cause === It looks like the bug is caused by 2 patches in order to fix CVE-2017-9524: - nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch - nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch Both patches were already included in version 2.8+dfsg-6+deb9u1, but not activated yet. This happened in version 2.8+dfsg-6+deb9u2. Versions affected by this bug (broken) === - 2.8+dfsg-6+deb9u2 - 2.8+dfsg-6+deb9u3 - 2.8+dfsg-6+deb9u4 - 2.8+dfsg-6+deb9u5 ... (only the listed versions were tested) Versions not affected (OK): - 2.8+dfsg-6+deb9u1 ... (older versions were not tested) Remark: In the following tests the live migration was executed several times in both directions. Test 1: - git clone https://salsa.debian.org/qemu-team/qemu - checkout tag 2.8+dfsg-6+deb9u1 - rebuild packages without any change - install packages on two Debian Stretch Servers together with libvirt 3.0.0-4+deb9u3 - execute a live migration including storage with following command: # time sudo virsh migrate --live --desturi qemu+ssh://destserver/system --copy-storage-all --persistent --verbose --undefinesource --domain pxe1 => Success Test 2: - checkout tag 2.8+dfsg-6+deb9u2 - disable both CVE-2017-9524 patches - rebuild packages - install packages on two Debian Stretch Servers together with libvirt 3.0.0-4+deb9u3 - execute a live migration including storage with following command: # time sudo virsh migrate --live --desturi qemu+ssh://destserver/system --copy-storage-all --persistent --verbose --undefinesource --domain pxe1 => Success Test 3: - checkout tag 2.8+dfsg-6+deb9u5 - disable both CVE-2017-9524 patches - rebuild packages - install packages on two Debian Stretch Servers together with libvirt 3.0.0-4+deb9u3 - execute a live migration including storage with following command: # time sudo virsh migrate --live --desturi qemu+ssh://destserver/system --copy-storage-all --persistent --verbose --undefinesource --domain pxe1 => Success Conclusion === Obviously, reverting the CVE-2017-9524 patches would just be a quick fix re-opening security issues. I can help testing. Unfortunately, anything else is beyond my capabilities. Regards Berni
