David Kalnischkies <da...@kalnischkies.de> (2015-11-27): > On Fri, Nov 27, 2015 at 09:08:35PM +0100, Cyril Brulebois wrote: > > | E: Method gave invalid 400 URI Failure message: Could not get new groups > > - getgroups (22: Invalid argument) > > | E: Method copy has died unexpectedly! > > | E: Sub-process copy returned an error code (112)
[ BTW, for completeness, the bug report I had in mind was filed against sbuild rather than schroot: https://bugs.debian.org/728422 ] > So, getgroups gets called there to verify that we really lost all groups > (beside the one _apt is in: nogroup). A few lines above we set the list > of (supplementary) groups containing only this group, then we switch uid > and gid (the later isn't enough for group switching aka we would be > still in root without the setgroups before). > > So, us calling getgroups should really only return one group. Getting an > EINVAL suggests we get more than one… that is probably bad, but I have > a slight glimmer of hope that its just two times the same group – even > if that makes no sense… anyway, I can't reproduce this at the moment, so > it would be nice if someone could try the attached patch which could at > least tell us in which groups we remain (or it just works if we really > see duplicated groups here). Everything is possible I guess. ACK, will test in a few moments. > Given that schroot is involved mentioning if your host has an _apt user > or not might also help. As I learned today schroot is copying users and > groups into the schroot which makes all of this kinda strange… (#565613) > [two years of testing and you are still surprised on release…] > > btw: To not block anyone: You can use the config option > Debug::NoDropPrivs to true to disable privilege dropping for the moment. Thanks, I'll try that and maybe temporarily switch debian-installer to using it so that we get our daily builds back until the apt side is figured out. Mraw, KiBi.
signature.asc
Description: Digital signature
