[Touch-packages] [Bug 1872863] Re: QEMU/KVM display is garbled when booting from kernel EFI stub due to missing bochs-drm module

2020-04-24 Thread Kelsey Margarete Skunberg
** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Committed

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

Title:
  QEMU/KVM display is garbled when booting from kernel EFI stub due to
  missing bochs-drm module

Status in kmod package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in kmod source package in Bionic:
  In Progress
Status in linux source package in Bionic:
  Fix Committed

Bug description:
  BugLink: https://bugs.launchpad.net/bugs/1872863

  [Impact]

  A recent grub2 SRU, LP #1864533, now forces the kernel to boot via the
  kernel EFI stub whenever EFI is enabled. This causes problems for
  QEMU/KVM virtual machines which use the VGA=std video device, as the
  efifb driver yields an unreadable garbled screen. See the attached
  image.

  The correct framebuffer driver to use in this situation is bochs-drm,
  and modprobing it from a HWE kernel fixes the issues.

  bochs-drm is missing from Bionic since CONFIG_DRM_BOCHS was disabled
  in LP #1378648 due to bochs-drm causing problems in a PowerKVM
  machine. This problem appears to be fixed now, and bochs-drm has been
  re-enabled for Disco and up, in LP #1795857 and has been proven safe.

  This has also come up again in LP #1823152, as well as chatter on LP
  #1795857 to get this enabled on Bionic.

  The customer which is experiencing this issue cannot switch to VGA=qxl
  as a workaround, and must use VGA=std, hence I suggest we re-enable
  bochs-drm for Bionic.

  [Fix]

  I noticed on Focal, if you boot, the framebuffer is initially efifb:

  [ 0.603716] efifb: probing for efifb
  [ 0.603733] efifb: framebuffer at 0xc000, using 1876k, total 1875k
  [ 0.603735] efifb: mode is 800x600x32, linelength=3200, pages=1
  [ 0.603736] efifb: scrolling: redraw
  [ 0.603738] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
  [ 0.604462] Console: switching to colour frame buffer device 100x37
  [ 0.605829] fb0: EFI VGA frame buffer device

  This soon changes to bochs-drm about a second later:

  [ 0.935988] bochs-drm :00:01.0: remove_conflicting_pci_framebuffers: bar 
0: 0xc000 -> 0xc0ff
  [ 0.937023] bochs-drm :00:01.0: remove_conflicting_pci_framebuffers: bar 
2: 0xc1c8c000 -> 0xc1c8cfff
  [ 0.937776] checking generic (c000 1d5000) vs hw (c000 100)
  [ 0.937776] fb0: switching to bochsdrmfb from EFI VGA
  [ 0.939085] Console: switching to colour dummy device 80x25
  [ 0.939117] bochs-drm :00:01.0: vgaarb: deactivate vga console
  [ 0.939210] [drm] Found bochs VGA, ID 0xb0c5.
  [ 0.939212] [drm] Framebuffer size 16384 kB @ 0xc000, mmio @ 0xc1c8c000.
  [ 0.941955] lpc_ich :00:1f.0: I/O space for GPIO uninitialized
  [ 0.942069] [TTM] Zone kernel: Available graphics memory: 2006780 KiB
  [ 0.942081] [TTM] Initializing pool allocator
  [ 0.942089] [TTM] Initializing DMA pool allocator
  [ 0.943026] virtio_blk virtio2: [vda] 20971520 512-byte logical blocks (10.7 
GB/10.0 GiB)
  [ 0.944019] [drm] Found EDID data blob.
  [ 0.944162] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:01.0 on 
