Control: tag -1 + pending Hi Ian & Julian,
On Tue, 15 May 2018 20:25:46 +0100 Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> In summary: I think the root cause is that the lxc container is not
> set up the way sbuild expects.
I would say the root cause is, that sbuild is buggy but indeed, the code that
tries to modify /etc/group is only run if the container does not have an sbuild
group.
> The named directory becomes $self->get('Location') within sbuild; it's
> a dummy value used when (as in this case) the chroot provider does not
> have a way to access the within-chroot filesystem from outside it.
>
> It is used in relatively few places. Searching for more of the error
> message found a use in basesetup (in ChrootSetup.pm). It seems to try
> to use it only if the `sbuild' group is not found in the chroot.
Yes, your analysis is entirely correct.
> Looking at the code, sbuild expects various other preparatory things
> to have been done to the chroot. It expects a /build directory, and
> /var/lib/sbuild, and so on. I can't find any of this documented
> anywhere.
It could be documented but I don't think it's a high priority to document these
internals. I think sbuild should be able to cope with any plain Debian chroot
and it should be the task of sbuild itself to do the setup that it requires.
This is why sbuild calls the basesetup() function every time it starts a new
chroot session (independent of the backend).
> Hopefully the following, observed in an schroot of mine, is helpful:
>
> $ id sbuild
> uid=120(sbuild) gid=124(sbuild) groups=124(sbuild)
> $ find /build/ /var/lib/sbuild/ -ls
> 606209 4 drwxrws--- 2 sbuild sbuild 4096 Jun 3 2016
> /build/
> 344285 4 drwxrws--- 3 sbuild sbuild 4096 Jun 3 2016
> /var/lib/sbuild/
> 344838 4 -rw-rw-r-- 1 root sbuild 1417 Jun 3 2016
> /var/lib/sbuild/package-checklist
> 344355 4 drwxrws--- 2 sbuild sbuild 4096 Jun 3 2016
> /var/lib/sbuild/srcdep-lock
> 344721 4 -rw------- 1 root sbuild 117 Jun 3 2016
> /var/lib/sbuild/apt.conf
> $
>
> Is there a script that someone could run in an existing
> vm/container/whatever, to prepare it appropriately, before
> snapshotting ?
I don't know of any but the basesetup() function is not doing much so I wonder
if it would be worth the added complexity.
> Also, the error message seems poor.
Agreed.
> I suggest the following approach:
>
> * Break out the relevant bits of sbuild-createchroot into an
> advertised script that can be run as root within the master
> image (what schroot calls the source chroot).
I don't think that should be necessary. Sbuild should do the setup that it
requires itself.
If you find "relevant bits of sbuild-createchroot" which are *required* and not
carried out by sbuild itself, please file a bug!
It should be possible for sbuild to work with a plain debootstrap-ed chroot.
> * Replace calls to ->get('Location') with ->get_location($reason)
> and make the latter fail if the access is not supported.
> $reason will be an explanation of what schroot was trying to do.
> So it will say something like
> E: filesystem access to chroot not supported (wanted because: trying to
> add sbuild group)
There is a better way: avoid the use of 'Location' altogether. Since the
failing piece of code is only attempting to add the sbuild group, sbuild now
instead calls $(groupadd --system sbuild) from within the chroot environment.
There is really no need for direct filesystem access here.
Autopkgtest was the first backend for sbuild where the host potentially didn't
have direct filesystem access to the chroot directory. Back then I tried to
eradicate lots of places where 'Location' was used in a similar way as it is
done here. This one must've slipped.
Thanks for the report!
> * In the longer term, the virt servers should have a way to edit
> the master image. Then you could say sbuild --setup-the-thing
> --autopkgtest-etc.
It seems that this is not going to happen:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886332
Thanks!
cheers, josch
signature.asc
Description: signature
