[Touch-packages] [Bug 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
@Mario Did you had the chance to get the file stats of 10-enP53p0s0.link and to try what Lukas suggested in comment #47? -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition enP50s3832 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition enP50s3832 is not for us (backend 1) **
[Touch-packages] [Bug 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
Since #18829 is now closed upstream: https://github.com/systemd/systemd/pull/18829 this should be SRUed (at least to focal). ** Also affects: isc-dhcp (Ubuntu Impish) Importance: Wishlist Status: Confirmed ** Also affects: systemd (Ubuntu Impish) Importance: High Status: Confirmed ** Also affects: netplan.io (Ubuntu Impish) Importance: Low Status: Confirmed ** Also affects: isc-dhcp (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Hirsute) Importance: Undecided Status: New ** No longer affects: isc-dhcp (Ubuntu Hirsute) ** No longer affects: isc-dhcp (Ubuntu Focal) ** No longer affects: isc-dhcp (Ubuntu Impish) -- 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/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode Status in Ubuntu on IBM z Systems: Incomplete Status in isc-dhcp package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in netplan.io source package in Focal: New Status in systemd source package in Focal: New Status in netplan.io source package in Hirsute: New Status in systemd source package in Hirsute: New Status in netplan.io source package in Impish: Confirmed Status in systemd source package in Impish: Confirmed Bug description: ---Problem Description--- IPs are not getting assigned for Hipersockets in DHCP mode Contact Information = Asha Shekharappa(ashsh...@in.ibm.com) Sankar(sankar...@in.ibm.com) ---uname output--- 52-Ubuntu SMP Thu Sep 10 10:59:04 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Ubuntu 20.04 Netplan with systemd-networkd as renderer Creating ethernet connection on Hipersockets device in DHCP mode fails to assign IPs 1. Configure a Hipersockets device chzdev -e 0.0.8f00 2. Create a .yaml file with the below details network: version: 2 ethernets: enc8f00: dhcp4: yes 3. netplan apply 4. The IP is not assigned as seen below root@M96SANKAR:/etc/netplan# ip a s enc8f00: mtu 32768 qdisc mq state UP group default qlen 1000 link/ether fe:da:af:44:08:02 brd ff:ff:ff:ff:ff:ff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+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 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
Before following Lukas' suggestions could you quickly do a: stat /etc/systemd/network/10-enP53p0s0.link (before deleting this file) since this would give us the creation / modification time and potentially (with some log correlation) this may provide a hint when and why it was created. -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch:
[Touch-packages] [Bug 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
No, I think we cannot gather much more data and logs than we already did. (Except the ude rules themselves, but they will not change with a kernel update.) I am relatively confident that this is not an netplan issue since I verified the files in /run/systemd/network/ and the look good and fit nicely to the yaml. I found a similar upstream issue, checking if this is close enough. I'm gonna reach out to another team and will discuss some potential next steps. So you can (and should) update, since the 5.4.0-74 is a significant update (and incl. the upstream stable patches from v5.4.107 to .114). And please watch out for any behavioral changes regarding the udev rules and the address assignments! -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch:
[Touch-packages] [Bug 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdc0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition enP50s3832 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition enP50s3832 is not for us (backend 1) **
[Touch-packages] [Bug 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) ** Tags added: reverse-proxy-bugzilla s390x -- 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/1931725 Title: initramfs-tools & kernel: use zstd as the default compression method Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: Fix Released Status in linux package in Ubuntu: New Bug description: Turns out that loading is always the slow part in loading initramfs into memory and decompressing it since decompression is always the final 10-20% or so of the task. It therefore makes sense to use a good compressor that shrinks the initramfs as much as possible with little decompression overhead. Benchmarking zstd vs lz4 shows that while zstd can be ~5x slower in decompression, the image size is much smaller with zstd than lz4, and since ~80-90% of the boot time is loading the image it makes sense to use zstd. Attached is a libreoffice spread sheet showing typical load and decompression times for a fairly standard 3.4 GHZ intel box with data for load times for a 5400 RPM, 7200 RPM and SATA SSD drives. The conclusions from the test results (attached) show: 1. Loading time is always significantly slower than decompression time. 2. ZSTD is 5x slower than LZ4 in decompression speed but produces far better compressed images 3. Given that loading time is the major factor in loading + decompression, ZSTD is best for kernel and initramfs boot timings. (Also refer to https://kernel.ubuntu.com/~cking/boot-speed-eoan-5.3 /kernel-compression-method.txt for some raw data on drive load speeds for the same UEFI box I did a couple of years ago). amd64 supports zstd, but s390x does not. Will use this bug to enable zstd support on s390x. Upstream submitted patch https://lore.kernel.org/linux-s390/20210615114150.325080-1-dimitri.led...@canonical.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931725/+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 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
Thanks Mario the output is helpful, especially in combination with the time indices. So udev does not seem to be able to complete the initialization of enP53p0s0.171: " Jun 14 08:12:10 ilabg13.tuc.stglabs.ibm.com systemd-networkd[4102292]: enP53p0s0.171: link pending udev initialization... " Would you mind having a look at: $ ls -l /run/systemd/network/ and share the _entire_ content of this folder? (Especially the files related to 'enP53p0s0', but for comparison reasons ideally all (network interface) files.) I want to compare the content with the config in the netplan yaml file. (That would hopefully allow us to check if then netplan config got properly translated to systemd network files.) On top could you also try to bring up the ip address (again successfully and unsuccessfully) with having the "sudo udevadm --debug monitor --property" active? (also triggering network only like this: 'sudo udevadm trigger --attr-match=subsystem=net') -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. **
[Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code
** Package changed: linux (Ubuntu) => openssl (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: openssl (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => Canonical Foundations Team (canonical-foundations) ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Status: New => Triaged ** Also affects: openssl (Ubuntu Impish) Importance: Undecided Assignee: Canonical Foundations Team (canonical-foundations) Status: New ** Also affects: openssl (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: openssl (Ubuntu Bionic) Importance: Undecided Status: New -- 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/1931994 Title: [Ubuntu 20.04] OpenSSL bugs im s390x AES code Status in Ubuntu on IBM z Systems: Triaged Status in openssl package in Ubuntu: New Status in openssl source package in Bionic: New Status in openssl source package in Focal: New Status in openssl source package in Groovy: New Status in openssl source package in Hirsute: New Status in openssl source package in Impish: New Bug description: Problem description: https://github.com/openssl/openssl/pull/14900 Solution available here: https://github.com/openssl/openssl/commit/dc67210d909b5dd7a50f60a96f36f3f5a891b1c8 Should be applied to all distros where openssl 1.1.1 is included for consistency reason. -> 21.10, 20.04, 18.04. I think not needed for 16.04 anymore To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1931994/+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 1925211] Re: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x
To unblock the SRU process for this bug I'm updating the tag from verification-needed-focal to verification-done-focal, however this ticket does not affect focal and it was never marked as affecting focal (see title and bug description), hence I think this tag should not have occurred here. ** 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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1925211 Title: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Status in linux source package in Hirsute: Fix Released Status in systemd source package in Hirsute: Invalid Status in udev source package in Hirsute: Invalid Bug description: SRU Justification [Impact] Hot removal of disks under kvm on s390 does not result in the kernel removing the block device, which can lead to hung tasks and other issues. [Test Plan] See steps to reproduce the bug in the original description below. To test, execute these steps and confirm that the block device gets removed as expected. [Where problems could occur] The fix is a revert of the changes which introduced this regression. The original commit was a removal of supposedly unused code, but it seems a mistake was made in the logic around unregistering of disks. Reverting the changes could have potential to introduce bugs related to other virt devices, especially if it interacts badly with subsequent driver changes. However, the patch reverted cleanly, and reverting restores the code to the state which has been working well in previous kernels and seems like the lowest risk option until a proper fix is available upstream. --- Repro: #1 Get a guest $ uvt-kvm create --disk 5 --password=ubuntu h release=hirsute arch=s390x label=daily $ uvt-kvm wait h release=hirsute arch=s390x label=daily #2 Attach and Detach disk $ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 10M $ virsh attach-disk h /var/lib/libvirt/images/test.qcow2 vdc $ virsh detach-disk h vdc From libvirts POV it is gone at this point $ virsh domblklist h Target Source -- vda /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs.qcow vdb /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs-ds.qcow But the guest thinks still it is present $ uvt-kvm ssh --insecure hirsute-2nd-zfs lsblk ... vdc252:32 0 20M 0 disk This even remains a while after (not a race). Any access to it in the guest will hang (as you'd expect of a non-existing blockdev) 4 017581739 20 0 12140 4800 - S+ pts/0 0:00 | \_ sudo mkfs.ext4 /dev/vdc 4 017591758 20 0 6924 1044 - D+ pts/0 0:00 | \_ mkfs.ext4 /dev/vdc The result above was originally found with hirsute-guest@hirsute-host on s390x I do NOT see the same with groovy-guest@hirsute-host on s390x I DO see the same with hirsute-guest@groovy-host on s390x => Guest version dependent not Host/Hipervisor dependent I DO see the same with ZFS disks AND LVM disks being added => not type dependent I do NOT see the same on x86. => Arch dependent ?? ... the evidence slowly points towards an issue in the guest, damn we are so close to release - but non-fully detaching disks are critical in my POV :-/ Filing this as-is for awareness, but certainly this will need more debugging. Unsure where this is going to eventually I'll now file it for kernel/udev/systemd. If there are any known issues/components that are related let me know please! --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu65 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 21.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lspci-vt: -[:00]- Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: Package: udev PackageArchitecture: s390x PciMultimedia: ProcFB: ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ProcVersionSignature: User Name 5.11.0-14.15-generic 5.11.12 RelatedPackageVersions:
[Touch-packages] [Bug 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
I should have added that it would be best in this case to have the debug mode enabled for udevd, too: $ cat /etc/systemd/system/systemd-udevd.service.d/override.conf [Service] Environment=SYSTEMD_LOG_LEVEL=debug $ sudo systemctl daemon-reload && sudo systemctl restart systemd-udevd $ journalctl -b -u systemd-networkd -u systemd-udevd --no-pager (instead of -b you may do '--since="today"' and/or '--until="5 minutes ago"' or so to reduce the output) You may then trigger the udev rules directly, like: $ sudo udevadm trigger and once indirectly via netplan (and maybe via 'ip'). -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition ence0f is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition encdb0 is not for us (backend 1) ** (generate:59965): DEBUG: 14:55:15.047: NetworkManager: definition encdb0 is
[Touch-packages] [Bug 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)
Ok, the line that concerns me is: " enP53p0s0.171: link pending udev initialization... " It looks like systemd-networkd thinks that udev is not done with enP53p0s0.171 --> "pending", but configuring it with ip works - so could be networkd or also udevd. So lets expand the journal output with the udev messages and share it again: journalctl -b -u systemd-networkd -u systemd-udevd --no-pager Please can you also share the output of: apt-cache policy systemd udev netplan.io Investigations pointed me to: https://github.com/systemd/systemd/issues/15445#issuecomment-776856604 (changing the interface name at some point could be interesting, too...) Anyway, I'll mark this bug as affecting systemd now. ** Bug watch added: github.com/systemd/systemd/issues #15445 https://github.com/systemd/systemd/issues/15445 ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- 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/1929657 Title: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x) Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: New Status in netplan.io package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: ---Problem Description--- Doing vLAN configuration one of the vLANs is not getting static IP assigned when the rest are workin without problems Contact Information = Mario Alvarado/mario.alberto.gali...@ibm.com ---uname output--- Linux ilabg13.tuc.stglabs.ibm.com 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1)Configure the netplan file as follow: root@ilabg13:~# cat /etc/netplan/01-iscsi-config.yaml # This is the network config written by 'subiquity' network: ethernets: encdb0: addresses: - 11.111.114.213/22 macaddress: 02:76:54:00:00:03 encdc0: addresses: - 11.111.112.213/22 macaddress: 02:76:54:00:00:04 enP50s3832 : addresses: - 11.111.112.214/22 enP53p0s0: addresses: - 11.111.112.215/22 vlans: encdb0.160: id: 160 link: encdb0 mtu: 9000 addresses: - 192.168.160.53/24 encdc0.150: id: 150 link: encdc0 mtu: 9000 addresses: - 192.168.150.53/24 enP50s3832.170: id: 170 link: enP50s3832 mtu: 9000 addresses: - 192.168.170.53/24 enP53p0s0.171: id: 171 link: enP53p0s0 mtu: 9000 addresses: - 192.168.171.53/24 version: 2 2)run net plan apply: root@ilabg13:~# netplan --debug apply ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/00-installer-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: Processing input file /etc/netplan/01-iscsi-config.yaml.. ** (generate:59965): DEBUG: 14:55:15.046: starting new processing pass ** (generate:59965): DEBUG: 14:55:15.046: We have some netdefs, pass them through a final round of validation ** (generate:59965): DEBUG: 14:55:15.046: encdc0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: ence0f: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdb0.160: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0.171: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP50s3832.170: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: enP53p0s0: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.046: encdc0.150: setting default backend to 1 ** (generate:59965): DEBUG: 14:55:15.046: Configuration is valid ** (generate:59965): DEBUG: 14:55:15.047: Generating output files.. ** (generate:59965): DEBUG: 14:55:15.047: openvswitch: definition ence0f is not
[Touch-packages] [Bug 1925211] Re: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x
With that we can close the entire bug, since hirsute / 5.11 is now Fix Released (#34), groovy / 5.8 is not affected (#17) and the patches are upstream with 5.13 (#33), hence will end up sooner or later in impish. ** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released ** Changed in: linux (Ubuntu) Status: Fix Committed => Fix Released -- 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/1925211 Title: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x Status in Ubuntu on IBM z Systems: Fix Released Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Status in linux source package in Hirsute: Fix Released Status in systemd source package in Hirsute: Invalid Status in udev source package in Hirsute: Invalid Bug description: SRU Justification [Impact] Hot removal of disks under kvm on s390 does not result in the kernel removing the block device, which can lead to hung tasks and other issues. [Test Plan] See steps to reproduce the bug in the original description below. To test, execute these steps and confirm that the block device gets removed as expected. [Where problems could occur] The fix is a revert of the changes which introduced this regression. The original commit was a removal of supposedly unused code, but it seems a mistake was made in the logic around unregistering of disks. Reverting the changes could have potential to introduce bugs related to other virt devices, especially if it interacts badly with subsequent driver changes. However, the patch reverted cleanly, and reverting restores the code to the state which has been working well in previous kernels and seems like the lowest risk option until a proper fix is available upstream. --- Repro: #1 Get a guest $ uvt-kvm create --disk 5 --password=ubuntu h release=hirsute arch=s390x label=daily $ uvt-kvm wait h release=hirsute arch=s390x label=daily #2 Attach and Detach disk $ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 10M $ virsh attach-disk h /var/lib/libvirt/images/test.qcow2 vdc $ virsh detach-disk h vdc From libvirts POV it is gone at this point $ virsh domblklist h Target Source -- vda /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs.qcow vdb /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs-ds.qcow But the guest thinks still it is present $ uvt-kvm ssh --insecure hirsute-2nd-zfs lsblk ... vdc252:32 0 20M 0 disk This even remains a while after (not a race). Any access to it in the guest will hang (as you'd expect of a non-existing blockdev) 4 017581739 20 0 12140 4800 - S+ pts/0 0:00 | \_ sudo mkfs.ext4 /dev/vdc 4 017591758 20 0 6924 1044 - D+ pts/0 0:00 | \_ mkfs.ext4 /dev/vdc The result above was originally found with hirsute-guest@hirsute-host on s390x I do NOT see the same with groovy-guest@hirsute-host on s390x I DO see the same with hirsute-guest@groovy-host on s390x => Guest version dependent not Host/Hipervisor dependent I DO see the same with ZFS disks AND LVM disks being added => not type dependent I do NOT see the same on x86. => Arch dependent ?? ... the evidence slowly points towards an issue in the guest, damn we are so close to release - but non-fully detaching disks are critical in my POV :-/ Filing this as-is for awareness, but certainly this will need more debugging. Unsure where this is going to eventually I'll now file it for kernel/udev/systemd. If there are any known issues/components that are related let me know please! --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu65 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 21.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lspci-vt: -[:00]- Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: Package: udev PackageArchitecture: s390x PciMultimedia: ProcFB: ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ProcVersionSignature: User Name 5.11.0-14.15-generic 5.11.12 RelatedPackageVersions:
[Touch-packages] [Bug 1929921] Re: Ubuntu 20.04.2 - OPENSSL_cleanse() fails with segmentation fault in eddsa_test
** Package changed: linux (Ubuntu) => openssl (Ubuntu) -- 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/1929921 Title: Ubuntu 20.04.2 - OPENSSL_cleanse() fails with segmentation fault in eddsa_test Status in Ubuntu on IBM z Systems: Invalid Status in openssl package in Ubuntu: Invalid Bug description: ---Problem Description--- === IBM z15 with D41C Bundle S39a and z/VM 7.2.0 guest with crypto cards attached OS: Ubuntu 20.04.2 (focal fossa) with 5.4.0-73-generic and libica 3.6.1 installed Core dump when running the eddsa_test from libica Details === The available openSSL version is: OpenSSL 1.1.1f 31 Mar 2020 The ibmca engine was installed, but not defined into the openssl.cnf file, openssl engine displayed the default line: (dynamic) Dynamic engine loading support The segmentation fault was generated by `./eddsa_test'. Program terminated with signal SIGSEGV, Segmentation fault in openSSL (gdb) bt #0 0x03ff896e50be in OPENSSL_cleanse () from /lib/s390x-linux-gnu/libcrypto.so.1.1 #1 0x03ff898a26fa in ica_ed25519_ctx_del (ctx=0x3fff9b7e010) at ica_api.c:1897 #2 0x02aa28986f14 in ed25519_stress () at eddsa_test.c:441 #3 0x02aa289831bc in main (argc=0x1, argv=0x3fff9b7eaf8) at eddsa_test.c:66 See https://wiki.ubuntu.com/Debug%20Symbol%20Packages about how to define debug repositories apt install libica3-dbgsym #0 0x03ff896e50be in OPENSSL_cleanse () from /lib/s390x-linux-gnu/libcrypto.so.1.1 (gdb) bt # coredumpctl dump 158582 > eddsa.core PID: 158582 (eddsa_test) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Wed 2021-05-26 19:52:28 CEST (15h ago) Command Line: ./eddsa_test Executable: /root/crypto/libica-3.6.1/test/eddsa_test Control Group: /user.slice/user-0.slice/session-9.scope Unit: session-9.scope Slice: user-0.slice Session: 9 Owner UID: 0 (root) Boot ID: 6a7a23240f464a0d9f2d3fa3e82be73e Machine ID: c933ae494f9a4c6e8d82625c952945d5 Hostname: t3514002.lnxne.boe Storage: /var/lib/systemd/coredump/core.eddsa_test.0.6a7a23240f464a0d9f2d3fa3e82be73e.158582.1622051548.lz4 Message: Process 158582 (eddsa_test) of user 0 dumped core. Stack trace of thread 158582: #0 0x03ff896e50be OPENSSL_cleanse (libcrypto.so.1.1 + 0x1650be) ---uname output--- Linux system 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:29:32 UTC 2021 s390x s390x s390x GNU/Linux Machine Type = Manufacturer: IBM Type: 8561 Model:703 T01 ---Debugger--- A debugger was configured, however the system did not enter into the debugger ---Steps to Reproduce--- 1.) install the github libica 3.6.1 package and build the test cases 2.) cd .../libica-3.6.1 3.) ./bootstrap.sh; configure --enable-coverage 4.) make coverage Watch the segmentation fault to happen Userspace tool common name: eddsa_test The userspace tool has the following bit modes: 64bit Userspace rpm: libica3 Userspace tool obtained from project website: na The problem could be reproduced with libica 3.6.1, however, it does not show up with libica 3.8.0. Looks like the problem was fixed by commit https://github.com/opencryptoki/libica/commit/b40d0d2ad4a2aac088cf47befbddd8b3b9fca1c5 After applying this fix on top of 3.6.1, the segfault does not occur anymore. It's sufficient to apply the 4 changes in eddsa_test.c. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929921/+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 1929825] Re: [Ubuntu 21.04] OSA Device doesn't get enabled if a vlan is specified on the kernel cmdline for the installer
*** This bug is a duplicate of bug 1924794 ***
https://bugs.launchpad.net/bugs/1924794
This is an issue that got already identified and reported (late in the cycle)
during 21.04 testing and is described at LP#1924794 in more detail.
It was unfortunately too late to get it fixed in time for 21.04 GA,
but you will find a fixed initramfs file in LP#1924794 comment #10 that needs
to be used as a replacement for the initfamfs file that is shipped by the ISO
in /boot.
The fix is already included in Impish, too.
Hence I'm marking this LP bug as a duplicate of LP#1924794.
** Changed in: linux (Ubuntu)
Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned)
** Changed in: ubuntu-z-systems
Status: New => Fix Released
** Package changed: linux (Ubuntu) => initramfs-tools (Ubuntu)
** Changed in: initramfs-tools (Ubuntu)
Status: New => Fix Released
** This bug has been marked a duplicate of bug 1924794
Getting error "ipconfig: no devices to configure" while trying to
autoinstall in a VLAN env on s390x
--
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/1929825
Title:
[Ubuntu 21.04] OSA Device doesn't get enabled if a vlan is specified
on the kernel cmdline for the installer
Status in Ubuntu on IBM z Systems:
Fix Released
Status in initramfs-tools package in Ubuntu:
Fix Released
Bug description:
The OSA Device doesn't get enabled if a vlan is specified on the
kernel cmdline for the installer.
with the cmdline
`ip=10.1.8.74::10.1.10.1:255.255.252.0::enc800.300:none nameserver=10.1.9.101
vlan=enc800.300:enc800
url=http://10.1.9.101:1002/iso/ubuntu-21.04-live-server-s390x.iso quiet ---`
the boot fails with this message and drops to a shell:
```
BusyBox v1.30.1 (Ubuntu 1:1.30.1-6ubuntu2) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs) [6n
ip: SIOCGIFFLAGS: No such device
ip: can't find device 'enc800'
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
ipconfig: enc800.300: SIOCGIFINDEX: No such device
ipconfig: no devices to configure
no search or nameservers found in /run/net-enc800.300.conf /run/net-*.conf
/run/
net6-*.conf
Connecting to 10.1.9.101:1002 (10.1.9.101:1002)
wget: can't connect to remote host (10.1.9.101): Network is unreachable
Unable to find a live file system on the network
```
It the zdev 800 doesn't get enabled.
```
ip addr
1: lo: mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
(initramfs) [6n
lszdev | grep 0.0.0800
qeth 0.0.0800:0.0.0801:0.0.0802 no no
```
But I can enable it manually:
```
chzdev -e 800
QETH device 0.0.0800:0.0.0801:0.0.0802 configured
Note: The initial RAM-disk must be updated for these changes to take effect:
- QETH device 0.0.0800:0.0.0801:0.0.0802
A manual update of the initial RAM-disk is required.
(initramfs) [6n
ip addr
1: lo: mtu 65536 qdisc noop qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enc800: mtu 1500 qdisc noop qlen 1000
link/ether f2:ae:7d:de:88:a0 brd ff:ff:ff:ff:ff:ff
```
The same cmdline (adjusted for the iso url) works on 20.04.
Between 20.04 and 21.04 the line 318 `echo "${VLAN}" | grep -q "${dev}" &&
continue` was added to /scripts/functions in the initrd.ubuntu. If I remove
this line and repack the ramdisk the network boot works as expected like on
ubuntu 20.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929825/+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 1925211] Re: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x
** Changed in: ubuntu-z-systems Status: Triaged => 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/1925211 Title: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x Status in Ubuntu on IBM z Systems: Fix Committed Status in linux package in Ubuntu: Fix Committed Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Status in linux source package in Hirsute: Fix Committed Status in systemd source package in Hirsute: Invalid Status in udev source package in Hirsute: Invalid Bug description: SRU Justification [Impact] Hot removal of disks under kvm on s390 does not result in the kernel removing the block device, which can lead to hung tasks and other issues. [Test Plan] See steps to reproduce the bug in the original description below. To test, execute these steps and confirm that the block device gets removed as expected. [Where problems could occur] The fix is a revert of the changes which introduced this regression. The original commit was a removal of supposedly unused code, but it seems a mistake was made in the logic around unregistering of disks. Reverting the changes could have potential to introduce bugs related to other virt devices, especially if it interacts badly with subsequent driver changes. However, the patch reverted cleanly, and reverting restores the code to the state which has been working well in previous kernels and seems like the lowest risk option until a proper fix is available upstream. --- Repro: #1 Get a guest $ uvt-kvm create --disk 5 --password=ubuntu h release=hirsute arch=s390x label=daily $ uvt-kvm wait h release=hirsute arch=s390x label=daily #2 Attach and Detach disk $ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 10M $ virsh attach-disk h /var/lib/libvirt/images/test.qcow2 vdc $ virsh detach-disk h vdc From libvirts POV it is gone at this point $ virsh domblklist h Target Source -- vda /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs.qcow vdb /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs-ds.qcow But the guest thinks still it is present $ uvt-kvm ssh --insecure hirsute-2nd-zfs lsblk ... vdc252:32 0 20M 0 disk This even remains a while after (not a race). Any access to it in the guest will hang (as you'd expect of a non-existing blockdev) 4 017581739 20 0 12140 4800 - S+ pts/0 0:00 | \_ sudo mkfs.ext4 /dev/vdc 4 017591758 20 0 6924 1044 - D+ pts/0 0:00 | \_ mkfs.ext4 /dev/vdc The result above was originally found with hirsute-guest@hirsute-host on s390x I do NOT see the same with groovy-guest@hirsute-host on s390x I DO see the same with hirsute-guest@groovy-host on s390x => Guest version dependent not Host/Hipervisor dependent I DO see the same with ZFS disks AND LVM disks being added => not type dependent I do NOT see the same on x86. => Arch dependent ?? ... the evidence slowly points towards an issue in the guest, damn we are so close to release - but non-fully detaching disks are critical in my POV :-/ Filing this as-is for awareness, but certainly this will need more debugging. Unsure where this is going to eventually I'll now file it for kernel/udev/systemd. If there are any known issues/components that are related let me know please! --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu65 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 21.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lspci-vt: -[:00]- Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: Package: udev PackageArchitecture: s390x PciMultimedia: ProcFB: ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ProcVersionSignature: User Name 5.11.0-14.15-generic 5.11.12 RelatedPackageVersions: linux-restricted-modules-5.11.0-14-generic N/A linux-backports-modules-5.11.0-14-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: hirsute uec-images Uname: Linux 5.11.0-14-generic s390x UpgradeStatus: No upgrade log present
[Touch-packages] [Bug 1916485] Re: test -x fails inside shell scripts in containers
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Tags added: reverse-proxy-bugzilla -- 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/1916485 Title: test -x fails inside shell scripts in containers Status in Ubuntu on IBM z Systems: New Status in docker.io package in Ubuntu: New Status in glibc package in Ubuntu: Opinion Status in libseccomp package in Ubuntu: Fix Committed Status in runc package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in docker.io source package in Xenial: New Status in libseccomp source package in Xenial: New Status in runc source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in docker.io source package in Bionic: New Status in libseccomp source package in Bionic: New Status in runc source package in Bionic: Fix Released Status in systemd source package in Bionic: Fix Released Status in docker.io source package in Focal: New Status in libseccomp source package in Focal: New Status in runc source package in Focal: Fix Released Status in systemd source package in Focal: Fix Released Status in docker.io source package in Groovy: New Status in libseccomp source package in Groovy: New Status in runc source package in Groovy: Fix Released Status in systemd source package in Groovy: Fix Released Status in docker.io source package in Hirsute: New Status in libseccomp source package in Hirsute: Fix Committed Status in runc source package in Hirsute: Fix Released Status in systemd source package in Hirsute: Fix Released Status in systemd package in Debian: Fix Released Bug description: (SRU template for systemd) [impact] bash (and some other shells) builtin test command -x operation fails [test case] on any affected host system, start nspawn container, e.g.: $ sudo apt install systemd-container $ wget https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64-root.tar.xz $ mkdir h $ cd h $ tar xvf ../hirsute-server-cloudimg-amd64-root.tar.xz $ sudo systemd-nspawn Then from a bash shell, verify if test -x works: root@h:~# ls -l /usr/bin/gpg -rwxr-xr-x 1 1000 1000 1083472 Jan 16 09:53 /usr/bin/gpg root@h:~# test -x /usr/bin/gpg || echo "fail" fail [regression potential] any regression would likely occur during a syscall, most likely faccessat2(), or during other syscalls. [scope] this is needed for b/f this is fixed upstream by commit bcf08acbffdee0d6360d3c31d268e73d0623e5dc which is in 247 and later, so this is fixed in h this was pulled into Debian at version 246.2 in commit e80c5e5371ab77792bae94e0f8c5e85a4237e6eb, so this is fixed in g in x, the entire systemd seccomp code is completely different and the patch doesn't apply, nor does it appear to be needed, as the problem doesn't reproduce in a h container under x. [other info] this needs fixing in libseccomp as well [original description] glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be
[Touch-packages] [Bug 1925211] Re: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Assignee: (unassigned) => bugproxy (bugproxy) ** Tags added: reverse-proxy-bugzilla -- 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/1925211 Title: Hot-unplug of disks leaves broken block devices around in Hirsute on s390x Status in Ubuntu on IBM z Systems: New Status in linux package in Ubuntu: Confirmed Status in systemd package in Ubuntu: New Status in udev package in Ubuntu: New Status in linux source package in Hirsute: Confirmed Status in systemd source package in Hirsute: New Status in udev source package in Hirsute: New Bug description: Repro: #1 Get a guest $ uvt-kvm create --disk 5 --password=ubuntu h release=hirsute arch=s390x label=daily $ uvt-kvm wait h release=hirsute arch=s390x label=daily #2 Attach and Detach disk $ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/test.qcow2 10M $ virsh attach-disk h /var/lib/libvirt/images/test.qcow2 vdc $ virsh detach-disk h vdc From libvirts POV it is gone at this point $ virsh domblklist h Target Source -- vda /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs.qcow vdb /var/lib/uvtool/libvirt/images/hirsute-2nd-zfs-ds.qcow But the guest thinks still it is present $ uvt-kvm ssh --insecure hirsute-2nd-zfs lsblk ... vdc252:32 0 20M 0 disk This even remains a while after (not a race). Any access to it in the guest will hang (as you'd expect of a non-existing blockdev) 4 017581739 20 0 12140 4800 - S+ pts/0 0:00 | \_ sudo mkfs.ext4 /dev/vdc 4 017591758 20 0 6924 1044 - D+ pts/0 0:00 | \_ mkfs.ext4 /dev/vdc The result above was originally found with hirsute-guest@hirsute-host on s390x I do NOT see the same with groovy-guest@hirsute-host on s390x I DO see the same with hirsute-guest@groovy-host on s390x => Guest version dependent not Host/Hipervisor dependent I DO see the same with ZFS disks AND LVM disks being added => not type dependent I do NOT see the same on x86. => Arch dependent ?? ... the evidence slowly points towards an issue in the guest, damn we are so close to release - but non-fully detaching disks are critical in my POV :-/ Filing this as-is for awareness, but certainly this will need more debugging. Unsure where this is going to eventually I'll now file it for kernel/udev/systemd. If there are any known issues/components that are related let me know please! --- ProblemType: Bug AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access '/dev/snd/': No such file or directory AplayDevices: Error: [Errno 2] No such file or directory: 'aplay' ApportVersion: 2.20.11-0ubuntu65 Architecture: s390x ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord' CRDA: N/A CasperMD5CheckResult: unknown DistroRelease: Ubuntu 21.04 IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig' Lspci: Lspci-vt: -[:00]- Lsusb: Error: command ['lsusb'] failed with exit code 1: Lsusb-t: Error: command ['lsusb', '-t'] failed with exit code 1: /sys/bus/usb/devices: No such file or directory Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1: Package: udev PackageArchitecture: s390x PciMultimedia: ProcFB: ProcKernelCmdLine: root=LABEL=cloudimg-rootfs ProcVersionSignature: User Name 5.11.0-14.15-generic 5.11.12 RelatedPackageVersions: linux-restricted-modules-5.11.0-14-generic N/A linux-backports-modules-5.11.0-14-generic N/A linux-firmware N/A RfKill: Error: [Errno 2] No such file or directory: 'rfkill' Tags: hirsute uec-images Uname: Linux 5.11.0-14-generic s390x UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm audio cdrom dialout dip floppy lxd netdev plugdev sudo video _MarkForUpload: True acpidump: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1925211/+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 1877088] Re: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf
** No longer affects: debianutils (Ubuntu) ** No longer affects: debianutils (Ubuntu Hirsute) ** No longer affects: debianutils (Ubuntu Focal) ** No longer affects: debianutils (Ubuntu Bionic) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debianutils in Ubuntu. https://bugs.launchpad.net/bugs/1877088 Title: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf Status in Ubuntu on IBM z Systems: In Progress Status in linux-base package in Ubuntu: Fix Released Status in linux-base source package in Bionic: New Status in linux-base source package in Focal: New Status in linux-base source package in Hirsute: Fix Released Bug description: [Impact] * initrd link is not updated when using installkernel or "make install" from kernel sources. This leads to boot failure after installing a new kernel with mentioned methods because the kernel does not match initrd. * It's a regression because for Focal it was working before. * Issue was reproduced also on Bionic. * The proposed fixed by Stefan Bader adds a hook in /etc/kernel/postinst.d/ so installkernel will relink the initrd. The kernel DEB packages should not be affected. * The solution from Stefan (first patch) was tested by the bug reporter (niklas.schne...@ibm.com). [Test Plan] * Build a kernel * sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot * Check if /boot/initrd or /initrd symlink to the new initrd [Where problems could occur] * Installing kernel via: installkernel or "make install", so mostly kernel developer environments [Other info from developer] When testing development kernels I usually rely on the installkernel script either through the "make install" target of the Kernel source or manually. This used to work great on Ubuntu on Z. On Ubuntu 20.04 (freshly installed up to date) this fails however because /boot/initrd.img is not updated (/boot/vmlinuz is) and thus zipl installs the wrong kernel/initrd combination rendering the system unbootable. (with the correct modules already copied to /usr/lib/modules/5.7.0-rc4-06500-gb67ea026badd/) # sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd update-initramfs: Generating /boot/initrd.img-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. run-parts: executing /etc/kernel/postinst.d/zz-zipl 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. # ls -l /boot total 178364 -rw--- 1 root root135168 May 6 11:52 bootmap -rw-r--r-- 1 root root 90471 Apr 29 15:34 config-5.4.0-29-generic lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img -> initrd.img-5.4.0-29-generic <== should point to new version -rw-r--r-- 1 root root 19663996 May 6 11:42 initrd.img-5.4.0-29-generic -rw-r--r-- 1 root root 125339494 May 6 11:52 initrd.img-5.7.0-rc4-06500-gb67ea026badd lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img.old -> initrd.img-5.4.0-29-generic -rw--- 1 root root 3087920 Apr 29 15:34 System.map-5.4.0-29-generic -rw-r--r-- 1 root root 4031691 May 6 11:52 System.map-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 4031691 May 6 11:49 System.map-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root37 May 6 11:52 vmlinuz -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw--- 1 root root 8086072 Apr 29 15:54 vmlinuz-5.4.0-29-generic -rw-r--r-- 1 root root 9080832 May 6 11:52 vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 9080832 May 6 11:49 vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root41 May 6 11:52 vmlinuz.old -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877088/+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 1903874] Re: [21.04 FEAT] Upgrade binutils to latest version 2.35.1
** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903874 Title: [21.04 FEAT] Upgrade binutils to latest version 2.35.1 Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Bug description: Update binutils to latest version. Currently 2.35.1 was made available To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903874/+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 1918970] Re: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration
** Changed in: ubuntu-z-systems Status: New => Triaged -- 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/1918970 Title: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration Status in MAAS: New Status in Ubuntu on IBM z Systems: Triaged Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in s390-tools package in Ubuntu: New Bug description: I tried to deploy Ubuntu 18.04 with the GA-18.04 kernel on an IBM Z14 DPM Partition. The initrd fails to bring up network and thus fails to boot in MAAS. I haven't tried older versions of Ubuntu but suspect they also have the same bug. mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 chvt: can't open console No init found. Try passing init= bootarg. Couldn't get a file descriptor referring to the console /scripts/panic/console_setup: line 133: can't create /dev/tty1: No such device o r address /scripts/panic/console_setup: line 1: can't open /dev/tty1: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty2: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty2: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty3: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty3: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty4: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty4: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty5: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty5: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty6: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty6: No such device or ad dress BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) [6n [ 78.114530] random: crng init done [ 78.114538] random: 7 urandom warning(s) missed due to ratelimiting To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1918970/+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 1918970] Re: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration
** Tags added: bot-stop-nagging -- 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/1918970 Title: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration Status in MAAS: New Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: Incomplete Status in s390-tools package in Ubuntu: New Bug description: I tried to deploy Ubuntu 18.04 with the GA-18.04 kernel on an IBM Z14 DPM Partition. The initrd fails to bring up network and thus fails to boot in MAAS. I haven't tried older versions of Ubuntu but suspect they also have the same bug. mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 chvt: can't open console No init found. Try passing init= bootarg. Couldn't get a file descriptor referring to the console /scripts/panic/console_setup: line 133: can't create /dev/tty1: No such device o r address /scripts/panic/console_setup: line 1: can't open /dev/tty1: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty2: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty2: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty3: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty3: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty4: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty4: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty5: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty5: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty6: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty6: No such device or ad dress BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) [6n [ 78.114530] random: crng init done [ 78.114538] random: 7 urandom warning(s) missed due to ratelimiting To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1918970/+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 1918970] Re: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration
in response to comment #2) That would be indeed a valid approach (and I think we already had that once in the z13s prototype), since we run in such a situation always on a system in DPM mode, were one usually have only selected devices configured (compared to a system in PR/SM classic mode, where one often heavily shares devices). -- 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/1918970 Title: Unable to netboot Ubuntu 18.04 and older on an IBM Z DPM Partition - no manual nor automatic qeth device configuration Status in MAAS: New Status in Ubuntu on IBM z Systems: New Status in initramfs-tools package in Ubuntu: New Status in linux package in Ubuntu: New Status in s390-tools package in Ubuntu: New Bug description: I tried to deploy Ubuntu 18.04 with the GA-18.04 kernel on an IBM Z14 DPM Partition. The initrd fails to bring up network and thus fails to boot in MAAS. I haven't tried older versions of Ubuntu but suspect they also have the same bug. mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: current directory on the same filesystem as the root: error 0 Target filesystem doesn't have requested /sbin/init. run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 run-init: current directory on the same filesystem as the root: error 0 chvt: can't open console No init found. Try passing init= bootarg. Couldn't get a file descriptor referring to the console /scripts/panic/console_setup: line 133: can't create /dev/tty1: No such device o r address /scripts/panic/console_setup: line 1: can't open /dev/tty1: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty2: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty2: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty3: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty3: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty4: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty4: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty5: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty5: No such device or ad dress /scripts/panic/console_setup: line 1: can't create /dev/tty6: No such device or address /scripts/panic/console_setup: line 1: can't open /dev/tty6: No such device or ad dress BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) [6n [ 78.114530] random: crng init done [ 78.114538] random: 7 urandom warning(s) missed due to ratelimiting To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1918970/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: Fix Released Status in binutils package in Debian: New Bug description: [Impact] * In s390 kernel context, this bug manifests itself as random errors and infinite loops. [Test Case] * Needs to be confirmed by IBM * Build-time tests-suite (applied upstream) backported to Bionic in + ld/testsuite/ld-s390/gotreloc-1.s + ld/testsuite/ld-s390/gotreloc-1.ver + ld/testsuite/ld-s390/gotreloc_31-1.dd + ld/testuite/ld-s390/gotreloc_64-1.dd * If you build the kernel with CONFIG_DEBUG_INFO_BTF, there is a 50% chance that you will see "Failed verification: in-kernel BTF is malformed" during boot [Where problems could occur] * Binutils is a base toolchain package - A problem could potentially affect the whole system - With compiler/linker errors - Or random errors in the produced binaries * This patch touches only architecture specific code in bfd/elf64-s390.c - It would only affect the s390x architecture in this case [Other Info] * While testing the fix in Bileto, we found one pending autopkgtest regression with linux/amd64 4.15.0-135.139 which is resolved in 4.15.0-136.140 (currently in -proposed). * The failed test in snapcraft is not a regression, as it never passed before. == Original Description == Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode
Looking at the tags that were added by the BZ bridge (targetmilestone- inin2004), it's focal. -- 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/1914740 Title: IPs are not assigned for Hipersockets in DHCP mode Status in Ubuntu on IBM z Systems: Incomplete Status in isc-dhcp package in Ubuntu: Confirmed Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: ---Problem Description--- IPs are not getting assigned for Hipersockets in DHCP mode Contact Information = Asha Shekharappa(ashsh...@in.ibm.com) Sankar(sankar...@in.ibm.com) ---uname output--- 52-Ubuntu SMP Thu Sep 10 10:59:04 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Ubuntu 20.04 Netplan with systemd-networkd as renderer Creating ethernet connection on Hipersockets device in DHCP mode fails to assign IPs 1. Configure a Hipersockets device chzdev -e 0.0.8f00 2. Create a .yaml file with the below details network: version: 2 ethernets: enc8f00: dhcp4: yes 3. netplan apply 4. The IP is not assigned as seen below root@M96SANKAR:/etc/netplan# ip a s enc8f00: mtu 32768 qdisc mq state UP group default qlen 1000 link/ether fe:da:af:44:08:02 brd ff:ff:ff:ff:ff:ff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1914740/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
Ok thx Ilyia, with that I'm going to update the tags accordingly ... ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: Fix Committed Status in binutils package in Debian: New Bug description: [Impact] * In s390 kernel context, this bug manifests itself as random errors and infinite loops. [Test Case] * Needs to be confirmed by IBM * Build-time tests-suite (applied upstream) backported to Bionic in + ld/testsuite/ld-s390/gotreloc-1.s + ld/testsuite/ld-s390/gotreloc-1.ver + ld/testsuite/ld-s390/gotreloc_31-1.dd + ld/testuite/ld-s390/gotreloc_64-1.dd * If you build the kernel with CONFIG_DEBUG_INFO_BTF, there is a 50% chance that you will see "Failed verification: in-kernel BTF is malformed" during boot [Where problems could occur] * Binutils is a base toolchain package - A problem could potentially affect the whole system - With compiler/linker errors - Or random errors in the produced binaries * This patch touches only architecture specific code in bfd/elf64-s390.c - It would only affect the s390x architecture in this case [Other Info] * While testing the fix in Bileto, we found one pending autopkgtest regression with linux/amd64 4.15.0-135.139 which is resolved in 4.15.0-136.140 (currently in -proposed). * The failed test in snapcraft is not a regression, as it never passed before. == Original Description == Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: Fix Committed Status in binutils package in Debian: New Bug description: [Impact] * In s390 kernel context, this bug manifests itself as random errors and infinite loops. [Test Case] * Needs to be confirmed by IBM * Build-time tests-suite (applied upstream) backported to Bionic in + ld/testsuite/ld-s390/gotreloc-1.s + ld/testsuite/ld-s390/gotreloc-1.ver + ld/testsuite/ld-s390/gotreloc_31-1.dd + ld/testuite/ld-s390/gotreloc_64-1.dd * If you build the kernel with CONFIG_DEBUG_INFO_BTF, there is a 50% chance that you will see "Failed verification: in-kernel BTF is malformed" during boot [Where problems could occur] * Binutils is a base toolchain package - A problem could potentially affect the whole system - With compiler/linker errors - Or random errors in the produced binaries * This patch touches only architecture specific code in bfd/elf64-s390.c - It would only affect the s390x architecture in this case [Other Info] * While testing the fix in Bileto, we found one pending autopkgtest regression with linux/amd64 4.15.0-135.139 which is resolved in 4.15.0-136.140 (currently in -proposed). * The failed test in snapcraft is not a regression, as it never passed before. == Original Description == Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: In Progress Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: In Progress Status in binutils package in Debian: New Bug description: [Impact] * In s390 kernel context, this bug manifests itself as random errors and infinite loops. [Test Case] * Needs to be confirmed by IBM * Build-time tests-suite (applied upstream) backported to Bionic in + ld/testsuite/ld-s390/gotreloc-1.s + ld/testsuite/ld-s390/gotreloc-1.ver + ld/testsuite/ld-s390/gotreloc_31-1.dd + ld/testuite/ld-s390/gotreloc_64-1.dd * If you build the kernel with CONFIG_DEBUG_INFO_BTF, there is a 50% chance that you will see "Failed verification: in-kernel BTF is malformed" during boot [Where problems could occur] * Binutils is a base toolchain package - A problem could potentially affect the whole system - With compiler/linker errors - Or random errors in the produced binaries * This patch touches only architecture specific code in bfd/elf64-s390.c - It would only affect the s390x architecture in this case [Other Info] * While testing the fix in Bileto, we found one pending autopkgtest regression with linux/amd64 4.15.0-135.139 which is resolved in 4.15.0-136.140 (currently in -proposed). * The failed test in snapcraft is not a regression, as it never passed before. == Original Description == Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1889742] Re: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils)
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1889742 Title: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils) Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Focal: Fix Released Status in binutils source package in Groovy: Fix Released Bug description: == Comment: #0 - Heinz-Werner Seeck - 2020-07-31 03:28:30 == On z13 we have that vector alignment hints are already accepted. This backport enables GAS to accept such hints not only for target z14 but also for z13. Since GCCs default target on Ubuntu is z13 for s390x, we could greatly benefit from such alignment hints. (note a separate bugzilla entry for GCC allowing to emit alignment hints for z13 will be opened shortly) This is a backport of upstreams commit 26b6ab7a0e. Userspace tool common name: as The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Already included within 20.10 via LP: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1888654 This should also be SRUed for 20.04 [Impact] * Vector alignment hints were enabled for z14 processors, but not z13 * Since the z13 processors support vector alignment hints, binutils should have them enabled for z13 [Test Case] * Run the test suite to make sure all tests pass * Pull in the change, and re-run the test suite to make sure all tests still pass. This backport includes tests for the vector alignment hints. [Where problems could occur] * If vector alignment hints were not enabled correctly we could still compile code with incorrectly ordered opcodes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889742/+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 1874381] Re: LVM device unavailable after 18.04 to 20.04 upgrade Timed out waiting for device /dev/mapper/s5lp8--v g-home
Sorry, I can't answer that for huge LVM installations. But what I can say is that it is for s390x installations (multipath with LVMs on top) a kind of immediately responding. One thought is to check/do this for example at the end of the dist- upgrade process, where a potential delay wouldn't be a very huge drawback (compared to a system that doesn't come up again after reboot). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1874381 Title: LVM device unavailable after 18.04 to 20.04 upgrade Timed out waiting for device /dev/mapper/s5lp8--v g-home Status in Ubuntu on IBM z Systems: Confirmed Status in lvm2 package in Ubuntu: Confirmed Status in lvm2 source package in Focal: Confirmed Bug description: After upgrading an LPAR configured with LVM from 18.04 to 20.04 /home is no longer mounted. During boot the console shows Timed out waiting for device /dev/mapper/s5lp8--vg-home Please see the attached dist-upgrade logs and console output for more detail. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1874381/+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 1889742] Re: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils)
** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1889742 Title: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils) Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Focal: Fix Committed Status in binutils source package in Groovy: Fix Released Bug description: == Comment: #0 - Heinz-Werner Seeck - 2020-07-31 03:28:30 == On z13 we have that vector alignment hints are already accepted. This backport enables GAS to accept such hints not only for target z14 but also for z13. Since GCCs default target on Ubuntu is z13 for s390x, we could greatly benefit from such alignment hints. (note a separate bugzilla entry for GCC allowing to emit alignment hints for z13 will be opened shortly) This is a backport of upstreams commit 26b6ab7a0e. Userspace tool common name: as The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Already included within 20.10 via LP: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1888654 This should also be SRUed for 20.04 [Impact] * Vector alignment hints were enabled for z14 processors, but not z13 * Since the z13 processors support vector alignment hints, binutils should have them enabled for z13 [Test Case] * Run the test suite to make sure all tests pass * Pull in the change, and re-run the test suite to make sure all tests still pass. This backport includes tests for the vector alignment hints. [Where problems could occur] * If vector alignment hints were not enabled correctly we could still compile code with incorrectly ordered opcodes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889742/+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 1889742] Re: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils)
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1889742 Title: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils) Status in Ubuntu on IBM z Systems: Fix Committed Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Focal: Fix Committed Status in binutils source package in Groovy: Fix Released Bug description: == Comment: #0 - Heinz-Werner Seeck - 2020-07-31 03:28:30 == On z13 we have that vector alignment hints are already accepted. This backport enables GAS to accept such hints not only for target z14 but also for z13. Since GCCs default target on Ubuntu is z13 for s390x, we could greatly benefit from such alignment hints. (note a separate bugzilla entry for GCC allowing to emit alignment hints for z13 will be opened shortly) This is a backport of upstreams commit 26b6ab7a0e. Userspace tool common name: as The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Already included within 20.10 via LP: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1888654 This should also be SRUed for 20.04 [Impact] * Vector alignment hints were enabled for z14 processors, but not z13 * Since the z13 processors support vector alignment hints, binutils should have them enabled for z13 [Test Case] * Run the test suite to make sure all tests pass * Pull in the change, and re-run the test suite to make sure all tests still pass. This backport includes tests for the vector alignment hints. [Where problems could occur] * If vector alignment hints were not enabled correctly we could still compile code with incorrectly ordered opcodes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889742/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
Thx for the confirmation! With that and all components of this bug on status Fix Released, this is closed now. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Fix Released Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Fix Released Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: Fix Released Status in gzip package in Ubuntu: Fix Released Status in gzip source package in Groovy: Fix Released Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc [Impact] * With zlib acceleration enabled, attempting to compress multiple files over 5MB would cause a segmentation fault. * The files could still be compressed in separate commands [Test Case] * Create two files that are larger than 5MB * Enable zlib acceleration (z15 hardware required) * Run the command gzip * NOTE: we do not have access to z15 hardware and therefore are relying on IBM to verify this fix [Where problems could occur] * Due to lack of testing resources, it's possible the bug has not been fully fixed, and the segmentation fault could still occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1907789] Re: 2.35.50 breaks ld -no-pie
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1907789 Title: 2.35.50 breaks ld -no-pie Status in binutils: Fix Released Status in Ubuntu on IBM z Systems: Fix Released Status in binutils package in Ubuntu: Fix Released Status in qemu package in Ubuntu: Fix Released Status in s390-tools package in Ubuntu: Fix Released Bug description: The qemu build reaches (and always did) a step where it tries to link some img files. That is done via the command: $ ld -m elf_i386 -T /<>/pc-bios/optionrom//flat.lds -no-pie -s -o multiboot.img multiboot.o Recently that still works in Debian [1] but no more in Ubuntu [2]. I think that the new binutils broke me. In hirsute proposed those are at 2.35.50.20201210-0ubuntu1 The issue is easily isolated, and by copying the two files around I found the following: Hirsute: 2.35.50.20201210-0ubuntu1 - bad Hirsute: 2.35.50.20201207-0ubuntu1 - bad Sid: 2.35.1-4 - good Groovy: 2.35.1-1ubuntu1 - good Focal: 2.34-6ubuntu1 - good I'll attach these two files to the bug, just thro them into a directory and run the command: $ ld -m elf_i386 -T ./flat.lds -no-pie -s -o linuxboot.img linuxboot.o If that is an intentional change please guide how this is now supposed to work. [1]: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A5.2%2Bdfsg-2=1607598738=1 [2]: https://launchpadlibrarian.net/510801929/buildlog_ubuntu-hirsute-amd64.qemu_1%3A5.2+dfsg-2ubuntu1~ppa2_BUILD To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1907789/+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 1889742] Re: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils)
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1889742 Title: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils) Status in Ubuntu on IBM z Systems: In Progress Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Focal: New Status in binutils source package in Groovy: Fix Released Bug description: == Comment: #0 - Heinz-Werner Seeck - 2020-07-31 03:28:30 == On z13 we have that vector alignment hints are already accepted. This backport enables GAS to accept such hints not only for target z14 but also for z13. Since GCCs default target on Ubuntu is z13 for s390x, we could greatly benefit from such alignment hints. (note a separate bugzilla entry for GCC allowing to emit alignment hints for z13 will be opened shortly) This is a backport of upstreams commit 26b6ab7a0e. Userspace tool common name: as The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Already included within 20.10 via LP: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1888654 This should also be SRUed for 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889742/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Changed in: ubuntu-z-systems
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
Fix Released
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
Fix Released
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Tags removed: verification-needed verification-needed-groovy
** Tags added: verification-done verification-done-groovy
** Changed in: ubuntu-z-systems
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
Fix Committed
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
Fix Committed
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1838258] Re: Unable to configure VLAN on an additional OSA interface
Thx for the re-test and update - with that I'm closing this ticket now. ** Changed in: linux (Ubuntu) Status: Incomplete => Fix Released ** Changed in: ubuntu-z-systems Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1838258 Title: Unable to configure VLAN on an additional OSA interface Status in Ubuntu on IBM z Systems: Fix Released Status in iproute2 package in Ubuntu: Expired Status in linux package in Ubuntu: Fix Released Bug description: After installing a base Ubuntu 18.04.1 server, an additional OSA device "e530" is attached and configured with chzdev. Then a VLAN configuration should be applied using the ip command. However this results in the error message "RTNETLINK answers: File exists". >snip ip link add link ence530 name ence530.209 type vlan id 209 RTNETLINK answers: File exists snip< Executing the same steps on an Ubuntu 16.04.5 server, the ip command finishes without an error message but the VLAN interface is also not configured. Reproduction: - Install a 18.04.1 server - attach an additional OSA interface - configure a VLAN using the ip command To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1838258/+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 1889742] Re: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils)
** Changed in: ubuntu-z-systems Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1889742 Title: [UBUNTU 20.04] Accept vector alignment hints on z13 (binutils) Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Focal: New Status in binutils source package in Groovy: Fix Released Bug description: == Comment: #0 - Heinz-Werner Seeck - 2020-07-31 03:28:30 == On z13 we have that vector alignment hints are already accepted. This backport enables GAS to accept such hints not only for target z14 but also for z13. Since GCCs default target on Ubuntu is z13 for s390x, we could greatly benefit from such alignment hints. (note a separate bugzilla entry for GCC allowing to emit alignment hints for z13 will be opened shortly) This is a backport of upstreams commit 26b6ab7a0e. Userspace tool common name: as The userspace tool has the following bit modes: 64-bit Userspace rpm: binutils Already included within 20.10 via LP: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1888654 This should also be SRUed for 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889742/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
Thx Ilya for the verification on groovy - I'm adjusting the tags accordingly ... ** Tags removed: verification-needed verification-needed-groovy ** Tags added: verification-done verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: Fix Committed Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Status in gzip source package in Groovy: Fix Committed Status in zlib source package in Groovy: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc [Impact] * With zlib acceleration enabled, attempting to compress multiple files over 5MB would cause a segmentation fault. * The files could still be compressed in separate commands [Test Case] * Create two files that are larger than 5MB * Enable zlib acceleration (z15 hardware required) * Run the command gzip * NOTE: we do not have access to z15 hardware and therefore are relying on IBM to verify this fix [Where problems could occur] * Due to lack of testing resources, it's possible the bug has not been fully fixed, and the segmentation fault could still occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
** Changed in: ubuntu-z-systems Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: Fix Committed Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Status in gzip source package in Groovy: Fix Committed Status in zlib source package in Groovy: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc [Impact] * With zlib acceleration enabled, attempting to compress multiple files over 5MB would cause a segmentation fault. * The files could still be compressed in separate commands [Test Case] * Create two files that are larger than 5MB * Enable zlib acceleration (z15 hardware required) * Run the command gzip * NOTE: we do not have access to z15 hardware and therefore are relying on IBM to verify this fix [Where problems could occur] * Due to lack of testing resources, it's possible the bug has not been fully fixed, and the segmentation fault could still occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
+1 (according to title prefix and tag 'targetmilestone-inin2010 ') -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: New Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Status in gzip source package in Groovy: Confirmed Status in zlib source package in Groovy: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Merge proposal linked:
https://code.launchpad.net/~fheimes/ubuntu/+source/elfutils/+git/elfutils/+merge/395986
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
In Progress
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
In Progress
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Merge proposal linked:
https://code.launchpad.net/~fheimes/ubuntu/+source/elfutils/+git/elfutils/+merge/395949
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
In Progress
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
In Progress
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Changed in: elfutils (Ubuntu Groovy)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
In Progress
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
In Progress
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
MP for groovy is open
** Merge proposal linked:
https://code.launchpad.net/~fheimes/ubuntu/+source/elfutils/+git/elfutils/+merge/395917
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
In Progress
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
In Progress
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
A PPA was created and shared that contains a patched elfutils version for
groovy:
Look for elfutils - 0.181-1ubuntu1~ppa1 at
https://launchpad.net/~fheimes/+archive/ubuntu/lp1908756/+packages
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
In Progress
Status in elfutils package in Ubuntu:
Fix Released
Status in elfutils source package in Groovy:
New
Status in elfutils source package in Hirsute:
Fix Released
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
MP for hirsute is open
** Changed in: ubuntu-z-systems
Status: New => In Progress
** Changed in: elfutils (Ubuntu Hirsute)
Assignee: Skipper Bug Screeners (skipper-screen-team) => Frank Heimes
(fheimes)
** Changed in: elfutils (Ubuntu Groovy)
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
** Changed in: elfutils (Ubuntu Hirsute)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
In Progress
Status in elfutils package in Ubuntu:
In Progress
Status in elfutils source package in Groovy:
New
Status in elfutils source package in Hirsute:
In Progress
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Merge proposal linked:
https://code.launchpad.net/~fheimes/ubuntu/+source/elfutils/+git/elfutils/+merge/395663
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
New
Status in elfutils package in Ubuntu:
New
Status in elfutils source package in Groovy:
New
Status in elfutils source package in Hirsute:
New
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
* But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
[Other]
* The fix is upstream accepted with elfutils > 0.182.
__
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32
bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Description changed:
+ SRU Bug Template:
+ =
+
+ [Impact]
+
+ * There is an endianess problem in pid_memory_read that impacts s390x.
+
+ * Due to this elfutils biarch test fails on s390x doing unwinding for a
+ 32 bit process.
+
+ [Fix]
+
+ * e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
+
+ [Test Case]
+
+ * Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
+
+ * Run the test script: 'run-backtrace-native-biarch.sh'
+
+ * It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
+
+ [Where problems could occur]
+
+ * If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
+
+ * But in worst case the changes in 'pid_memory_read' of
/libdwfl/linux-pid-attach.c could have a negative impact even on architectures
other than s390x, in case the check for the endiness is wrong.
+
+ * But the changes are quite traceable and the additional code that fixes the
endianess problem is really only active on a big endian architecture.
+
+ [Other]
+
+ * The fix is upstream accepted with elfutils > 0.182.
+ __
+
---Problem Description---
libdw unwinding fails for 32 bit binaries.
-
- Elfutils biarch test currently fails on s390x doing unwinding for a 32 bit
process.
+
+ Elfutils biarch test currently fails on s390x doing unwinding for a 32
+ bit process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
- IBM Z: Fix endianess problem in pid_memory_read
-
- The cached reads lack the big endian adjustments done in the fallback
- path.
-
- Signed-off-by: Andreas Krebbel
+ IBM Z: Fix endianess problem in pid_memory_read
+ The cached reads lack the big endian adjustments done in the fallback
+ path.
+
+ Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to use
libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
New
Status in elfutils package in Ubuntu:
New
Status in elfutils source package in Groovy:
New
Status in elfutils source package in Hirsute:
New
Bug description:
SRU Bug Template:
=
[Impact]
* There is an endianess problem in pid_memory_read that impacts
s390x.
* Due to this elfutils biarch test fails on s390x doing unwinding for
a 32 bit process.
[Fix]
* e4d985a3c1c873f77d20fa0cd421458cc2824996 e4d985a3 "IBM Z: Fix endianess
problem in pid_memory_read"
[Test Case]
* Have an Ubuntu Server 20.10 system or newer installed on LPAR, z/VM or KVM
that comes with elfutils 0.181 or 0.182.
* Run the test script: 'run-backtrace-native-biarch.sh'
* It either core dumps without the patch in place - look for
"/test-subr.sh: line 84: 376822 Aborted (core dumped)" or succeeds.
[Where problems could occur]
* If the translation is not done right (shift of the upper 4 bytes + down on
big endian 64 bit targets) the situation is broken in the same way, and things
stay the same.
* But in worst case the changes in
[Touch-packages] [Bug 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Also affects: elfutils (Ubuntu Hirsute)
Importance: Undecided
Assignee: Skipper Bug Screeners (skipper-screen-team)
Status: New
** Also affects: elfutils (Ubuntu Groovy)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
New
Status in elfutils package in Ubuntu:
New
Status in elfutils source package in Groovy:
New
Status in elfutils source package in Hirsute:
New
Bug description:
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32 bit
process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1908756] Re: Ubuntu 20.10 - elfutils unwinding broken for s390 compat
** Also affects: ubuntu-z-systems
Importance: Undecided
Status: New
** Changed in: ubuntu-z-systems
Importance: Undecided => Medium
** Changed in: ubuntu-z-systems
Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to elfutils in Ubuntu.
https://bugs.launchpad.net/bugs/1908756
Title:
Ubuntu 20.10 - elfutils unwinding broken for s390 compat
Status in Ubuntu on IBM z Systems:
New
Status in elfutils package in Ubuntu:
New
Bug description:
---Problem Description---
libdw unwinding fails for 32 bit binaries.
Elfutils biarch test currently fails on s390x doing unwinding for a 32 bit
process.
FAIL: run-backtrace-native-biarch.sh
0x557e7000 0x557eb000 /root/elfutils/tests/backtrace-child-biarch
0x7dba4000 0x7dd51000 /usr/lib/libc-2.32.so
0x7dd53000 0x7dd7 /usr/lib/libpthread-2.32.so
0x7dd7f000 0x7dda6000 /usr/lib/ld-2.32.so
TID 376858:
# 0 0x7dd6668a raise
# 1 0x7fd0ef60 - 1
/root/elfutils/tests/backtrace: dwfl_thread_getframes: No DWARF information
found
backtrace: backtrace.c:114: callback_verify: Assertion `symname != NULL &&
strcmp (symname, "sigusr2") == 0' failed.
./test-subr.sh: line 84: 376822 Aborted (core dumped)
LD_LIBRARY_PATH="${built_library_path}${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$VALGRIND_CMD "$@"
backtrace-child-biarch: no main
FAIL run-backtrace-native-biarch.sh (exit status: 1)
Patch has already been posted and upstream committed:
https://sourceware.org/pipermail/elfutils-devel/2020q4/003149.html
Please pick up the following commit for the next release:
commit e4d985a3c1c873f77d20fa0cd421458cc2824996
Author: Andreas Krebbel
Date: Thu Nov 19 20:32:24 2020 +0100
IBM Z: Fix endianess problem in pid_memory_read
The cached reads lack the big endian adjustments done in the fallback
path.
Signed-off-by: Andreas Krebbel
The patch applies cleanly ontop of elfutils_0.181-1.
strace right now is not built with unwinding support for IBM Z although both
variants should work - libdw and libunwind.
Other distros use libdw from elfutils while Ubuntu on x86 appears to
use libunwind. libdw and libunwind do support IBM Z.
It would be good to build strace with unwinding support for Z.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1908756/+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 1877088] Re: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debianutils in Ubuntu. https://bugs.launchpad.net/bugs/1877088 Title: [UBUNTU 20.04] installkernel script does not symlink /boot/initrd.img which is required with the default zipl.conf Status in Ubuntu on IBM z Systems: In Progress Status in debianutils package in Ubuntu: New Status in linux-base package in Ubuntu: In Progress Bug description: When testing development kernels I usually rely on the installkernel script either through the "make install" target of the Kernel source or manually. This used to work great on Ubuntu on Z. On Ubuntu 20.04 (freshly installed up to date) this fails however because /boot/initrd.img is not updated (/boot/vmlinuz is) and thus zipl installs the wrong kernel/initrd combination rendering the system unbootable. (with the correct modules already copied to /usr/lib/modules/5.7.0-rc4-06500-gb67ea026badd/) # sudo installkernel 5.7.0-rc4-06500-gb67ea026badd bzImage System.map /boot run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd run-parts: executing /etc/kernel/postinst.d/initramfs-tools 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd update-initramfs: Generating /boot/initrd.img-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. run-parts: executing /etc/kernel/postinst.d/zz-zipl 5.7.0-rc4-06500-gb67ea026badd /boot/vmlinuz-5.7.0-rc4-06500-gb67ea026badd Using config file '/etc/zipl.conf' Building bootmap in '/boot' Building menu 'menu' Adding #1: IPL section 'ubuntu' (default) Adding #2: IPL section 'old' Preparing boot device: dasda (3844). Done. # ls -l /boot total 178364 -rw--- 1 root root135168 May 6 11:52 bootmap -rw-r--r-- 1 root root 90471 Apr 29 15:34 config-5.4.0-29-generic lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img -> initrd.img-5.4.0-29-generic <== should point to new version -rw-r--r-- 1 root root 19663996 May 6 11:42 initrd.img-5.4.0-29-generic -rw-r--r-- 1 root root 125339494 May 6 11:52 initrd.img-5.7.0-rc4-06500-gb67ea026badd lrwxrwxrwx 1 root root27 May 6 11:40 initrd.img.old -> initrd.img-5.4.0-29-generic -rw--- 1 root root 3087920 Apr 29 15:34 System.map-5.4.0-29-generic -rw-r--r-- 1 root root 4031691 May 6 11:52 System.map-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 4031691 May 6 11:49 System.map-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root37 May 6 11:52 vmlinuz -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw--- 1 root root 8086072 Apr 29 15:54 vmlinuz-5.4.0-29-generic -rw-r--r-- 1 root root 9080832 May 6 11:52 vmlinuz-5.7.0-rc4-06500-gb67ea026badd -rw-r--r-- 1 root root 9080832 May 6 11:49 vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old lrwxrwxrwx 1 root root41 May 6 11:52 vmlinuz.old -> vmlinuz-5.7.0-rc4-06500-gb67ea026badd.old To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877088/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
** Changed in: gzip (Ubuntu) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Fix Released Status in gzip package in Ubuntu: New Status in zlib package in Ubuntu: Fix Released Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
** Changed in: gzip (Ubuntu) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: zlib (Ubuntu) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: ubuntu-z-systems Assignee: Canonical Foundations Team (canonical-foundations) => Skipper Bug Screeners (skipper-screen-team) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: New Status in gzip package in Ubuntu: New Status in zlib package in Ubuntu: New Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
** Also affects: gzip (Ubuntu) Importance: Undecided Status: New ** Changed in: zlib (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: New Status in gzip package in Ubuntu: New Status in zlib package in Ubuntu: New Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1903814] Re: [binutils] Prevent GOT access rewrite for certain symbols
According to the affected binutils versions and the communication with IBM it's sufficient to get this fixed in Bionic. ** Also affects: binutils (Ubuntu) Importance: Undecided Status: New ** No longer affects: binutils-s390x-cross (Ubuntu) ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Also affects: binutils (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: binutils (Ubuntu) Status: New => Fix Released ** Changed in: binutils (Ubuntu Bionic) Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) ** Changed in: ubuntu-z-systems Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1903814 Title: [binutils] Prevent GOT access rewrite for certain symbols Status in Ubuntu on IBM z Systems: Triaged Status in binutils package in Ubuntu: Fix Released Status in binutils source package in Bionic: New Bug description: Please backport the following bugfix into Ubuntu LTS: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=e6213e09ed0e Some relevant historic links: Debian bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961736 glibc bugreport: https://sourceware.org/bugzilla/show_bug.cgi?id=18960 In s390 kernel context, this bug manifests itself as random errors and infinite loops, so it's fairly severe. These are the current versions of binutils: Package binutils xenial (16.04LTS) (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8 [security]: amd64 i386 2.26-8ubuntu2 [ports]: arm64 armhf powerpc ppc64el s390x xenial-updates (devel): GNU assembler, linker and binary utilities 2.26.1-1ubuntu1~16.04.8: amd64 arm64 armhf i386 powerpc ppc64el s390x bionic (18.04LTS) (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4 [security]: amd64 i386 2.30-15ubuntu1 [ports]: arm64 armhf ppc64el s390x bionic-updates (devel): GNU assembler, linker and binary utilities 2.30-21ubuntu1~18.04.4: amd64 arm64 armhf i386 ppc64el s390x focal (20.04LTS) (devel): GNU assembler, linker and binary utilities 2.34-6ubuntu1: amd64 arm64 armhf i386 ppc64el s390x groovy (devel): GNU assembler, linker and binary utilities 2.35.1-1ubuntu1: amd64 arm64 armhf i386 ppc64el s390x The patch applies fine to 2.26 and 2.30 (except for tests, but we don't need them). We don't need it on 2.32+. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1903814/+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 1898547] Re: neutron-linuxbridge-agent fails to start with iptables 1.8.5
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Status: New => Fix Committed ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1898547 Title: neutron-linuxbridge-agent fails to start with iptables 1.8.5 Status in Ubuntu on IBM z Systems: Fix Committed Status in iptables package in Ubuntu: Fix Committed Status in neutron package in Ubuntu: Invalid Status in iptables source package in Groovy: Fix Committed Status in neutron source package in Groovy: Invalid Status in iptables source package in Hirsute: Fix Committed Status in neutron source package in Hirsute: Invalid Bug description: [Impact] With iptables 1.8.5 neutron-linuxbridge-agent fails to properly start. The log file shows many errors like: 2020-10-05 10:20:37.998 551 ERROR neutron.plugins.ml2.drivers.agent._common_agent ; Stdout: ; Stderr: iptables-restore: line 29 failed This can be demonstrated with a simple test case: iptables-restore
[Touch-packages] [Bug 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Released Status in zlib source package in Groovy: Fix Released Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
If you follow the above link (comment #11): https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#zlib and click on the s390x status [here 'not a regression'], you should eventually find it - or just directly look here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/b/burp/20201020_215047_4c004@/log.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Committed Status in zlib source package in Groovy: Fix Released Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+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 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Canonical Foundations Team (canonical-foundations) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Many thx for testing on focal - I've updated the tags accordingly. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Committed Status in zlib source package in Groovy: Fix Released Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: Fix Released Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
1.2.11.dfsg-2ubuntu4 is the latest package that incl. the patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Same for focal: https://launchpad.net/ubuntu/focal/+queue?queue_state=3_text=zlib1g zlib1g | 1:1.2.11.dfsg-2ubuntu1.1 | focal-updates | s390x (groovy: zlib1g | 1:1.2.11.dfsg-2ubuntu4 | groovy-proposed | s390x ) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
Fixed package landed in proposed: https://launchpad.net/ubuntu/groovy/+queue?queue_state=3_text=zlib1g -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: In Progress Status in zlib source package in Focal: In Progress Status in zlib source package in Groovy: In Progress Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. [Impact] * Certain rsync builds fail with "error in rsync protocol data stream" on z15. * On ubuntu, rsync normally uses zstd or lz4. But when rsync is forced to use non-default zlib compression (-z flag) it uses inflateSyncPoint() API. This can also happen when rsync on the the other end doesn't support zstd & lz4. * inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. * Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. * Above makes rsync to succeed, when zlib uses hardware compression. [Test Case] Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 [Regression Potential] * inflateSyncPoint API is rarely used. Scanning codesearch, there is a lot of false positives due to embedded copies of zlib in all the things. I do see that both rsync and backuppc-rsync use it. It used during a safety check to ensure that algorithm is not at a sync point (or that cannot be determined). Nonetheless, returning error is a safer implementation for this API call. [Other Info] * This is a regression introduced by adding & enabling zlib hw acceleration by default on z15; and discovering using rsync that one API is implemented incorrectly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Release Notes for Ubuntu: New Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/1899621/+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 1899621] Re: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15
** Also affects: zlib (Ubuntu Groovy) Importance: Undecided Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Also affects: zlib (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1899621 Title: [Ubuntu 20.04] zlib: inflateSyncPoint() returns an incorrect result on z15 Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Description: zlib: inflateSyncPoint() returns an incorrect result on z15 Symptom: Certain rsync builds fail with "error in rsync protocol data stream" on z15. Problem: inflateSyncPoint() does not take into account the hardware compression state and returns an incorrect result. Solution: Make inflateSyncPoint() fail if the hardware compression is on. The hardware does not provide enough information in order to implement this function. Reproduction: z15 only: printf 1 >1 && rsync -z 1 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1899621/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
Successfully tested on z13, no regressions identified. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Committed Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
The changes landed in groovy proposed: zlib1g | 1:1.2.11.dfsg-2ubuntu3 | groovy-proposed | s390x hence updating status to Fix Committed. ** Changed in: zlib (Ubuntu) Status: Triaged => Fix Committed ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed ** No longer affects: gzip (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Committed Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Released Status in zlib source package in Groovy: Fix Released Bug description: SRU Justification: == [Impact] * This SRU fixes a combination of multiple issues: * zlib DFLTCC compression level switching can corrupt data because hardware and software compression states become desynchronized. (LP 1893170) * Since zlib is not working on all s390x system configurations support for switching between software and hardware compression is required especially for Java. (LP 1882494) * zlib on s390x may produce incomplete raw streams (but not gzip/zlib). (LP 1889059) [Test Case] * Since especially DFLTCC requires a s390x generation z15 or LinuxONE III the tests need to be done by IBM. * IBM has a set of tests available, that exercise public zlib APIs by calling them in different sequences with different buffer sizes and flush modes. * Partially these come from the IBM z/OS team, who developed their own zlib support for the hardware accelerator, and partially they are developed by the IBM Linux team based on issues encountered during development as well as fuzzing. * IBM also uses the zlib-ng test-suite as well as squash and stress- ng. * Compress data using zlib/DFLTCC with different compression level and verify state and if data got corrupted or not. (LP 1893170) * On a system with patched zlib package, switch between hardware and software compression and use zlib via the java.util.zip package (http://java.sun.com/developer/technicalArticles/Programming/compression/). (LP 1882494) * On a z15 system with hardware acceleration compression (DFLTCC) enabled, create a raw (negative windowBits value) stream with zlib. Then check if EOBS is missing or truncated. (LP 1889059) [Regression Potential] * There is a certain risk for regressions with the modifications that are introduced by the four LP bugs. * In case the package fails entirely, it will have (in worst case) an impact on all zlib, gzip and DFLTCC compression/decompression functions, that are very wide spread (gzip, tar cfz, everything with zlib) in Linux and would virtually make the system unusable. * If potential issues are limited to hardware assisted compression (which is more likely, since these patches are mostly about hw assisted compression), then issues would be limited to systems that provide this feature (latest s390x generation only). * A switch back to software got introduced (by setting DFLTCC=0 environment variable) that will help to mitigate a potential negative impact of the hw assisted compression. * Only the latest s390x generation (z15 and LinuxONE III) supports hardware assisted DFLTCC and is potentially affected. * A patched test package was made available and got successfully tested by IBM. All four bugs were finally considered as solved with zlib (1:1.2.11.dfsg-2ubuntu2~ppa2) available here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=zlib __ Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1882494] Re: [UBUNTU 20.04] zlib not working on all s390x systems configurations
Updating the status of this ticket to Fix Released because it is now fixed based on LP 1893170. ** Changed in: zlib (Ubuntu Focal) Status: Fix Committed => Fix Released ** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1882494 Title: [UBUNTU 20.04] zlib not working on all s390x systems configurations Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Eoan: Won't Fix Status in zlib source package in Focal: Fix Released Status in zlib source package in Groovy: Fix Released Bug description: Pull request (https://github.com/madler/zlib/pull/410) and tagged https://github.com/iii-i/zlib/tree/dfltcc-20200511. The new code contains the following improvements: * Added support for switching between software and hardware compression. * Added --dfltcc configure flag (the old way of building it still works). Switching between software and hardware compression is not simply a nice-to-have feature, but is actually required by Java - that's why we are requesting an update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1882494/+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 1889059] Re: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams
Updating the status of this ticket to Fix Released because it is now fixed based on LP 1893170. ** Changed in: zlib (Ubuntu Focal) Status: Fix Committed => Fix Released ** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1889059 Title: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams Status in Ubuntu on IBM z Systems: Fix Released Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Released Status in zlib source package in Groovy: Fix Released Bug description: zlib on s390x may produce incomplete raw (but not gzip/zlib) streams ---uname output--- Linux t35lp56.lnxne.boe 5.8.0-20200703.rc3.git0.52a479d42203.300.fc31.s390x #1 SMP Fri Jul 3 00:46:20 CEST 2020 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Create a raw (negative windowBits value) stream with zlib. EOBS might be missing or truncated. This affects all distro levels that contain hardware acceleration (DFLTCC) patch. I've attached the preliminary fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889059/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: In Progress Status in gzip package in Ubuntu: Triaged Status in zlib package in Ubuntu: Triaged Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
Many thx for the approval. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Triaged Status in gzip package in Ubuntu: Triaged Status in zlib package in Ubuntu: Triaged Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
Thx for the verification - updating tags ... ** 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 zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Committed Status in zlib source package in Groovy: Fix Released Bug description: SRU Justification: == [Impact] * This SRU fixes a combination of multiple issues: * zlib DFLTCC compression level switching can corrupt data because hardware and software compression states become desynchronized. (LP 1893170) * Since zlib is not working on all s390x system configurations support for switching between software and hardware compression is required especially for Java. (LP 1882494) * zlib on s390x may produce incomplete raw streams (but not gzip/zlib). (LP 1889059) [Test Case] * Since especially DFLTCC requires a s390x generation z15 or LinuxONE III the tests need to be done by IBM. * IBM has a set of tests available, that exercise public zlib APIs by calling them in different sequences with different buffer sizes and flush modes. * Partially these come from the IBM z/OS team, who developed their own zlib support for the hardware accelerator, and partially they are developed by the IBM Linux team based on issues encountered during development as well as fuzzing. * IBM also uses the zlib-ng test-suite as well as squash and stress- ng. * Compress data using zlib/DFLTCC with different compression level and verify state and if data got corrupted or not. (LP 1893170) * On a system with patched zlib package, switch between hardware and software compression and use zlib via the java.util.zip package (http://java.sun.com/developer/technicalArticles/Programming/compression/). (LP 1882494) * On a z15 system with hardware acceleration compression (DFLTCC) enabled, create a raw (negative windowBits value) stream with zlib. Then check if EOBS is missing or truncated. (LP 1889059) [Regression Potential] * There is a certain risk for regressions with the modifications that are introduced by the four LP bugs. * In case the package fails entirely, it will have (in worst case) an impact on all zlib, gzip and DFLTCC compression/decompression functions, that are very wide spread (gzip, tar cfz, everything with zlib) in Linux and would virtually make the system unusable. * If potential issues are limited to hardware assisted compression (which is more likely, since these patches are mostly about hw assisted compression), then issues would be limited to systems that provide this feature (latest s390x generation only). * A switch back to software got introduced (by setting DFLTCC=0 environment variable) that will help to mitigate a potential negative impact of the hw assisted compression. * Only the latest s390x generation (z15 and LinuxONE III) supports hardware assisted DFLTCC and is potentially affected. * A patched test package was made available and got successfully tested by IBM. All four bugs were finally considered as solved with zlib (1:1.2.11.dfsg-2ubuntu2~ppa2) available here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=zlib __ Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1882494] Re: [UBUNTU 20.04] zlib not working on all s390x systems configurations
aligned state to LP 1893170 ** Changed in: zlib (Ubuntu Focal) Status: New => Confirmed ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed ** Changed in: zlib (Ubuntu Focal) Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1882494 Title: [UBUNTU 20.04] zlib not working on all s390x systems configurations Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Eoan: Won't Fix Status in zlib source package in Focal: Fix Committed Status in zlib source package in Groovy: Fix Released Bug description: Pull request (https://github.com/madler/zlib/pull/410) and tagged https://github.com/iii-i/zlib/tree/dfltcc-20200511. The new code contains the following improvements: * Added support for switching between software and hardware compression. * Added --dfltcc configure flag (the old way of building it still works). Switching between software and hardware compression is not simply a nice-to-have feature, but is actually required by Java - that's why we are requesting an update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1882494/+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 1889059] Re: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams
aligned state to LP 1893170 ** Changed in: zlib (Ubuntu Focal) Status: New => Fix Committed ** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1889059 Title: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Committed Status in zlib source package in Groovy: Fix Released Bug description: zlib on s390x may produce incomplete raw (but not gzip/zlib) streams ---uname output--- Linux t35lp56.lnxne.boe 5.8.0-20200703.rc3.git0.52a479d42203.300.fc31.s390x #1 SMP Fri Jul 3 00:46:20 CEST 2020 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Create a raw (negative windowBits value) stream with zlib. EOBS might be missing or truncated. This affects all distro levels that contain hardware acceleration (DFLTCC) patch. I've attached the preliminary fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889059/+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 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: Fix Committed Status in zlib package in Ubuntu: Fix Released Status in zlib source package in Focal: Fix Committed Status in zlib source package in Groovy: Fix Released Bug description: SRU Justification: == [Impact] * This SRU fixes a combination of multiple issues: * zlib DFLTCC compression level switching can corrupt data because hardware and software compression states become desynchronized. (LP 1893170) * Since zlib is not working on all s390x system configurations support for switching between software and hardware compression is required especially for Java. (LP 1882494) * zlib on s390x may produce incomplete raw streams (but not gzip/zlib). (LP 1889059) [Test Case] * Since especially DFLTCC requires a s390x generation z15 or LinuxONE III the tests need to be done by IBM. * IBM has a set of tests available, that exercise public zlib APIs by calling them in different sequences with different buffer sizes and flush modes. * Partially these come from the IBM z/OS team, who developed their own zlib support for the hardware accelerator, and partially they are developed by the IBM Linux team based on issues encountered during development as well as fuzzing. * IBM also uses the zlib-ng test-suite as well as squash and stress- ng. * Compress data using zlib/DFLTCC with different compression level and verify state and if data got corrupted or not. (LP 1893170) * On a system with patched zlib package, switch between hardware and software compression and use zlib via the java.util.zip package (http://java.sun.com/developer/technicalArticles/Programming/compression/). (LP 1882494) * On a z15 system with hardware acceleration compression (DFLTCC) enabled, create a raw (negative windowBits value) stream with zlib. Then check if EOBS is missing or truncated. (LP 1889059) [Regression Potential] * There is a certain risk for regressions with the modifications that are introduced by the four LP bugs. * In case the package fails entirely, it will have (in worst case) an impact on all zlib, gzip and DFLTCC compression/decompression functions, that are very wide spread (gzip, tar cfz, everything with zlib) in Linux and would virtually make the system unusable. * If potential issues are limited to hardware assisted compression (which is more likely, since these patches are mostly about hw assisted compression), then issues would be limited to systems that provide this feature (latest s390x generation only). * A switch back to software got introduced (by setting DFLTCC=0 environment variable) that will help to mitigate a potential negative impact of the hw assisted compression. * Only the latest s390x generation (z15 and LinuxONE III) supports hardware assisted DFLTCC and is potentially affected. * A patched test package was made available and got successfully tested by IBM. All four bugs were finally considered as solved with zlib (1:1.2.11.dfsg-2ubuntu2~ppa2) available here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=zlib __ Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1884514] Re: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement
** Summary changed: - [20.10 FEAT] zlib/gzip hardware compression enablement + [FFe][20.10 FEAT] zlib/gzip hardware compression enablement ** Changed in: ubuntu-z-systems Status: In Progress => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [FFe][20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: Triaged Status in gzip package in Ubuntu: New Status in zlib package in Ubuntu: New Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1884514] Re: [20.10 FEAT] zlib/gzip hardware compression enablement
** Description changed: + [Feature Freeze Exception] + + 1. Feature: + + The latest s390x hardware comes with a new concept for hardware assisted + compression/decompression, based on a 'Next Accelerator Function unit' + (NXU). This is an on-chip concept, a co-processor for compression + available to all cores on the same chip. It provides functions as normal + 'problem state' instructions (in other words user space instructions + that are directly consumable by libraries and applications) and supports + DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. + + To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". + The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). + There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. + + 2. Changes + + Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro + during build of zlib and gzip. + + 3. Regression risk + + The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. + Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). + In case of unforeseen issues with the NXU hardware component, a fallback to software is done. + On top a modified zlib package was build and made available in a PPA for further testing. + This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. + __ + HW Compression need to be enabled with Default-Compression-Level 6. - Adding following CFLAGS attributes during build of zlib and gzip - "-DDFLTCC_LEVEL_MASK=0x7e" - + Adding following CFLAGS attributes during build of zlib and gzip + "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: In Progress Status in gzip package in Ubuntu: New Status in zlib package in Ubuntu: New Bug description: [Feature Freeze Exception] 1. Feature: The latest s390x hardware comes with a new concept for hardware assisted compression/decompression, based on a 'Next Accelerator Function unit' (NXU). This is an on-chip concept, a co-processor for compression available to all cores on the same chip. It provides functions as normal 'problem state' instructions (in other words user space instructions that are directly consumable by libraries and applications) and supports DEFLATE compliant compression/decompression + GZIP CRC/ZLIB Adler. To enable this hardware support for zlib and gzip, zlib needs to be compiled with CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e". The value of 0x7e enables hardware compression for the compression levels 1-6 (out of 0-9). There is a significant business value of having the enablement active by default, since tests on a system with 4 IFLs and hardware compression enabled this way offered (especially for DEFLATE as best case) a speed up of more than 40x. 2. Changes Adding CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" attributes/macro during build of zlib and gzip. 3. Regression risk The concept is new and comes with IBM z15 and LinuxONE III only and is with that specific and limited to s390x. Hence a potential regressions of this late addition would be limited to s390x and there again with the above changes to zlib (and gzip). In case of unforeseen issues with the NXU hardware component, a fallback to software is done. On top a modified zlib package was build and made available in a PPA for further testing. This change should have been included earlier, but was blocked by other zlib tickets/bugs that needed to be fixed and integrated first (like LP 1893170), hence this request for late addition. __ HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1884514] Re: [20.10 FEAT] zlib/gzip hardware compression enablement
** Information type changed from Private to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1884514 Title: [20.10 FEAT] zlib/gzip hardware compression enablement Status in Ubuntu on IBM z Systems: In Progress Status in gzip package in Ubuntu: New Status in zlib package in Ubuntu: New Bug description: HW Compression need to be enabled with Default-Compression-Level 6. Adding following CFLAGS attributes during build of zlib and gzip "-DDFLTCC_LEVEL_MASK=0x7e" CFLAGS="-O2 -DDFLTCC -DDFLTCC_LEVEL_MASK=0x7e" ./configure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1884514/+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 1799928] Re: [20.10 FEAT] openssl: RNG support
** Changed in: ubuntu-z-systems Status: In Progress => Fix Released -- 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/1799928 Title: [20.10 FEAT] openssl: RNG support Status in Ubuntu on IBM z Systems: Fix Released Status in openssl package in Ubuntu: Fix Released Bug description: Provide a CPACF based random number generator for openSSL using PRNO- SHA-512-DRNG to implement a NIST SP800-90A compliant SHA512 hash based deterministic random bit generator (DRBG) seeded true random numbers extracted using the PRNO-TRNG instruction. Planned with > openssl 1.1.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1799928/+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 1875300] Re: [Ubuntu 20.04 s390] Failed to install os from CD
Thank you Dominik for testing and confirming! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1875300 Title: [Ubuntu 20.04 s390] Failed to install os from CD Status in subiquity: Invalid Status in Ubuntu on IBM z Systems: Fix Released Status in casper package in Ubuntu: Fix Released Status in lvm2 package in Ubuntu: Fix Released Status in casper source package in Focal: Confirmed Status in lvm2 source package in Focal: Confirmed Status in casper source package in Groovy: Fix Released Status in lvm2 source package in Groovy: Fix Released Bug description: Failed to install os from CD ---Installation Media--- ubuntu-20.04-live-server-s390x.iso ---Machine type --- model: 8561 - T01 ---Steps--- Login to HMC Load CD via 'Load from Removable media or Serer' Select FTP After loaded successfully Get following message in Operating System Messages and installation failed: ln: /tmp/mountroot-fail-hooks.d//scripts/init-premount/lvm2: No such file or dir ectory To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1875300/+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 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it
** Tags added: ssc -- 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/1794478 Title: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it Status in Ubuntu on IBM z Systems: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Bionic: Fix Released Bug description: [Impact] In case creating bond interface, IPv4 address is not automatically assigned when IPv6 has manual setting. [Test Case] 1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as original description. 2. ipv6 manual, ipv4 auto ## sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup; sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, updelay=0"; sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses fe81::ff:fe97:a27f/64; sudo nmcli con mod bond0 ipv4.method auto; sudo nmcli con add type bond-slave ifname ens34 master bond0; sudo nmcli con add type bond-slave ifname ens35 master bond0; sudo nmcli con mod bond0 +bond.options mii=100 sleep 5 sudo nmcli con up bond-slave-ens34 sudo nmcli con up bond-slave-ens35 sudo nmcli con up bond0; sleep 5; sudo nmcli c s bond0 ## 3. ipv6 auto, ipv4 auto ## sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup; sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, updelay=0"; sudo nmcli con mod bond0 ipv6.method auto; sudo nmcli con mod bond0 ipv4.method auto; sudo nmcli con add type bond-slave ifname ens34 master bond0; sudo nmcli con add type bond-slave ifname ens35 master bond0; sudo nmcli con mod bond0 +bond.options mii=100 sleep 5 sudo nmcli con up bond-slave-ens34 sudo nmcli con up bond-slave-ens35 sudo nmcli con up bond0; sleep 5 sudo nmcli c s bond0 ## when run #3, it is working, but with #2, it is not working. [Potential Regression] Actually nothing special. fix just remove if statement. but it needs Network Manager restarted. [Other informations] After upstream fix, it is working fine with #2 and #3 above. * Upstream bug and fix: https://bugzilla.redhat.com/show_bug.cgi?id=1575944 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35 * Only affecting Bionic: $ git describe --contains f03ae35 1.10.8~2 $ rmadison network-manager ==> network-manager | 1.10.6-2ubuntu1.2 | bionic-updates network-manager | 1.20.4-2ubuntu2.2 | eoan-updates network-manager | 1.22.4-1ubuntu2 | focal [Original description] ---Problem Description--- Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get automatic ipv4 assigned from dhcp server. ---uname output--- Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 2018 s390x s390x s390x GNU/Linux Machine Type = s390x ---Debugger--- A debugger is not configured ---Steps to Reproduce--- When user configures ipv4 as automatic and ipv6 as manual for bond interface automatic ipv4 is not getting assigned. Looks like dhcp client request for ipv4 is not done to dhcp server after maunal ipv6 is assigned quickly to bond interface This issue will not happen in below cases: 1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan interface. 2)with ipv4 automatic and ipv6 automatic configuration for bond interface 3)with ipv4 automatic and ipv6 disabled configuration for bond interface Configuration: Bond interface, ipv4 automatic mode and ipv6 automatic mode root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond [connection] id=test_bond uuid=63e54542-5135-47ac-a954-b861c3937be2 type=bond interface-name=test_bond permissions= timestamp=1537944121 [ethernet] mac-address-blacklist= [bond] downdelay=0 fail_over_mac=none miimon=100 mode=active-backup num_grat_arp=0 primary_reselect=always updelay=0 [ipv4] dns-search= method=auto [ipv6] addr-gen-mode=stable-privacy dns-search= method=auto From /var/log/syslog, we can see ip got assigned: Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e) Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e) Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 10.2.3.1 Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from
[Touch-packages] [Bug 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Description changed: SRU Justification: == [Impact] - * This SRU fixes a combination of multiple issues: + * This SRU fixes a combination of multiple issues: - * HW Compression needs to be enabled with Default-Compression-Level 6, - by adding CFLAGS attribute "-DDFLTCC_LEVEL_MASK=0x7e" during build of - zlib and gzip. (LP 1884514) - - * zlib DFLTCC compression level switching can corrupt data because + * zlib DFLTCC compression level switching can corrupt data because hardware and software compression states become desynchronized. (LP 1893170) - * Since zlib is not working on all s390x system configurations support + * Since zlib is not working on all s390x system configurations support for switching between software and hardware compression is required especially for Java. (LP 1882494) - * zlib on s390x may produce incomplete raw streams (but not gzip/zlib). + * zlib on s390x may produce incomplete raw streams (but not gzip/zlib). (LP 1889059) [Test Case] - * Since especially DFLTCC requires a s390x generation z15 or LinuxONE + * Since especially DFLTCC requires a s390x generation z15 or LinuxONE III the tests need to be done by IBM. - * IBM has a set of tests available, that exercise public zlib APIs by + * IBM has a set of tests available, that exercise public zlib APIs by calling them in different sequences with different buffer sizes and flush modes. * Partially these come from the IBM z/OS team, who developed their own zlib support for the hardware accelerator, and partially they are developed by the IBM Linux team based on issues encountered during development as well as fuzzing. * IBM also uses the zlib-ng test-suite as well as squash and stress-ng. - * Compress data using zlib/DFLTCC with different compression level and + * Compress data using zlib/DFLTCC with different compression level and verify state and if data got corrupted or not. (LP 1893170) - * Check whether hardware compression was enabled for Default- - Compression-Level 6 after adding CFLAGS attribute - "-DDFLTCC_LEVEL_MASK=0x7e" while building zlib and gzip or not. (LP - 1884514) - - * On a system with patched zlib package, switch between hardware and + * On a system with patched zlib package, switch between hardware and software compression and use zlib via the java.util.zip package (http://java.sun.com/developer/technicalArticles/Programming/compression/). (LP 1882494) * On a z15 system with hardware acceleration compression (DFLTCC) enabled, create a raw (negative windowBits value) stream with zlib. Then check if EOBS is missing or truncated. (LP 1889059) [Regression Potential] - * There is a certain risk for regressions with the modifications that + * There is a certain risk for regressions with the modifications that are introduced by the four LP bugs. - * In case the package fails entirely, it will have (in worst case) an + * In case the package fails entirely, it will have (in worst case) an impact on all zlib, gzip and DFLTCC compression/decompression functions, that are very wide spread (gzip, tar cfz, everything with zlib) in Linux and would virtually make the system unusable. - * If potential issues are limited to hardware assisted compression + * If potential issues are limited to hardware assisted compression (which is more likely, since these patches are mostly about hw assisted compression), then issues would be limited to systems that provide this feature (latest s390x generation only). * A switch back to software got introduced (by setting DFLTCC=0 environment variable) that will help to mitigate a potential negative impact of the hw assisted compression. - * Only the latest s390x generation (z15 and LinuxONE III) supports + * Only the latest s390x generation (z15 and LinuxONE III) supports hardware assisted DFLTCC and is potentially affected. - * A patched test package was made available and got successfully tested + * A patched test package was made available and got successfully tested by IBM. All four bugs were finally considered as solved with zlib (1:1.2.11.dfsg-2ubuntu2~ppa2) available here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=zlib __ Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were
[Touch-packages] [Bug 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Description changed: + SRU Justification: + == + + [Impact] + + * This SRU fixes a combination of multiple issues: + + * HW Compression needs to be enabled with Default-Compression-Level 6, + by adding CFLAGS attribute "-DDFLTCC_LEVEL_MASK=0x7e" during build of + zlib and gzip. (LP 1884514) + + * zlib DFLTCC compression level switching can corrupt data because + hardware and software compression states become desynchronized. (LP + 1893170) + + * Since zlib is not working on all s390x system configurations support + for switching between software and hardware compression is required + especially for Java. (LP 1882494) + + * zlib on s390x may produce incomplete raw streams (but not gzip/zlib). + (LP 1889059) + + [Test Case] + + * Since especially DFLTCC requires a s390x generation z15 or LinuxONE + III the tests need to be done by IBM. + + * IBM has a set of tests available, that exercise public zlib APIs by + calling them in different sequences with different buffer sizes and + flush modes. + + * Partially these come from the IBM z/OS team, who developed their own + zlib support for the hardware accelerator, and partially they are + developed by the IBM Linux team based on issues encountered during + development as well as fuzzing. + + * IBM also uses the zlib-ng test-suite as well as squash and stress-ng. + + * Compress data using zlib/DFLTCC with different compression level and + verify state and if data got corrupted or not. (LP 1893170) + + * Check whether hardware compression was enabled for Default- + Compression-Level 6 after adding CFLAGS attribute + "-DDFLTCC_LEVEL_MASK=0x7e" while building zlib and gzip or not. (LP + 1884514) + + * On a system with patched zlib package, switch between hardware and + software compression and use zlib via the java.util.zip package + (http://java.sun.com/developer/technicalArticles/Programming/compression/). + (LP 1882494) + + * On a z15 system with hardware acceleration compression (DFLTCC) + enabled, create a raw (negative windowBits value) stream with zlib. Then + check if EOBS is missing or truncated. (LP 1889059) + + [Regression Potential] + + * There is a certain risk for regressions with the modifications that + are introduced by the four LP bugs. + + * In case the package fails entirely, it will have (in worst case) an + impact on all zlib, gzip and DFLTCC compression/decompression functions, + that are very wide spread (gzip, tar cfz, everything with zlib) in Linux + and would virtually make the system unusable. + + * If potential issues are limited to hardware assisted compression + (which is more likely, since these patches are mostly about hw assisted + compression), then issues would be limited to systems that provide this + feature (latest s390x generation only). + + * A switch back to software got introduced (by setting DFLTCC=0 + environment variable) that will help to mitigate a potential negative + impact of the hw assisted compression. + + * Only the latest s390x generation (z15 and LinuxONE III) supports + hardware assisted DFLTCC and is potentially affected. + + * A patched test package was made available and got successfully tested + by IBM. All four bugs were finally considered as solved with zlib + (1:1.2.11.dfsg-2ubuntu2~ppa2) available here: + https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=zlib + + __ + Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project -does not accept patches at the moment, the fix has been -integrated into the DFLTCC pull request: -https://github.com/madler/zlib/pull/410 -The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. + does not accept patches at the moment, the fix has been + integrated into the DFLTCC pull request: + https://github.com/madler/zlib/pull/410 + The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were -discovered using example_call_fuzzer from: -https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ + discovered using example_call_fuzzer from: + https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: New Status in zlib source
[Touch-packages] [Bug 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
Thanks for testing, Ilya. With that we now have a patches zlib (1:1.2.11.dfsg-2ubuntu2~ppa2) package that was verified to fix not only this LP 1893170, but also LP 1884514, LP 1882494 and LP 1889059. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Changed in: ubuntu-z-systems Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1886814] Re: posix_spawn usage in gnu make causes failures on s390x
** Changed in: ubuntu-z-systems Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to make-dfsg in Ubuntu. https://bugs.launchpad.net/bugs/1886814 Title: posix_spawn usage in gnu make causes failures on s390x Status in Ubuntu on IBM z Systems: Fix Released Status in flatpak package in Ubuntu: Fix Released Status in glibc package in Ubuntu: Invalid Status in linux package in Ubuntu: Invalid Status in make-dfsg package in Ubuntu: Invalid Bug description: posix_spawn usage in gnu make causes failures on s390x Recently in gnu-make v4.3 https://paste.ubuntu.com/p/tYhbJFKN76/ it started to use posix_spawn, instead of fork()/exec(). This has caused failure of an unrelated package flatpak-builder autopkgtests on s390x only, like so echo Building make: echo: Operation not permitted make: *** [Makefile:2: all] Error 127 Julian Klaude investigated this in-depth. His earlier research also indicated that this is a heisenbug, if one tries to print to stderr before printing to stdout, no issue occurs. We are configuring GNU make to be build with --disable-posix-spawn on s390x only. We passed these details to Debian https://bugs.debian.org /cgi-bin/bugreport.cgi?bug=964541 too. But I do wonder, if there is something different or incorrect about posix_spawn() implementation in either glibc, or linux kernel, on s390x. Or gnu-make's usage of posix_spawn(). As otherise, using posix_spawn() in gnu-make works on other architectures, and flatpak-builder autopkgtests pass too. It seems very weird that stdout does not appear to be functional, unless stderr was opened/written to, from gnu-make execution compiled with posix-spawn feature. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1886814/+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 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1882494] Re: [UBUNTU 20.04] zlib not working on all s390x systems configurations
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1882494 Title: [UBUNTU 20.04] zlib not working on all s390x systems configurations Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: New Status in zlib source package in Eoan: Won't Fix Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Pull request (https://github.com/madler/zlib/pull/410) and tagged https://github.com/iii-i/zlib/tree/dfltcc-20200511. The new code contains the following improvements: * Added support for switching between software and hardware compression. * Added --dfltcc configure flag (the old way of building it still works). Switching between software and hardware compression is not simply a nice-to-have feature, but is actually required by Java - that's why we are requesting an update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1882494/+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 1875300] Re: [Ubuntu 20.04 s390] Failed to install os from CD
Please take the latest Ubuntu Server Live image 20.04.1: http://cdimage.ubuntu.com/cdimage/ubuntu/releases/20.04.1/release/ubuntu-20.04.1-live-server-s390x.iso With the recent changes in the casper component of the installer (LP 1854513 and LP 1884933) this is should be fixed now - but the minimum levels are 20.04.1 or 20.10. ** Changed in: ubuntu-z-systems Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1875300 Title: [Ubuntu 20.04 s390] Failed to install os from CD Status in subiquity: Invalid Status in Ubuntu on IBM z Systems: Fix Released Status in casper package in Ubuntu: Fix Released Status in lvm2 package in Ubuntu: Fix Released Status in casper source package in Focal: Confirmed Status in lvm2 source package in Focal: Confirmed Status in casper source package in Groovy: Fix Released Status in lvm2 source package in Groovy: Fix Released Bug description: Failed to install os from CD ---Installation Media--- ubuntu-20.04-live-server-s390x.iso ---Machine type --- model: 8561 - T01 ---Steps--- Login to HMC Load CD via 'Load from Removable media or Serer' Select FTP After loaded successfully Get following message in Operating System Messages and installation failed: ln: /tmp/mountroot-fail-hooks.d//scripts/init-premount/lvm2: No such file or dir ectory To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1875300/+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 1893170] Re: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Also affects: zlib (Ubuntu Groovy) Importance: Undecided Assignee: Skipper Bug Screeners (skipper-screen-team) Status: New ** Also affects: zlib (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1893170 Title: [Ubuntu 20.10] zlib: DFLTCC compression level switching issues Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Description: zlib: DFLTCC compression level switching issues Symptom: Switching compression levels corrupts data Problem: Hardware and software compression states become desynchronized. Solution: Improve compression state synchronization. Since zlib project does not accept patches at the moment, the fix has been integrated into the DFLTCC pull request: https://github.com/madler/zlib/pull/410 The commitid is 992a7afc3edfa511dff0650d1c545b11bf64e655. Reproduction: Not possible with popular command line tools. The issues were discovered using example_call_fuzzer from: https://github.com/iii-i/zlib-ng/tree/fuzz/test/fuzz/ This needs also be applied against 20.04 ! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1893170/+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 1889059] Re: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1889059 Title: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams Status in Ubuntu on IBM z Systems: In Progress Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: zlib on s390x may produce incomplete raw (but not gzip/zlib) streams ---uname output--- Linux t35lp56.lnxne.boe 5.8.0-20200703.rc3.git0.52a479d42203.300.fc31.s390x #1 SMP Fri Jul 3 00:46:20 CEST 2020 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Create a raw (negative windowBits value) stream with zlib. EOBS might be missing or truncated. This affects all distro levels that contain hardware acceleration (DFLTCC) patch. I've attached the preliminary fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889059/+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 1889059] Re: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams
** Changed in: ubuntu-z-systems Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1889059 Title: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams Status in Ubuntu on IBM z Systems: Triaged Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: zlib on s390x may produce incomplete raw (but not gzip/zlib) streams ---uname output--- Linux t35lp56.lnxne.boe 5.8.0-20200703.rc3.git0.52a479d42203.300.fc31.s390x #1 SMP Fri Jul 3 00:46:20 CEST 2020 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Create a raw (negative windowBits value) stream with zlib. EOBS might be missing or truncated. This affects all distro levels that contain hardware acceleration (DFLTCC) patch. I've attached the preliminary fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889059/+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 1882494] Re: [UBUNTU 20.04] zlib not working on all s390x systems configurations
Can be tested based on LP 1889059 and the package referenced there in comment #9 ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1882494 Title: [UBUNTU 20.04] zlib not working on all s390x systems configurations Status in Ubuntu on IBM z Systems: Triaged Status in zlib package in Ubuntu: New Status in zlib source package in Eoan: Won't Fix Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: Pull request (https://github.com/madler/zlib/pull/410) and tagged https://github.com/iii-i/zlib/tree/dfltcc-20200511. The new code contains the following improvements: * Added support for switching between software and hardware compression. * Added --dfltcc configure flag (the old way of building it still works). Switching between software and hardware compression is not simply a nice-to-have feature, but is actually required by Java - that's why we are requesting an update. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1882494/+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 1889059] Re: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams
Due to the work on the point releases (20.04.1 and 18.04.5 within 2 weeks) there is some delay on this. But the maintaining team is aware of this... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1889059 Title: [Ubuntu 20.04] zlib on s390x may produce incomplete raw (but not gzip/zlib) streams Status in Ubuntu on IBM z Systems: New Status in zlib package in Ubuntu: New Status in zlib source package in Focal: New Status in zlib source package in Groovy: New Bug description: zlib on s390x may produce incomplete raw (but not gzip/zlib) streams ---uname output--- Linux t35lp56.lnxne.boe 5.8.0-20200703.rc3.git0.52a479d42203.300.fc31.s390x #1 SMP Fri Jul 3 00:46:20 CEST 2020 s390x s390x s390x GNU/Linux Machine Type = z15 ---Debugger--- A debugger is not configured ---Steps to Reproduce--- Create a raw (negative windowBits value) stream with zlib. EOBS might be missing or truncated. This affects all distro levels that contain hardware acceleration (DFLTCC) patch. I've attached the preliminary fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1889059/+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 1873961] Re: tc filter show tcp_flags wrong mask value
** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1873961 Title: tc filter show tcp_flags wrong mask value Status in The Ubuntu-power-systems project: Fix Committed Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Bionic: Fix Committed Bug description: [SRU Justification] Impact: The tc command does not show the correct values for tcp_flags (and ip_tos) on filter rules. This might break other scripts parsing that output but at least confuses users. Fix: Backport of "tc: fix bugs for tcp_flags and ip_attr hex output" from upstream iproute2. Testcase: tc qdisc add dev lo ingress tc filter add dev lo parent : prio 3 proto ip flower ip_tos 0x8/32 tc filter add dev lo parent : prio 5 proto ip flower ip_proto tcp \ tcp_flags 0x909/f00 tc filter show dev lo parent : filter protocol ip pref 3 flower chain 0 filter protocol ip pref 3 flower chain 0 handle 0x1 eth_type ipv4 ip_tos a9606c10 <-- bad, should be 0x8/32 not_in_hw filter protocol ip pref 5 flower chain 0 filter protocol ip pref 5 flower chain 0 handle 0x1 eth_type ipv4 ip_proto tcp tcp_flags 909909 <-- bad, should be 0x909/f00 not_in_hw Note that the ip_tos value in the -j[son] output is correct, while the tcp_flags value is is incorrect in both cases. Risk of Regression: Low: Usually scripts would use the json output and that has at least the ip output correct. And the values shown in the bad case seem to be little useful. So it seems unlikely anybody relied on them. But cannot completely be ruled out. === Original description === ---Problem Description--- Problem Descriptions "tc" utility does not show correct TC rule's tcp_flags mask correctly in current "iproute2" package shipped on Genesis. # dpkg -l |grep iproute2 ii iproute2 4.15.0-2ubuntu1 ppc64el networking and traffic control tools ---Steps to Reproduce--- Steps to reproduce the problem: 1) Add a tc rule to the testing VF (i.e. p0v2_r): # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 2 skip_sw action mirred egress redirect dev p0v0_r 2) Validate the added TC rule: # tc filter show dev p0v2_r root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 22 /* <--- Wrong */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen 3) If we add the tcp_flags using explicit mask 0x7: # tc filter add dev p0v2 protocol ip parent : pref 5 chain 1 handle 0x1 flower src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff ip_proto tcp tcp_flags 0x2/7 skip_sw action mirred egress redirect dev p0v0_r After that, using "tc filter show dev p0v2_r root" to verify, we still see the same output (tcp_flags 22) as shown in 2) above, which is wrong. Userspace tool common name: tc The userspace tool has the following bit modes: 64-bit Userspace package: iproute2 == Fixes: There are 2 patches to fix the issue: patch 1: commit b85076cd74e77538918d35992b1a9cd17ff86af8 Author: Stephen Hemminger Date: Tue Sep 11 08:29:33 2018 -0700 lib: introduce print_nl Common pattern in iproute commands is to print a line seperator in non-json mode. Make that a simple function. /* This patch declares global variable "const char *_SL_ = "\n";" in lib/utils.c to be used by 2nd patch */ patch 2: commit e8bd395508cead5a81c2bebd9d3705a9e41ea8bc Author: Keara Leibovitz Date: Thu Jul 26 09:45:30 2018 -0400 tc: fix bugs for tcp_flags and ip_attr hex output Fix hex output for both the ip_attr and tcp_flags print functions. With the above 2 patches pull in, the new "tc" utility will show the correct tcp_flags mask: # tc filter show dev p0v2 root filter protocol ip pref 5 flower chain 1 filter protocol ip pref 5 flower chain 1 handle 0x1 src_mac 00:00:00:00:4e:2f/00:00:00:ff:ff:ff eth_type ipv4 ip_proto tcp tcp_flags 0x2/7 /* <--- Correct */ skip_sw in_hw action order 1: mirred (Egress Redirect to device p0v0_r) stolen This bug affects tc in Ubuntu 18.04.1 stock image. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1873961/+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
