Activity log for bug #1840640

Date Who What changed Old value New value Message
2019-08-19 10:13:50 Steve Dodd bug added bug
2019-08-19 10:21:31 Dimitri John Ledkov nominated for series Ubuntu Bionic
2019-08-19 10:21:31 Dimitri John Ledkov bug task added systemd (Ubuntu Bionic)
2019-08-19 11:37:52 Dan Streetman bug added subscriber Dan Streetman
2019-09-30 01:39:58 Dan Streetman nominated for series Ubuntu Disco
2019-09-30 01:39:58 Dan Streetman bug task added systemd (Ubuntu Disco)
2019-09-30 01:40:04 Dan Streetman systemd (Ubuntu): status New Fix Released
2019-09-30 01:40:17 Dan Streetman tags apport-bug armhf bionic apport-bug armhf bionic next-ddstreet systemd
2019-10-02 13:11:23 Dan Streetman tags apport-bug armhf bionic next-ddstreet systemd apport-bug armhf bionic ddstreet disco systemd
2019-10-02 13:52:15 Dan Streetman systemd (Ubuntu Disco): assignee Dan Streetman (ddstreet)
2019-10-02 13:52:17 Dan Streetman systemd (Ubuntu Bionic): assignee Dan Streetman (ddstreet)
2019-10-02 13:52:19 Dan Streetman systemd (Ubuntu Disco): importance Undecided Medium
2019-10-02 13:52:20 Dan Streetman systemd (Ubuntu Bionic): importance Undecided Medium
2019-10-02 13:52:22 Dan Streetman systemd (Ubuntu Disco): status New In Progress
2019-10-02 13:52:24 Dan Streetman systemd (Ubuntu Bionic): status New In Progress
2019-10-10 21:24:52 Dan Streetman description ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM: #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> void main() { int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666); int r=sync_file_range(f, 0, 0, 0); if (r) perror("sync_file_range"); close(f); } This seems to be causing problems specifically for borg(backup) and postgres: https://github.com/borgbackup/borg/issues/4710 https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93 The solution should be to cherrypick https://github.com/systemd/systemd/pull/13352, I am currently waiting for systemd to rebuild on a slow ARM box. Any chance of an SRU? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.24 Uname: Linux 4.14.66+ armv7l NonfreeKernelModules: extcon_usb_gpio ApportVersion: 2.20.9-0ubuntu7.7 Architecture: armhf Date: Mon Aug 19 11:10:48 2019 ProcEnviron: TERM=screen PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) [impact] calling the glibc function sync_file_range() on a armhf nspawn container fails. [test case] see sample C program from original description below. compile and run that inside a nspawn container on armhf and it will fail. [regression potential] this only adjusts spawn to allow the sync_file_range2 syscall which is used on armhf, so the regression potential is very low. any possible regressions would likely be when calling sync_file_range(). [other info] original description: --- ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM: #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> void main() {         int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);         int r=sync_file_range(f, 0, 0, 0);         if (r)                 perror("sync_file_range");         close(f); } This seems to be causing problems specifically for borg(backup) and postgres: https://github.com/borgbackup/borg/issues/4710 https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93 The solution should be to cherrypick https://github.com/systemd/systemd/pull/13352, I am currently waiting for systemd to rebuild on a slow ARM box. Any chance of an SRU? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.24 Uname: Linux 4.14.66+ armv7l NonfreeKernelModules: extcon_usb_gpio ApportVersion: 2.20.9-0ubuntu7.7 Architecture: armhf Date: Mon Aug 19 11:10:48 2019 ProcEnviron:  TERM=screen  PATH=(custom, no user)  LANG=en_GB.UTF-8  SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install)
2019-10-10 21:26:56 Dan Streetman description [impact] calling the glibc function sync_file_range() on a armhf nspawn container fails. [test case] see sample C program from original description below. compile and run that inside a nspawn container on armhf and it will fail. [regression potential] this only adjusts spawn to allow the sync_file_range2 syscall which is used on armhf, so the regression potential is very low. any possible regressions would likely be when calling sync_file_range(). [other info] original description: --- ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM: #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> void main() {         int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);         int r=sync_file_range(f, 0, 0, 0);         if (r)                 perror("sync_file_range");         close(f); } This seems to be causing problems specifically for borg(backup) and postgres: https://github.com/borgbackup/borg/issues/4710 https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93 The solution should be to cherrypick https://github.com/systemd/systemd/pull/13352, I am currently waiting for systemd to rebuild on a slow ARM box. Any chance of an SRU? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.24 Uname: Linux 4.14.66+ armv7l NonfreeKernelModules: extcon_usb_gpio ApportVersion: 2.20.9-0ubuntu7.7 Architecture: armhf Date: Mon Aug 19 11:10:48 2019 ProcEnviron:  TERM=screen  PATH=(custom, no user)  LANG=en_GB.UTF-8  SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) [impact] calling the glibc function sync_file_range() on a armhf nspawn container fails. [test case] see sample C program from original description below. compile and run that inside a nspawn container on armhf and it will fail. [regression potential] this only adjusts nspawn to allow the sync_file_range2 syscall which is used on armhf, so the regression potential is very low. any possible regressions would likely be when calling sync_file_range(). [other info] original description: --- ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM: #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> void main() {         int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);         int r=sync_file_range(f, 0, 0, 0);         if (r)                 perror("sync_file_range");         close(f); } This seems to be causing problems specifically for borg(backup) and postgres: https://github.com/borgbackup/borg/issues/4710 https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93 The solution should be to cherrypick https://github.com/systemd/systemd/pull/13352, I am currently waiting for systemd to rebuild on a slow ARM box. Any chance of an SRU? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.24 Uname: Linux 4.14.66+ armv7l NonfreeKernelModules: extcon_usb_gpio ApportVersion: 2.20.9-0ubuntu7.7 Architecture: armhf Date: Mon Aug 19 11:10:48 2019 ProcEnviron:  TERM=screen  PATH=(custom, no user)  LANG=en_GB.UTF-8  SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install)
2019-11-09 00:42:56 Steve Langasek systemd (Ubuntu Disco): status In Progress Incomplete
2019-11-09 00:42:58 Steve Langasek systemd (Ubuntu Bionic): status In Progress Incomplete
2019-11-09 00:59:12 Bryan Quigley description [impact] calling the glibc function sync_file_range() on a armhf nspawn container fails. [test case] see sample C program from original description below. compile and run that inside a nspawn container on armhf and it will fail. [regression potential] this only adjusts nspawn to allow the sync_file_range2 syscall which is used on armhf, so the regression potential is very low. any possible regressions would likely be when calling sync_file_range(). [other info] original description: --- ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM: #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> void main() {         int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);         int r=sync_file_range(f, 0, 0, 0);         if (r)                 perror("sync_file_range");         close(f); } This seems to be causing problems specifically for borg(backup) and postgres: https://github.com/borgbackup/borg/issues/4710 https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93 The solution should be to cherrypick https://github.com/systemd/systemd/pull/13352, I am currently waiting for systemd to rebuild on a slow ARM box. Any chance of an SRU? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.24 Uname: Linux 4.14.66+ armv7l NonfreeKernelModules: extcon_usb_gpio ApportVersion: 2.20.9-0ubuntu7.7 Architecture: armhf Date: Mon Aug 19 11:10:48 2019 ProcEnviron:  TERM=screen  PATH=(custom, no user)  LANG=en_GB.UTF-8  SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) [impact] calling the glibc function sync_file_range() on a armhf nspawn container fails. [test case] see sample C program from original description below. compile and run that inside a nspawn container on armhf and it will fail. nspawn instructions: sudo apt install debootstrap systemd-container sudo -i debootstrap --arch=armhf bionic ~/bionic-tree/ systemd-nspawn -D ~/bionic-tree/ [regression potential] this only adjusts nspawn to allow the sync_file_range2 syscall which is used on armhf, so the regression potential is very low. any possible regressions would likely be when calling sync_file_range(). [other info] original description: --- ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn container on ARM: #define _GNU_SOURCE #include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <errno.h> void main() {         int f = open("/tmp/syncrange.test",O_CREAT|O_RDWR,0666);         int r=sync_file_range(f, 0, 0, 0);         if (r)                 perror("sync_file_range");         close(f); } This seems to be causing problems specifically for borg(backup) and postgres: https://github.com/borgbackup/borg/issues/4710 https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BydOUT4zjxb6QmJWy8U9WbC-q%2BJWV7wLsEY9Df%3Dmw0Mw%40mail.gmail.com#ac8f14897647dc7eae3c7e7cbed36d93 The solution should be to cherrypick https://github.com/systemd/systemd/pull/13352, I am currently waiting for systemd to rebuild on a slow ARM box. Any chance of an SRU? ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.24 Uname: Linux 4.14.66+ armv7l NonfreeKernelModules: extcon_usb_gpio ApportVersion: 2.20.9-0ubuntu7.7 Architecture: armhf Date: Mon Aug 19 11:10:48 2019 ProcEnviron:  TERM=screen  PATH=(custom, no user)  LANG=en_GB.UTF-8  SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install)
2019-11-09 01:01:59 Steve Langasek systemd (Ubuntu Disco): status Incomplete Triaged
2019-11-09 01:02:01 Steve Langasek systemd (Ubuntu Bionic): status Incomplete Triaged
2019-11-09 01:02:05 Steve Langasek systemd (Ubuntu Bionic): status Triaged Confirmed
2019-11-09 01:02:07 Steve Langasek systemd (Ubuntu Bionic): status Confirmed In Progress
2019-11-09 01:02:08 Steve Langasek systemd (Ubuntu Disco): status Triaged In Progress
2019-11-09 01:02:59 Steve Langasek systemd (Ubuntu Disco): status In Progress Fix Committed
2019-11-09 01:03:01 Steve Langasek bug added subscriber Ubuntu Stable Release Updates Team
2019-11-09 01:03:03 Steve Langasek bug added subscriber SRU Verification
2019-11-09 01:03:06 Steve Langasek tags apport-bug armhf bionic ddstreet disco systemd apport-bug armhf bionic ddstreet disco systemd verification-needed verification-needed-disco
2019-11-10 17:02:44 Steve Dodd tags apport-bug armhf bionic ddstreet disco systemd verification-needed verification-needed-disco apport-bug armhf bionic ddstreet disco systemd verification-done-disco verification-needed
2019-11-14 15:00:53 Łukasz Zemczak systemd (Ubuntu Bionic): status In Progress Fix Committed
2019-11-14 15:00:58 Łukasz Zemczak tags apport-bug armhf bionic ddstreet disco systemd verification-done-disco verification-needed apport-bug armhf bionic ddstreet disco systemd verification-done-disco verification-needed verification-needed-bionic
2019-11-17 14:05:18 Steve Dodd tags apport-bug armhf bionic ddstreet disco systemd verification-done-disco verification-needed verification-needed-bionic apport-bug armhf bionic ddstreet disco systemd verification-done verification-done-bionic verification-done-disco
2019-11-25 11:18:51 Launchpad Janitor systemd (Ubuntu Disco): status Fix Committed Fix Released
2019-11-25 11:19:23 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2019-11-26 17:37:57 Launchpad Janitor systemd (Ubuntu Bionic): status Fix Committed Fix Released