minor 0
  [ 0.944979] fbcon: bochs-drmdrmfb (fb0) is primary device
  [ 0.947712] Console: switching to colour frame buffer device 128x48

  On bionic, the framebuffer never changes from efifb, since the bochs-
  drm kernel module is not built, and it is also present on the module
  banlist in /etc/modprobe.d/blacklist-framebuffer.conf

  bochs-drm needs to be enabled to be built in the kernel config, and
  removed from the module blacklist in kmod.

  [Testcase]

  Create a new QEMU/KVM virtual machine, I used virt-manager. Before you
  install the OS, check the box to modify settings before install. In
  the "Overview" tab, enable EFI by setting the firmware to "UEFI
  x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd".

  Set the video device to qxl while you install Bionic. Once the install
  is done, reboot, do a "apt update" and "apt upgrade", to ensure you
  have grub2 2.02-2ubuntu8.15 installed.

  Shut the VM down, and set the video device to VGA. Or VGA=std if you
  use the QEMU command line.

  Start the VM up, and the screen will be garbled. See attached picture.

  If you install my test packages, which are available here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf272653-test

  Instructions to install (on a bionic system):

  1) sudo add-apt-repository ppa:mruffell/sf272653-test
  2) sudo apt-get update
  3) sudo apt install linux-image-unsigned-4.15.0-96-generic 
linux-modules-4.15.0-96-generic linux-modules-extra-4.15.0-96-generic 
linux-headers-4.15.0-96-generic linux-headers-4.15.0-96 libkmod2 kmod
  4) sudo reboot
  5) uname -rv
  4.15.0-96-generic #97+TEST272653v20200409b1-Ubuntu SMP Thu Apr 9 04:09:18 UTC 
2020

  If you reboot, the screen will be perfectly readable, since the bochs-
  drm driver will be in 

[Touch-packages] [Bug 1892358] Re: autopkgtest success rate dropped inhibiting proposed migration

2020-09-15 Thread Kelsey Margarete Skunberg
Seeing similar problems on Xenial and I suspect it's similar to the
problems occurring with Bionic and Focal:
http://autopkgtest.ubuntu.com/packages/s/systemd/xenial/amd64

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

Title:
  autopkgtest success rate dropped inhibiting proposed migration

Status in build-essential package in Ubuntu:
  Invalid
Status in glib2.0 package in Ubuntu:
  Invalid
Status in iputils package in Ubuntu:
  Invalid
Status in kbd package in Ubuntu:
  Invalid
Status in linux-meta package in Ubuntu:
  Invalid
Status in ntpsec package in Ubuntu:
  Invalid
Status in qemu package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  Invalid
Status in linux-meta source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in build-essential source package in Focal:
  Confirmed
Status in linux-meta source package in Focal:
  New
Status in qemu source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Confirmed
Status in util-linux source package in Focal:
  Confirmed

Bug description:
  Hi,
  we had such cases in the past like bug 1817721 for bionic and maybe bug 
1892130 is about the same as well. There were more but I didn't want to search 
for all of them - what I checked is that there are no open ones clearly 
pointing out the recent further drop in already flaky subtests.

  In particular the tests "tests-in-lxd" and "systemd-fsckd" were known
  to be flaky before, but got even worse.

  Here stats of the last 40 runs, it might be a coincidences that this
  is after 246-2ubuntu1 landed. Could as well be any other change

  groovy
amd64
  tests-in-lxd   (F 42% S  0% B 10% => P 45%/) 
