Activity log for bug #1845337

Date Who What changed Old value New value Message
2019-09-25 14:14:28 Christian Ehrhardt  bug added bug
2019-09-25 14:14:43 Christian Ehrhardt  tags update-excuse
2019-09-25 14:14:52 Christian Ehrhardt  nominated for series Ubuntu Disco
2019-09-25 14:14:52 Christian Ehrhardt  bug task added systemd (Ubuntu Disco)
2019-09-25 14:15:10 Christian Ehrhardt  bug task added qemu (Ubuntu)
2019-09-25 14:17:31 Christian Ehrhardt  attachment added bad case - full log https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+attachment/5291153/+files/bad.log.gz
2019-09-25 14:25:58 Christian Ehrhardt  attachment added good case - full log https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+attachment/5291155/+files/good.log.gz
2019-09-25 14:26:17 Christian Ehrhardt  attachment added bad case - short log https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+attachment/5291156/+files/bad-short.log
2019-09-25 14:26:39 Christian Ehrhardt  attachment added good case - short log https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1845337/+attachment/5291157/+files/good-short.log
2019-09-25 19:32:52 Dan Streetman bug added subscriber Iain Lane
2019-09-25 19:33:36 Dan Streetman bug added subscriber Dan Streetman
2019-09-26 08:59:13 Christian Ehrhardt  bug added subscriber Stéphane Graber
2019-09-26 18:06:50 Dan Streetman tags update-excuse next-ddstreet systemd update-excuse
2019-09-27 11:23:24 Launchpad Janitor qemu (Ubuntu): status New Confirmed
2019-09-27 11:23:24 Launchpad Janitor systemd (Ubuntu): status New Confirmed
2019-09-27 11:23:24 Launchpad Janitor qemu (Ubuntu Disco): status New Confirmed
2019-09-27 11:23:24 Launchpad Janitor systemd (Ubuntu Disco): status New Confirmed
2019-09-30 14:04:31 Rafael David Tinoco bug added subscriber Ubuntu Server
2019-10-02 13:11:38 Dan Streetman tags next-ddstreet systemd update-excuse ddstreet disco systemd update-excuse
2019-10-02 13:14:52 Dan Streetman tags ddstreet disco systemd update-excuse disco systemd update-excuse
2019-10-02 13:15:00 Dan Streetman removed subscriber Dan Streetman
2019-10-03 13:30:11 Paride Legovini systemd (Ubuntu): status Confirmed Triaged
2019-10-03 13:30:15 Paride Legovini systemd (Ubuntu Disco): status Confirmed Triaged
2019-10-03 13:30:19 Paride Legovini qemu (Ubuntu Disco): status Confirmed Triaged
2019-10-03 13:30:22 Paride Legovini qemu (Ubuntu): status Confirmed Triaged
2019-10-04 16:42:51 Launchpad Janitor systemd (Ubuntu): status Triaged Fix Released
2019-10-04 16:42:51 Launchpad Janitor cve linked 2019-15718
2019-10-14 19:11:45 Dan Streetman description Since the recent few weeks systemd autopkgtest @ armhf @ disco fail [1]. The log is very (very) long and partially interwoven due to concurrent execution. Somewhere in between we see this subcase is the one failing: root-unittests Of this test (which again has many subtests) it is: test-execute And of this again it is (always): I'll attach bad and good case full and stripped logs. The diff of those comes down to just: 1. execute a find in a shell 2. shell exits 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=0/SUCCESS vs 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=1/FAILURE 4. in the bad case that triggers an assertion The find that fails is: find / -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf Good and bad case are the same most recent version systemd/240-6ubuntu5.7. Maybe something is bad in the containers we have for armhf in regard to these paths? Was there any change we'd know of? If there is nothing known, could we force-badtest it to get it out of the way of ongoing migrations? [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf [impact] due to recent change to run armhf tests in nested lxd container, autopkgtest for systemd on disco fails consistently. [test case] see test results, linked in original description below. [regression potential] very low, autopkgtest fix only. [other info] original description: --- Since the recent few weeks systemd autopkgtest @ armhf @ disco fail [1]. The log is very (very) long and partially interwoven due to concurrent execution. Somewhere in between we see this subcase is the one failing: root-unittests Of this test (which again has many subtests) it is: test-execute And of this again it is (always): I'll attach bad and good case full and stripped logs. The diff of those comes down to just: 1. execute a find in a shell 2. shell exits 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=0/SUCCESS vs 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=1/FAILURE 4. in the bad case that triggers an assertion The find that fails is: find / -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf Good and bad case are the same most recent version systemd/240-6ubuntu5.7. Maybe something is bad in the containers we have for armhf in regard to these paths? Was there any change we'd know of? If there is nothing known, could we force-badtest it to get it out of the way of ongoing migrations? [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf
2019-11-01 14:02:03 Balint Reczey qemu (Ubuntu): status Triaged Invalid
2019-11-01 14:02:10 Balint Reczey qemu (Ubuntu Disco): status Triaged Invalid
2019-11-09 01:01:22 Steve Langasek description [impact] due to recent change to run armhf tests in nested lxd container, autopkgtest for systemd on disco fails consistently. [test case] see test results, linked in original description below. [regression potential] very low, autopkgtest fix only. [other info] original description: --- Since the recent few weeks systemd autopkgtest @ armhf @ disco fail [1]. The log is very (very) long and partially interwoven due to concurrent execution. Somewhere in between we see this subcase is the one failing: root-unittests Of this test (which again has many subtests) it is: test-execute And of this again it is (always): I'll attach bad and good case full and stripped logs. The diff of those comes down to just: 1. execute a find in a shell 2. shell exits 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=0/SUCCESS vs 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=1/FAILURE 4. in the bad case that triggers an assertion The find that fails is: find / -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf Good and bad case are the same most recent version systemd/240-6ubuntu5.7. Maybe something is bad in the containers we have for armhf in regard to these paths? Was there any change we'd know of? If there is nothing known, could we force-badtest it to get it out of the way of ongoing migrations? [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf [impact] due to a recent change to allow armhf tests to run lxd containers, autopkgtest for systemd on disco fails consistently. [test case] see test results, linked in original description below. [regression potential] very low, autopkgtest fix only. [other info] original description: --- Since the recent few weeks systemd autopkgtest @ armhf @ disco fail [1]. The log is very (very) long and partially interwoven due to concurrent execution. Somewhere in between we see this subcase is the one failing: root-unittests Of this test (which again has many subtests) it is: test-execute And of this again it is (always): I'll attach bad and good case full and stripped logs. The diff of those comes down to just: 1. execute a find in a shell 2. shell exits 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=0/SUCCESS vs 3. exec-dynamicuser-statedir.service: Main process exited, code=exited, status=1/FAILURE 4. in the bad case that triggers an assertion The find that fails is: find / -path /var/tmp -o -path /tmp -o -path /proc -o -path /dev/mqueue -o -path /dev/shm -o -path /sys/fs/bpf Good and bad case are the same most recent version systemd/240-6ubuntu5.7. Maybe something is bad in the containers we have for armhf in regard to these paths? Was there any change we'd know of? If there is nothing known, could we force-badtest it to get it out of the way of ongoing migrations? [1]: http://autopkgtest.ubuntu.com/packages/s/systemd/disco/armhf
2019-11-09 01:03:23 Steve Langasek systemd (Ubuntu Disco): status Triaged Fix Committed
2019-11-09 01:03:25 Steve Langasek bug added subscriber Ubuntu Stable Release Updates Team
2019-11-09 01:03:26 Steve Langasek bug added subscriber SRU Verification
2019-11-09 01:03:30 Steve Langasek tags disco systemd update-excuse disco systemd update-excuse verification-needed verification-needed-disco
2019-11-11 11:12:38 Balint Reczey tags disco systemd update-excuse verification-needed verification-needed-disco disco systemd update-excuse verification-done verification-done-disco
2019-11-11 11:12:50 Balint Reczey tags disco systemd update-excuse verification-done verification-done-disco disco systemd update-excuse update-excuse-disco verification-done verification-done-disco
2019-11-25 11:18:51 Launchpad Janitor systemd (Ubuntu Disco): status Fix Committed Fix Released
2019-11-25 11:19:27 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team