[Touch-packages] [Bug 1943818] Re: mesa built with -O3 on ppc64el has broken EGL

2021-09-16 Thread Frank Heimes
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1943818

Title:
  mesa built with -O3 on ppc64el has broken EGL

Status in Mesa:
  Unknown
Status in The Ubuntu-power-systems project:
  New
Status in gcc-11 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New

Bug description:
  If mesa is built with -O3 then EGL will fail with:

  libEGL warning: DRI2: failed to create any config

  this can be easily reproduced by building libepoxy which then runs a
  series of tests.

  The same is fine on amd64, and also ppc64el is fine with gcc-10 and
  -O3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1943818/+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

2021-09-09 Thread Frank Heimes
After upgrading my systems to hirsute I was able to successfully validate on 
hirsute, too.
Adjusting the tags accordingly ...

** Tags removed: verification-needed verification-needed-hirsute
** Tags added: verification-done verification-done-hirsute

-- 
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:
  Fix Committed
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Committed
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Committed
Status in netplan.io source package in Impish:
  Confirmed
Status in systemd source package in Impish:
  Fix Committed

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 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode

2021-09-09 Thread Frank Heimes
I was able to verify this on focal in a little z/VM env. that I've setup (it's 
a little bit different to the setup that was used by the initial reporter, but 
close enough).
So I'm updating the focal tag.
(will then upgrade to hirsute and redo - sorry this way it's less work for me)

** 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/1914740

Title:
  IPs are not assigned for Hipersockets in DHCP mode

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Committed
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Committed
Status in netplan.io source package in Impish:
  Confirmed
Status in systemd source package in Impish:
  Fix Committed

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 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode

2021-09-02 Thread Frank Heimes
** 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 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:
  Fix Committed
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Committed
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  Fix Committed
Status in netplan.io source package in Impish:
  Confirmed
Status in systemd source package in Impish:
  Fix Committed

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 1932010] Re: [21.10 FEAT] zlib CRC32 optimization for s390x

2021-08-27 Thread Frank Heimes
** 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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in zlib package in Ubuntu:
  Fix Released

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1929184] Re: [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

2021-08-19 Thread Frank Heimes
The modified version already landed in -proposed.
Hence updating the status to Fix Committed.

** Changed in: systemd (Ubuntu)
   Status: In Progress => 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1929184

Title:
  [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  Feature Description:  
  - Interface names for RoCE Express adapters are currently very hard to 
predict, causing problems with the installer which requires knowledge of the 
interface name
  - Interface names can change between re-boots, invalidating any previously 
stored network card configuration
  To fix this requires changes in the Linux kernel to indicate whether UIDs are 
unique (and therefore usable), and in systemd to generate an interface name 
based on UIDs all the time.

  Business Case:
  Increase usability, lower service efforts.

  The code is in the upstream repository and should eventually be
  contained in the upcoming systemd release 249

  a496a23 udev: fix slot based network names on s390
  b08c3fb udev: add missing initialization to fix freeing invalid address
  5a7eb46 udev: allow onboard index up to 65535

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929184/+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 1931725] Re: initramfs-tools & kernel: use zstd as the default compression method

2021-08-18 Thread Frank Heimes
** Tags added: bot-stop-nagging

** 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 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:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Incomplete

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 1929184] Re: [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

2021-08-17 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Triaged => In Progress

** No longer affects: ubuntu-release-notes

-- 
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/1929184

Title:
  [21.10 FEAT] RoCE: Predictable Interface Names - systemd part

Status in Ubuntu on IBM z Systems:
  In Progress
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  Feature Description:  
  - Interface names for RoCE Express adapters are currently very hard to 
predict, causing problems with the installer which requires knowledge of the 
interface name
  - Interface names can change between re-boots, invalidating any previously 
stored network card configuration
  To fix this requires changes in the Linux kernel to indicate whether UIDs are 
unique (and therefore usable), and in systemd to generate an interface name 
based on UIDs all the time.

  Business Case:
  Increase usability, lower service efforts.

  The code is in the upstream repository and should eventually be
  contained in the upcoming systemd release 249

  a496a23 udev: fix slot based network names on s390
  b08c3fb udev: add missing initialization to fix freeing invalid address
  5a7eb46 udev: allow onboard index up to 65535

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1929184/+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 1932010] Re: [21.10 FEAT] zlib CRC32 optimization for s390x

2021-08-17 Thread Frank Heimes
Since the updated package version arrived in impish-proposed:
 zlib | 1:1.2.11.dfsg-2ubuntu7   | impish-proposed | source
