Bug#728422: sbuild: fails to getent group sbuild when running with init=/bin/systemd

Cyril Brulebois

unread,

Oct 31, 2013, 10:20:02 PM10/31/13

to

Package: sbuild
Version: 0.63.2-1.1
Severity: important

Hi,

from a pristine wheezy box, I've done that:
- install sbuild
- add myself to the sbuild group
- run sbuild-createchroot sid /location http://mirror/debian
- run sbuild -As -d unstable foo.dsc

The last bit failed with:
| D: Running command: schroot -d / -c sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205 --run-session -q -u root -p -- getent group sbuild
| /bin/sh: 1: cannot create /var/lib/schroot/mount/sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205/etc/group: Permission denied
| E: Failed to create group sbuild
| Failed to set up chroot

Looking at the "mount" output, that reminded me I was running under
systemd, so I wondered whether switching it off would help. And it
helped indeed!

I suspect there's some interference between some schroot things and
systemd, but filing it against sbuild for now, since that's where I
hit the bug so far.

Mraw,
KiBi.

-- System Information:
Debian Release: 7.2
APT prefers proposed-updates
APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sbuild depends on:
ii adduser 3.113+nmu3
ii apt-utils 0.9.7.9
ii libsbuild-perl 0.63.2-1.1
ii perl 5.14.2-21+deb7u1
ii perl-modules 5.14.2-21+deb7u1

Versions of packages sbuild recommends:
ii debootstrap 1.0.48+deb7u1
ii fakeroot 1.18.4-2

Versions of packages sbuild suggests:
pn deborphan <none>
ii wget 1.13.4-3

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Roger Leigh

unread,

Nov 6, 2013, 6:00:02 AM11/6/13

to

On Fri, Nov 01, 2013 at 03:14:05AM +0100, Cyril Brulebois wrote:
> The last bit failed with:
> | D: Running command: schroot -d / -c sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205 --run-session -q -u root -p -- getent group sbuild
> | /bin/sh: 1: cannot create /var/lib/schroot/mount/sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205/etc/group: Permission denied
> | E: Failed to create group sbuild
> | Failed to set up chroot
>
> Looking at the "mount" output, that reminded me I was running under
> systemd, so I wondered whether switching it off would help. And it
> helped indeed!
>
> I suspect there's some interference between some schroot things and
> systemd, but filing it against sbuild for now, since that's where I
> hit the bug so far.

The failure is trying to run

getent group sbuild >> ${chroot}/etc/group

However, this only works as root, and it's only used as a fallback
in the unusual case that the passwd/group databases in the chroot
are out of sync with the base system. The real question here is
why the system databases weren't copied over during the session
setup.

I would suggest trying to run schroot without sbuild and see that
if you start a new session with

schroot -b -n test -c sid-amd64-sbuild -v --debug=notice

and see if there is anything group-related in the output.
After this completes, is there a group file in the schroot
directory? Does

schroot -r -c test -- getent group sbuild

succeed or fail?

Does "getent group sbuild" work correctly on the base system when
systemd is running? How about "getent group"?

sbuild and schroot don't really do anything which should be
affected by the init system in use. Both just make use of
standard POSIX interfaces, and if systemd causes changes in
how these basic libc calls function, that's a bit worrying.
The schroot db copy is as simple as

getent $db >> $chroot/etc/$db

Any more information you could provide regarding the above would
be much appreciated.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

Cyril Brulebois

unread,

Nov 8, 2013, 4:40:02 PM11/8/13

to

Hi,

answering in a linear fashion, but you may want to read the comment at
the bottom first… (see arrow: →)

Roger Leigh <rle...@codelibre.net> (2013-11-06):

> The failure is trying to run
>
> getent group sbuild >> ${chroot}/etc/group
>
> However, this only works as root, and it's only used as a fallback
> in the unusual case that the passwd/group databases in the chroot
> are out of sync with the base system. The real question here is
> why the system databases weren't copied over during the session
> setup.
>
> I would suggest trying to run schroot without sbuild and see that
> if you start a new session with
>
> schroot -b -n test -c sid-amd64-sbuild -v --debug=notice