BFFFBFF.B.F.F...FBF
  build-login(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  unit-config(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  networkd-testpy(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  boot-and-services  (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  boot-smoke (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  logind (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  storage(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  upstream   (F 35% S  0% B 10% => P 52%/) 
..FFB.FFF.FFBFF.B.F.F..FFBF
  udev   (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  systemd-fsckd  (F 37% S  0% B 10% => P 50%/) 
BFFFB.FF...FB.F..B.
  root-unittests (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
ppc64el
  tests-in-lxd   (F 25% S  0% B  0% => P 75%/) 
FFFFF.F.
  systemd-fsckd  (F 35% S  0% B  0% => P 65%/) 
FFF...FFFFF.F..F
  root-unittests (F  2% S  0% B  0% => P 97%/) 
..F.
s390x
  tests-in-lxd   (F 52% S  0% B  0% => P 47%/) 
FFF.FFF.FF....F.
  timedated  (F  2% S  0% B  0% => P 97%/) 
...F
  upstream   (F 17% S  0% B  0% => P 82%/) 
.F..F.F.FFF...F.
  systemd-fsckd  (F 32% S  0% B  0% => P 67%/) 
FFF..FF..F.FF..F
  root-unittests (F 10% S  0% B  0% => P 90%/) 
FFF...F.
arm64
  tests-in-lxd   (F 40% S  0% B  2% => P 57%/) 
F.B...FFF.FF..F..F.FFF.F
  logind (F  2% S  0% B  2% => P 95%/) 
..B...F.
  upstream   (F 22% S  0% B  2% => P 75%/) 
...F.FB.F.F.F..FFF.F
  root-unittests (F 12% S  0% B  2% => P 85%/) 
..B.F...F.FF...F

  (I'm sure LP will make this unreadable, but is is nice in monospace)

  Whatever the root cause is - the success rate of these has reduced so
  much that the (even formerly questionable) practice of retry-until-
  success won't work anymore.

  
  I have run the two tests in a local VM and systemd-fsckd works there while 
tests-in-lxd seems to trip over the old flaky fellow being "boot-and-services".

  We had the discussion in the past, but I think I need to again bring
  up the suggestion to skip "tests-in-lxd" and "systemd-fsckd" until
  they are on reasonable success rates.

To manage notifications about this 

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

2020-10-02 Thread Kelsey Margarete Skunberg
msgstress03 and msgstress04 is failing with similar behavior on Focal
aws : 5.4.0-1026.26 : amd64

-- 
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 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 1783881] Re: ltp-syscalls: msgstress03 fails because systemd limits number of processes

2020-10-02 Thread Kelsey Margarete Skunberg
** Tags added: sru-20200921

-- 
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 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 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

2020-10-07 Thread Kelsey Margarete Skunberg
** Tags added: 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/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 1892130] [NEW] systemd 245.4-4ubuntu3.2 ADT test failure with linux-aws 5.4.0-1022.22

2020-08-18 Thread Kelsey Margarete Skunberg
Public bug reported:

Testing failed on:
amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20200817_235646_79e19@/log.gz

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: kernel-adt-failure

** Tags added: kernel-adt-failure

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

Title:
  systemd 245.4-4ubuntu3.2 ADT test failure with linux-aws 5.4.0-1022.22

Status in systemd package in Ubuntu:
  New

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/s/systemd/20200817_235646_79e19@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1892130/+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 1891224] Re: [Hyper-V] VSS and File Copy daemons intermittently fails to start

2020-08-27 Thread Kelsey Margarete Skunberg
** Changed in: linux (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Changed in: linux (Ubuntu Focal)
   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/1891224

Title:
   [Hyper-V] VSS and File Copy daemons intermittently fails to start

Status in linux package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Fix Committed
Status in systemd source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Invalid
Status in linux source package in Focal:
  Fix Committed
Status in systemd source package in Focal:
  Invalid
Status in linux source package in Groovy:
  In Progress
Status in systemd source package in Groovy:
  Invalid

Bug description:
  [Impact]

  We have most reliably reproduced this on a Standard_B1s in Azure in
  the North Europe region (>80% of the time). Tests in other regions/VM
  types do not show this failure as often (<1%). We have reproduced this
  in Xenial, Bionic, Focal, and Groovy. We saw an increase of test
  failures around a month ago.

  From the journal :

  Aug 11 09:55:28 ubuntu systemd[1]: 
sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job 
sys-devices-virtual-misc-vmbus\x21hv_vss.device/start tim>
  Aug 11 09:55:28 ubuntu systemd[1]: Timed out waiting for device 
sys-devices-virtual-misc-vmbus\x21hv_vss.device.
  Aug 11 09:55:28 ubuntu systemd[1]: Dependency failed for Hyper-V VSS Protocol 
Daemon.
  Aug 11 09:55:28 ubuntu systemd[1]: hv-vss-daemon.service: Job 
hv-vss-daemon.service/start failed with result 'dependency'.
  Aug 11 09:55:28 ubuntu systemd[1]: 
sys-devices-virtual-misc-vmbus\x21hv_vss.device: Job 
sys-devices-virtual-misc-vmbus\x21hv_vss.device/start fai>
  Aug 11 09:55:28 ubuntu systemd[1]: 
sys-devices-virtual-misc-vmbus\x21hv_fcopy.device: Job 
sys-devices-virtual-misc-vmbus\x21hv_fcopy.device/start>
  Aug 11 09:55:28 ubuntu systemd[1]: Timed out waiting for device 
sys-devices-virtual-misc-vmbus\x21hv_fcopy.device.
  Aug 11 09:55:28 ubuntu systemd[1]: Dependency failed for Hyper-V File Copy 
Protocol Daemon.

  We've seen problems in the past with KVP daemons that looked very
  similar : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1820063

  
  [Test Case]

  There two main scenarios that need to be tested:

  1. Azure instances:

 - Just start an azure instance using our Ubuntu images and check
  the the status of the hv-vss-daemon and hv-fcopy-daemon services using
  systemctl.

 - If the issue is solved they shouldn't be listed as failed.

  2. Local Hyper-V VM:

 - Create a local Hyper-V instance and enable the two systemd
  services if necessary (hv-vss-daemon and hv-fcopy-daemon) and reboot.

 - You can change the integration services that are enable to the
  guest.

   1. With desktop integration and the backup feature disabled, the 
hv-fcopy-daemon and the hv-vss-daemon service, respectively should not be 
listed as failed.
   2. With the same features enabled the services should start without 
errors.

  
  [Regression Potential] 

  The major risk with a potential regression is that those systemd
  service units are shipped by a package produced by our generic kernels
  and not the linux-azure kernel. So in case of a regression we might
  need to re-spin the generic kernels.

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

2020-10-02 Thread Kelsey Margarete Skunberg
** Tags added: 4.15 bionic

-- 
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 1783881] Re: ltp-syscalls: msgstress03 fails because systemd limits number of processes

2020-10-02 Thread Kelsey Margarete Skunberg
Updating bug to include msgstress04 failure.

msgstress04 - part of log from F aws : 5.4.0-1026.26 : amd64

12969.  09/23 17:30:15 DEBUG| utils:0153| [stdout] startup='Wed Sep 23 17:11:41 
2020'
12970.  09/23 17:30:15 DEBUG| utils:0153| [stdout] msgstress04 0 TINFO : Found 
32000 available message queues
12971.  09/23 17:30:15 DEBUG| utils:0153| [stdout] msgstress04 0 TINFO : Using 
upto 2097063 pids
12972.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9217
12973.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9237
12974.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9202
12975.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9251
12976.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9273
12977.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9277
12978.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9275
12979.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9276
12980.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9278
12981.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9279
12982.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9248
12983.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9262
12984.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9274
12985.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9310
12986.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9290
12987.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9314
12988.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9315
12989.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9316
12990.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9309
12991.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9325
12992.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9326
12993.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9298
12994.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9327
12995.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9308
12996.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the second 
child of child group 9324
12997.  09/23 17:30:15 DEBUG| utils:0153| [stdout] Fork failure in the first 
child of child group 9357
12998.  09/23 17:30:15 DEBUG| utils:0153| [stdout] msgstress04 1 TFAIL : 
msgstress04.c:204: Fork failed (may be OK if under stress)
12999.  09/23 17:30:15 DEBUG| utils:0153| [stdout] tag=msgstress04 
stime=1600881101 dur=169 exit=exited stat=1 core=no cu=14 cs=136

** Summary changed:

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

** Tags added: 5.4 aws

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

-- 

[Touch-packages] [Bug 1892358] Re: autopkgtest success rate dropped inhibiting proposed migration

2020-09-16 Thread Kelsey Margarete Skunberg
Thank you @christian. I marked the Xenial test cases under this same
bug, though can open a new bug and update the hint bug references if
needed. I'll check back to see when/if ddstreet/rbalint have a chance to
review.

For the test results you're posting, I was wondering where you're
getting those results from and an explanation of the results?

xenial
  amd64
boot-and-services (F 45% f 0% S 0% B 5% => P 50%/) .FF...BFF.F.
boot-smoke (F 80% f 0% S 0% B 5% => P 15%/) F.FF..BF
systemd-fsckd (F 65% f 0% S 0% B 5% => P 30%/) FF.FFF.F..B.FF.F
  ppc64el
no failures
  s390x
no failures

In the above, what does the F, f, B, & . stand for? Am I correct to
assume the P *% is the pass rate? F for fail?

Thank you!

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

Title:
  autopkgtest success rate dropped inhibiting proposed migration

Status in build-essential package in Ubuntu:
  Invalid
Status in glib2.0 package in Ubuntu:
  Invalid
Status in iputils package in Ubuntu:
  Invalid
Status in kbd package in Ubuntu:
  Invalid
Status in linux-meta package in Ubuntu:
  Invalid
Status in ntpsec package in Ubuntu:
  Invalid
Status in qemu package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  Invalid
Status in linux-meta source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in build-essential source package in Focal:
  Confirmed
Status in linux-meta source package in Focal:
  New
Status in qemu source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Confirmed
Status in util-linux source package in Focal:
  Confirmed

Bug description:
  Hi,
  we had such cases in the past like bug 1817721 for bionic and maybe bug 
1892130 is about the same as well. There were more but I didn't want to search 
for all of them - what I checked is that there are no open ones clearly 
pointing out the recent further drop in already flaky subtests.

  In particular the tests "tests-in-lxd" and "systemd-fsckd" were known
  to be flaky before, but got even worse.

  Here stats of the last 40 runs, it might be a coincidences that this
  is after 246-2ubuntu1 landed. Could as well be any other change

  groovy
amd64
  tests-in-lxd   (F 42% S  0% B 10% => P 45%/) 
BFFFBFF.B.F.F...FBF
  build-login(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  unit-config(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  networkd-testpy(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  boot-and-services  (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  boot-smoke (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  logind (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  storage(F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  upstream   (F 35% S  0% B 10% => P 52%/) 
..FFB.FFF.FFBFF.B.F.F..FFBF
  udev   (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
  systemd-fsckd  (F 37% S  0% B 10% => P 50%/) 
BFFFB.FF...FB.F..B.
  root-unittests (F  0% S  0% B 10% => P 87%/) 
B...B...BB.
ppc64el
  tests-in-lxd   (F 25% S  0% B  0% => P 75%/) 
FFFFF.F.
  systemd-fsckd  (F 35% S  0% B  0% => P 65%/) 
FFF...FFFFF.F..F
  root-unittests (F  2% S  0% B  0% => P 97%/) 
..F.
s390x
  tests-in-lxd   (F 52% S  0% B  0% => P 47%/) 
FFF.FFF.FF....F.
  timedated  (F  2% S  0% B  0% => P 97%/) 
...F
  upstream   (F 17% S  0% B  0% => P 82%/) 
.F..F.F.FFF...F.
  systemd-fsckd  (F 32% S  0% B  0% => P 67%/) 
FFF..FF..F.FF..F
  root-unittests (F 10% S  0% B  0% => P 90%/) 
FFF...F.
arm64
  tests-in-lxd   (F 40% S  0% B  2% => P 57%/) 
F.B...FFF.FF..F..F.FFF.F
  logind (F  2% S  0% B  2% => P 95%/) 
..B...F.
  upstream   (F 22% S  0% B  2% => P 75%/) 
...F.FB.F.F.F..FFF.F
  root-unittests (F 12% S  0% B  2% => P 85%/) 
..B.F...F.FF...F

  (I'm sure LP will make this 

[Touch-packages] [Bug 1884318] [NEW] lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic

2020-06-19 Thread Kelsey Margarete Skunberg
Public bug reported:

Testing failed on:
amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200617_163718_07690@/log.gz
arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200617_165305_fce64@/log.gz

** Affects: lxc (Ubuntu)
 Importance: Undecided
 Status: Invalid

** Affects: lxc (Ubuntu Bionic)
 Importance: Undecided
 Status: New


** Tags: kernel-adt-failure

** Tags added: kernel-adt-failure

** Summary changed:

- lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with linux-aws-5.4 
5.4.0-1016.16~18.04.1
+ lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic

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

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

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

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic

Status in lxc package in Ubuntu:
  Invalid
Status in lxc source package in Bionic:
  New

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200617_163718_07690@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200617_165305_fce64@/log.gz

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

2020-11-30 Thread Kelsey Margarete Skunberg
Found on Groovy/linux 5.8.0-31.33

** Tags added: 5.8 groovy

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