I'm updating the status to Fix Committed.

** Changed in: zlib (Ubuntu)
   Status: In Progress => 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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in zlib package in Ubuntu:
  Fix Committed

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs in the s390x AES code

2021-08-10 Thread Frank Heimes
** 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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1931994

Title:
  [Ubuntu 20.04] OpenSSL bugs in the s390x AES code

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  Fix Released
Status in openssl source package in Focal:
  Fix Released
Status in openssl source package in Hirsute:
  Fix Released
Status in openssl source package in Impish:
  Fix Released

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  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

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

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 1932010] Re: [21.10 FEAT] zlib CRC32 optimization for s390x

2021-08-10 Thread Frank Heimes
** 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/1932010

Title:
  [21.10 FEAT] zlib CRC32 optimization for s390x

Status in Ubuntu on IBM z Systems:
  In Progress
Status in zlib package in Ubuntu:
  In Progress

Bug description:
  Use SIMD instructions to accelerate the zlib CRC32 implementation.
  Business value: Performance improvement in database area

  The zlib CRC32 optimization for IBM Z is currently being discussed for 
inclusion into zlib-ng:
  https://github.com/zlib-ng/zlib-ng/pull/912

  The patch for zlib will be based on that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1932010/+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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs in the s390x AES code

2021-08-09 Thread Frank Heimes
Sorry for the late response, but was quite busy.
Yes I always have some systems in place (@schopin you can always ping me per MM 
is s/t is needed).

I just did the verifications for hirsute and focal and both are fine:

ubuntu@h7:~$ arch && lsb_release -c
s390x
Codename:   hirsute
ubuntu@h7:~$ apt-cache policy openssl
openssl:
  Installed: 1.1.1j-1ubuntu3.2
  Candidate: 1.1.1j-1ubuntu3.2
  Version table:
 *** 1.1.1j-1ubuntu3.2 500
500 http://us.ports.ubuntu.com/ubuntu-ports hirsute-proposed/main s390x 
Packages
100 /var/lib/dpkg/status
 1.1.1j-1ubuntu3 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/main s390x Packages
ubuntu@h7:~$ gcc test.c -o evc-test -lcrypto -lssl
ubuntu@h7:~$ ./evc-test && echo OK
OK
ubuntu@h7:~$


ubuntu@s15:~$ arch && lsb_release -c
s390x
Codename:   focal
ubuntu@s15:~$ apt-cache policy openssl
openssl:
  Installed: 1.1.1f-1ubuntu2.5
  Candidate: 1.1.1f-1ubuntu2.5
  Version table:
 *** 1.1.1f-1ubuntu2.5 500
500 http://us.ports.ubuntu.com/ubuntu-ports focal-proposed/main s390x 
Packages
500 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main s390x 
Packages
100 /var/lib/dpkg/status
 1.1.1f-1ubuntu2.4 500
500 http://ports.ubuntu.com/ubuntu-ports focal-updates/main s390x 
Packages
 1.1.1f-1ubuntu2.3 500
500 http://ports.ubuntu.com/ubuntu-ports focal-security/main s390x 
Packages
 1.1.1f-1ubuntu2 500
500 http://ports.ubuntu.com/ubuntu-ports focal/main s390x Packages
ubuntu@s15:~$ gcc test.c -o evc-test -lcrypto -lssl
ubuntu@s15:~$ ./evc-test && echo OK
OK
ubuntu@s15:~$

I'm updating the tags accordingly ...

** Tags removed: verification-needed verification-needed-focal 
verification-needed-hirsute
** Tags added: verification-done verification-done-focal 
verification-done-hirsute

-- 
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 in the s390x AES code

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  Fix Committed
Status in openssl source package in Focal:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Committed
Status in openssl source package in Impish:
  Fix Released

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  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

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs in the s390x AES code

2021-07-30 Thread Frank Heimes
** 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 openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1931994

Title:
  [Ubuntu 20.04] OpenSSL bugs in the s390x AES code

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Bionic:
  Fix Committed
Status in openssl source package in Focal:
  Fix Committed
Status in openssl source package in Hirsute:
  Fix Committed
Status in openssl source package in Impish:
  Fix Released

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  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

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

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 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)

2021-07-28 Thread Frank Heimes
** Changed in: linux (Ubuntu)
   Status: New => Invalid

** Changed in: netplan.io (Ubuntu)
   Status: New => Invalid

** Changed in: systemd (Ubuntu)
   Status: New => Invalid

** 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 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:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in netplan.io package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid

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
  