I've recreated a new chroot ("under systemd"), named
experimental-amd64-sbuild, still using sid as the distribution.
sbuild-update -udcar experimental-amd64-sbuild fails the same way.

> and see if there is anything group-related in the output.

Let's see (2>&1):
| kibi@arya:~$ grep -i group /tmp/schroot.log
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=type
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=active
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=run-setup-scripts
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=run-session-scripts
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=run-exec-scripts
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=profile
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=script-config
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=priority
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=aliases
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=environment-filter
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=description
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=users
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=groups
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=root-users
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=root-groups
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=mount-location
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=name
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=command-prefix
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=message-verbosity
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=preserve-environment
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=shell
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=directory
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=location
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=personality
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=user-modifiable-keys
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=root-modifiable-keys
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=union-type
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=union-mount-options
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=union-overlay-directory
| D(2): Getting keyfile group=experimental-amd64-sbuild, key=union-underlay-directory
| D(2): Getting keyfile group=sid-amd64-sbuild, key=type
| D(2): Getting keyfile group=sid-amd64-sbuild, key=active
| D(2): Getting keyfile group=sid-amd64-sbuild, key=run-setup-scripts
| D(2): Getting keyfile group=sid-amd64-sbuild, key=run-session-scripts
| D(2): Getting keyfile group=sid-amd64-sbuild, key=run-exec-scripts
| D(2): Getting keyfile group=sid-amd64-sbuild, key=profile
| D(2): Getting keyfile group=sid-amd64-sbuild, key=script-config
| D(2): Getting keyfile group=sid-amd64-sbuild, key=priority
| D(2): Getting keyfile group=sid-amd64-sbuild, key=aliases
| D(2): Getting keyfile group=sid-amd64-sbuild, key=environment-filter
| D(2): Getting keyfile group=sid-amd64-sbuild, key=description
| D(2): Getting keyfile group=sid-amd64-sbuild, key=users
| D(2): Getting keyfile group=sid-amd64-sbuild, key=groups
| D(2): Getting keyfile group=sid-amd64-sbuild, key=root-users
| D(2): Getting keyfile group=sid-amd64-sbuild, key=root-groups
| D(2): Getting keyfile group=sid-amd64-sbuild, key=mount-location
| D(2): Getting keyfile group=sid-amd64-sbuild, key=name
| D(2): Getting keyfile group=sid-amd64-sbuild, key=command-prefix
| D(2): Getting keyfile group=sid-amd64-sbuild, key=message-verbosity
| D(2): Getting keyfile group=sid-amd64-sbuild, key=preserve-environment
| D(2): Getting keyfile group=sid-amd64-sbuild, key=shell
| D(2): Getting keyfile group=sid-amd64-sbuild, key=directory
| D(2): Getting keyfile group=sid-amd64-sbuild, key=location
| D(2): Getting keyfile group=sid-amd64-sbuild, key=personality
| D(2): Getting keyfile group=sid-amd64-sbuild, key=user-modifiable-keys
| D(2): Getting keyfile group=sid-amd64-sbuild, key=root-modifiable-keys
| D(2): Getting keyfile group=sid-amd64-sbuild, key=union-type
| D(2): Getting keyfile group=sid-amd64-sbuild, key=union-mount-options
| D(2): Getting keyfile group=sid-amd64-sbuild, key=union-overlay-directory
| D(2): Getting keyfile group=sid-amd64-sbuild, key=union-underlay-directory
| In groups: 1
| In root-groups: 1
| In groups: 1
| In root-groups: 1
| D(1): Inserted into environment: AUTH_RGROUP=kibi
| I: 00check: AUTH_RGROUP=kibi
| I: 20nssdatabases: Copying group database to /var/lib/schroot/mount/test/etc/group

> After this completes, is there a group file in the schroot
> directory?

Yes:
-rw-r--r-- 1 root root 941 Nov 8 22:18 /var/lib/schroot/mount/test/etc/group

That's a copy of /etc/group on the host.

> Does
>
> schroot -r -c test -- getent group sbuild
>
> succeed or fail?

> Does "getent group sbuild" work correctly on the base system when
> systemd is running? How about "getent group"?

