[Touch-packages] [Bug 1943441] Re: lxc: lxc-test-parse-config-file failure

2021-09-20 Thread Krzysztof Kozlowski
Found on impish/linux-oracle/5.13.0-1005.7

** Also affects: ubuntu-kernel-tests
   Importance: Undecided
   Status: New

** Tags added: 5.13 amd64 impish linux-kvm oracle sru-20210906 ubuntu-
lxc

** Tags added: hinted

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

Title:
  lxc: lxc-test-parse-config-file failure

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  In Progress

Bug description:
  I'm getting the following error with the lxc kernel autotest on
  impish:

  08:46:04 DEBUG| parse_config_file.c: 60: set_get_compare_clear_save_load: 
expected value "system_u:system_r:lxc_t:s0:c22" and retrieved value "" for 
config key "lxc.selinux.context" do not match
  08:46:04 DEBUG|
  08:46:04 DEBUG| parse_config_file.c: 382: main: lxc.selinux.context
  08:46:06 INFO | ERRORubuntu_lxc.lxc-test-parse-config-file
ubuntu_lxc.lxc-test-parse-config-filetimestamp=1631090766localtime=Sep 
08 08:46:06Command  failed, rc=1, Command returned non-zero exit status
* Command:
/tmp/lxc-pkg-ubuntu/src/tests/lxc-test-parse-config-file
Exit status: 1
Duration: 0.0550210475922

stderr:
parse_config_file.c: 60: set_get_compare_clear_save_load: expected value 
"system_u:system_r:lxc_t:s0:c22" and retrieved value "" for config key 
"lxc.selinux.context" do not match

parse_config_file.c: 382: main: lxc.selinux.context

  I haven't investigated very much, but it looks like a
  (mis)configuration change / issue. Does it ring any bell? Otherwise
  I'll investigate more.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1943441/+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-09-02 Thread Krzysztof Kozlowski
** Also affects: linux-oracle (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux-oracle (Ubuntu)
   Status: New => Fix Committed

-- 
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:
  Fix Released
Status in linux-oracle package in Ubuntu:
  Fix Committed

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 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

2021-07-31 Thread Krzysztof Kozlowski
Found on bionic/azure-5.4 5.4.0-1056.58~18.04.1 (and previous cycle
5.4.0-1054.56~18.04.1)

** Tags added: azure sru-20210719

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

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Confirmed

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-07-19 Thread Krzysztof Kozlowski
** Changed in: linux (Ubuntu Xenial)
   Status: New => Invalid

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

** Changed in: linux-azure (Ubuntu)
   Status: New => Invalid

** Changed in: linux-azure (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: linux-azure (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: linux (Ubuntu)
   Status: Incomplete => Invalid

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

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in linux-azure package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Invalid
Status in linux-azure source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  Invalid
Status in linux-azure source package in Bionic:
  Invalid
Status in systemd source package in Bionic:
  Invalid

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-07-19 Thread Krzysztof Kozlowski
** Changed in: ubuntu-kernel-tests
   Status: In Progress => 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/1783881

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  Fix Released
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  Invalid

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

2021-07-06 Thread Krzysztof Kozlowski
Found on groovy/azure groovy/azure 5.8.0-1038.40


** Tags added: sru-20210621

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

Title:
  lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed

Bug description:
  We seem to get failed dep8 testing on lxc in Groovy for a while. What
  we are interested in is knowing whether this is known problems in the
  testing or something that waits on kernel fixes (who would be driving
  those if this is the case).

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1917601/+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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-07-01 Thread Krzysztof Kozlowski
** Tags added: sru-20210621

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

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  In Progress
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  Invalid

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-06-22 Thread Krzysztof Kozlowski
Sent patch to upstream (LTP):
https://lists.linux.it/pipermail/ltp/2021-June/023346.html

** Changed in: ubuntu-kernel-tests
   Status: Triaged => 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/1783881

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  In Progress
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-06-22 Thread Krzysztof Kozlowski
** Changed in: ubuntu-kernel-tests
 Assignee: Sean Feole (sfeole) => Krzysztof Kozlowski (krzk)

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

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  Triaged
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

2021-06-21 Thread Krzysztof Kozlowski
Found on groovy/aws 5.8.0-1036.38

** Tags added: aws

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

Title:
  lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed

Bug description:
  We seem to get failed dep8 testing on lxc in Groovy for a while. What
  we are interested in is knowing whether this is known problems in the
  testing or something that waits on kernel fixes (who would be driving
  those if this is the case).

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1917601/+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 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

2021-06-17 Thread Krzysztof Kozlowski
Found on groovy/oracle 5.8.0-1032.33

** Tags added: oracle

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

Title:
  lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed

Bug description:
  We seem to get failed dep8 testing on lxc in Groovy for a while. What
  we are interested in is knowing whether this is known problems in the
  testing or something that waits on kernel fixes (who would be driving
  those if this is the case).

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1917601/+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 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

2021-06-17 Thread Krzysztof Kozlowski
Found on groovy/azure 5.8.0-1034.36

** Tags added: azure

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

Title:
  lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed

Bug description:
  We seem to get failed dep8 testing on lxc in Groovy for a while. What
  we are interested in is knowing whether this is known problems in the
  testing or something that waits on kernel fixes (who would be driving
  those if this is the case).

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1917601/+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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-05-07 Thread Krzysztof Kozlowski
Found on focal/azure-5.8 5.8.0-1031.33~20.04.1

** Tags added: sru-20210412

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

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  Triaged
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+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 Krzysztof Kozlowski
** Description changed:

+ [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.
+ 
+ [Test Plan]
+ 
  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
+ 
+ [Where problems could occur]
+ 
+ * Installing kernel via: installkernel or "make install", so mostly
+ kernel developer environments

** Also affects: debianutils (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: linux-base (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: debianutils (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: linux-base (Ubuntu Hirsute)
   Importance: Medium
 Assignee: Stefan Bader (smb)
   Status: In Progress

** Also affects: debianutils (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: linux-base (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Tags added: bionic focal hirsute installkernel

** Description changed:

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

[Touch-packages] [Bug 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2021-04-08 Thread Krzysztof Kozlowski
** Tags added: sru-20210315

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

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  Triaged
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

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