[Touch-packages] [Bug 1929657] Re: [Ubuntu 20.4.2] vLan not getting static IP assigned (on s390x)

2021-07-28 Thread Frank Heimes
Hi Mario, thanks for coming back to this case.
So it seems that the situation is now good again - now that the 
/etc/systemd/network/10-enP53p0s0.link got removed.

We don't know a tool or application offhand that would create such a .link file 
in /etc/systemd/network/ alone.
However, there are plenty of tools that generate files in this context, like 
netplan, udev, NetworkManager, etc. - but then such automatically created files 
would be usually located at /run/systemd/network - /etc is more for manually 
created ones.

Maybe this was caused by a less common tool that does not stick to this 
(de-facto) standard.
Or maybe it got copied there by accident, while backing up files or so - 
difficult to say.
We at least don't imagine a case where such a file is created by the standard 
Ubuntu tooling.

You didn't had a chance to grab the stats for that file before having
removed it, did you?


Do you agree that the bug can be closed now based on finding the cause (the 
.link) file, having it removed and now the system behaving as expected again?

-- 
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 

[Touch-packages] [Bug 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code

2021-07-27 Thread Frank Heimes
@schopin that is a (known) issue with the bugzilla-launchpad bridge that is in 
place here (bugproxy is the functional user id for this).
I'll ask to get the "Standalone C program from the upstream test case" 
attachment removed on the bugzilla side, that should help ...

-- 
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:
  In Progress
Status in openssl package in Ubuntu:
  Fix Committed
Status in openssl source package in Bionic:
  New
Status in openssl source package in Focal:
  New
Status in openssl source package in Hirsute:
  New
Status in openssl source package in Impish:
  Fix Committed

Bug description:
  Problem description:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  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

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

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 1914740] Re: IPs are not assigned for Hipersockets in DHCP mode

2021-07-26 Thread Frank Heimes
** Changed in: ubuntu-z-systems
   Status: Incomplete => In Progress

-- 
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:
  In Progress
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  In Progress
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  In Progress
Status in netplan.io source package in Hirsute:
  New
Status in systemd source package in Hirsute:
  In Progress
Status in netplan.io source package in Impish:
  Confirmed
Status in systemd source package in Impish:
  In Progress

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 1931994] Re: [Ubuntu 20.04] OpenSSL bugs im s390x AES code

2021-07-26 Thread Frank Heimes
** 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 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:
  In Progress
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:

  When passing a NULL key to reset AES EVC state, the state wouldn't be 
completely reset on s390x.
  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

  [Test plan]

  $ sudo apt install libssl-dev
  $ gcc test.c -o evc-test -lcrypto -lssl # See 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1931994/comments/2 for 
the test.c program
  $ ./evc-test && echo OK

  [Where problems could occur]

  This patch only touches s390x code paths, so there shouldn't be any 
regression on other architectures. However, on s390x this could reveal
  latent bugs by spreading a NULL key to new code paths.

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 1935617] Re: systemd autopkgtest broken on ppc64el with qemu 6.0

2021-07-12 Thread Frank Heimes
** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Tags added: ppc64el reverse-proxy-bugzilla

** Changed in: ubuntu-power-systems
 Assignee: (unassigned) => bugproxy (bugproxy)

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

-- 
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/1935617

Title:
  systemd autopkgtest broken on ppc64el with qemu 6.0

Status in The Ubuntu-power-systems project:
  New
Status in qemu package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm not sure yet if this is flaky or a real issue, but I'm filing it
  to avoid multiple people analyzing the same.

  The Qemu 6.0 upload 
https://launchpad.net/ubuntu/+source/qemu/1:6.0+dfsg-1~ubuntu2 triggers a test 
failure like
  
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/ppc64el/s/systemd/20210708_223311_e3bbb@/log.gz

  I have tested the new qemu on ppc64 and it worked fine for device emulation 
and migration cases.
  But this is suspicious.
  Of the last tests exactly and only those with the new qemu failed.

  
  impish
ppc64el
  tests-in-lxd   (F  5% f  0% S  0% B  0% => P 95%/) 
F.F.
  systemd-fsckd  (F  0% f  0% S 100% B  0% => P  0%/) 

  upstream-1 (F 15% f  0% S  0% B  0% => P 85%/) 
F..F
  upstream-2 (F 12% f  0% S  0% B  0% => P 87%/) 
F...

  
  For an insight in flakyness/reproducibility I've retriggered the missing qemu 
