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