Both work:
| kibi@arya:~$ getent group sbuild
| sbuild:x:127:kibi
| [ longer output for getent group ]

> sbuild and schroot don't really do anything which should be
> affected by the init system in use. Both just make use of
> standard POSIX interfaces, and if systemd causes changes in
> how these basic libc calls function, that's a bit worrying.
> The schroot db copy is as simple as
>
> getent $db >> $chroot/etc/$db

→ Reading the log again, and checking the initial output, the error is
EPERM, not exactly a getent failure? Something cgroup-ish could explain
some strange user/group issues, when running and storing things in the
chroot, maybe?

> Any more information you could provide regarding the above would
> be much appreciated.

Feel free to ask other questions, but I'm pretty sure I purged
everything related to schroot and sbuild, and that I never configured
anything under /etc for those (except for the file created by
sbuild-createchroot and the sid/experimental rename above).

Mraw,
KiBi.

signature.asc

Roger Leigh

unread,

Nov 10, 2013, 4:00:02 PM11/10/13

to

On Fri, Nov 08, 2013 at 10:28:57PM +0100, Cyril Brulebois wrote:
> Roger Leigh <rle...@codelibre.net> (2013-11-06):

> > Does
> >
> > schroot -r -c test -- getent group sbuild
> >
> > succeed or fail?
>
> Fail:
> | kibi@arya:~$ schroot -r -c test -- getent group sbuild
> | E: Failed to change to directory ‘/home/kibi’: No such file or directory
> | I: The directory does not exist inside the chroot. Use the --directory option to run the command in a different directory.
> | Hangup
> | kibi@arya:~$ echo $?
> | 129

This is probably due to the home directory not existing in the
chroot, and so is probably unrelated to the sbuild failure
(unless we're not running that check in the root).

Does adding "-d /" to make it run in the chroot root, which
should never fail, then make this work?

> → Reading the log again, and checking the initial output, the error is
> EPERM, not exactly a getent failure? Something cgroup-ish could explain
> some strange user/group issues, when running and storing things in the
> chroot, maybe?

I think that's just the above issue with the directory not
existing. Hopefully the result with "-d /" might provide
more information.

Cyril Brulebois

unread,

Nov 10, 2013, 4:10:02 PM11/10/13

to

Roger Leigh <rle...@codelibre.net> (2013-11-10):

> This is probably due to the home directory not existing in the
> chroot, and so is probably unrelated to the sbuild failure
> (unless we're not running that check in the root).
>
> Does adding "-d /" to make it run in the chroot root, which
> should never fail, then make this work?

Here we go:

kibi@arya:~$ schroot -r -c test -d / -- getent group sbuild
I: [test chroot] Running command: “getent group sbuild”
sbuild:x:127:kibi

Hangup
kibi@arya:~$ echo $?
129

Mraw,
KiBi.

signature.asc

Johannes Schauer

unread,

Dec 23, 2015, 7:10:04 PM12/23/15

to

Control: tag -1 + moreinfo unreproducible

Hi,

On Fri, 01 Nov 2013 03:14:05 +0100 Cyril Brulebois <ki...@debian.org> wrote:
> from a pristine wheezy box, I've done that:
> - install sbuild
> - add myself to the sbuild group
> - run sbuild-createchroot sid /location http://mirror/debian
> - run sbuild -As -d unstable foo.dsc
>
> The last bit failed with:
> | D: Running command: schroot -d / -c sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205 --run-session -q -u root -p -- getent group sbuild
> | /bin/sh: 1: cannot create /var/lib/schroot/mount/sid-amd64-sbuild-59d745d4-bd00-4c4d-82cb-1b21032d8205/etc/group: Permission denied
> | E: Failed to create group sbuild
> | Failed to set up chroot
>
> Looking at the "mount" output, that reminded me I was running under
> systemd, so I wondered whether switching it off would help. And it
> helped indeed!
>
> I suspect there's some interference between some schroot things and
> systemd, but filing it against sbuild for now, since that's where I
> hit the bug so far.

can you still reproduce this issue? I'm unable to.

Thanks!

cheers, josch

signature.asc