and the non-qemu cases a few times. If those reproduce all-bad vs all-good 
again this would further indicate a real issue.

  Unfortunately the ppc maas seems down right now and canonistack also
  isn't too nice this week - overall that inhibits the testing a bit :-/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1935617/+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)

2021-07-12 Thread Frank Heimes
@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

2021-07-01 Thread Frank Heimes
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)

2021-06-25 Thread Frank Heimes
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)

2021-06-17 Thread Frank Heimes
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)

2021-06-17 Thread Frank Heimes
** 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

2021-06-15 Thread Frank Heimes
** 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)

2021-06-15 Thread Frank Heimes
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

2021-06-15 Thread Frank Heimes
** 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

2021-06-14 Thread Frank Heimes
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)

2021-06-10 Thread Frank Heimes
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)

2021-06-10 Thread Frank Heimes
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

2021-06-01 Thread Frank Heimes
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

2021-05-31 Thread Frank Heimes
** 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

2021-05-31 Thread Frank Heimes
*** 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

2021-04-23 Thread Frank Heimes
** 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

2021-04-20 Thread Frank Heimes
** 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

2021-04-20 Thread Frank Heimes
** 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

2021-04-14 Thread Frank Heimes
** 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

2021-04-07 Thread Frank Heimes
** 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

2021-04-01 Thread Frank Heimes
** 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

2021-03-31 Thread Frank Heimes
** 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

2021-03-31 Thread Frank Heimes
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

2021-03-01 Thread Frank Heimes
** 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

2021-02-26 Thread Frank Heimes
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

2021-02-25 Thread Frank Heimes
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

2021-02-19 Thread Frank Heimes
** 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

2021-02-18 Thread Frank Heimes
** 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)

2021-02-18 Thread Frank Heimes
** 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

2021-02-08 Thread Frank Heimes
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)

2021-02-05 Thread Frank Heimes
** 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)

2021-02-04 Thread Frank Heimes
** 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

2021-01-29 Thread Frank Heimes
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)

2021-01-28 Thread Frank Heimes
** 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

2021-01-28 Thread Frank Heimes
** 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)

2021-01-21 Thread Frank Heimes
** 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

2021-01-21 Thread Frank Heimes
** 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

2021-01-21 Thread Frank Heimes
** 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

2021-01-21 Thread Frank Heimes
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)

2021-01-21 Thread Frank Heimes
** 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)

2021-01-20 Thread Frank Heimes
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)

2021-01-19 Thread Frank Heimes
** 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)

2021-01-19 Thread Frank Heimes
+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

2021-01-08 Thread Frank Heimes
** 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

2021-01-07 Thread Frank Heimes
** 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

2021-01-07 Thread Frank Heimes
** 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

2021-01-07 Thread Frank Heimes
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

2021-01-07 Thread Frank Heimes
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

2021-01-01 Thread Frank Heimes
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

2020-12-31 Thread Frank Heimes
** 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

2020-12-31 Thread Frank Heimes
** 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

2020-12-20 Thread Frank Heimes
** 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

2020-12-20 Thread Frank Heimes
** 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

2020-12-17 Thread Frank Heimes
** 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

2020-12-09 Thread Frank Heimes
** 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)

2020-12-09 Thread Frank Heimes
** 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)

2020-11-16 Thread Frank Heimes
** 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

2020-11-11 Thread Frank Heimes
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

2020-11-05 Thread Frank Heimes
** 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

2020-11-05 Thread Frank Heimes
** 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

2020-11-02 Thread Frank Heimes
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)

2020-10-26 Thread Frank Heimes
** 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

2020-10-21 Thread Frank Heimes
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

2020-10-19 Thread Frank Heimes
** 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

2020-10-19 Thread Frank Heimes
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

2020-10-16 Thread Frank Heimes
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

2020-10-16 Thread Frank Heimes
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

2020-10-13 Thread Frank Heimes
** 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

2020-10-13 Thread Frank Heimes
** 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

2020-10-12 Thread Frank Heimes
** 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

2020-10-08 Thread Frank Heimes
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

2020-10-07 Thread Frank Heimes
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

2020-10-05 Thread Frank Heimes
** 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

2020-10-05 Thread Frank Heimes
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

2020-10-05 Thread Frank Heimes
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

2020-10-05 Thread Frank Heimes
** 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

2020-10-01 Thread Frank Heimes
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

2020-09-28 Thread Frank Heimes
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

2020-09-25 Thread Frank Heimes
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

2020-09-25 Thread Frank Heimes
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

2020-09-25 Thread Frank Heimes
** 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

2020-09-24 Thread Frank Heimes
** 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


  1   2   3   4   5   >