Hi, Quoting Theodore Ts'o (2022-12-27 05:19:45) > On Mon, Dec 26, 2022 at 08:45:53PM +0100, Santiago Vila wrote: > > El 26/12/22 a las 20:29, Theodore Ts'o escribió: > > > I: The directory does not exist inside the chroot. > > > > This is really a problem with schroot. I guess that this will not work either: > > > > schroot -c the-chroot-name > > > > This usually works when you are in your $HOME because this file: > > > > /etc/schroot/default/fstab > > Nope, that's not the issue; yes, /tmp and /home are missing form > /etc/schroot/sbuild/fstab, but that was true on the *working* setup as > well, and from what I can tell; that's deliberate. It looks like the > goal is to keep things hermetic when building with sbuild, so it's a > feature that there aren't random directories leaking through from the > host to the sbuild enviroment. that is correct. :) > I think I've figured out the issue. The problem is that the user and group > id's for sbuild are different on my desktop and my laptop, and I did an rsync > to copy the /chroot directories from my desktop to my laptop --- and it > appears that sbuild is very sensisitve about the user id's being the same > across the host and chroot environments. > > Apparently sbuild copies the files for the package it is building over > a directory in /var/lib/sbuild/build, with the permissions being mode > 770, and that is what sbuild bind mounts into the chroot. If my > theory is correct, if the user/group id's are different from between > the base /etc/passwd and chroot, then things go bad in a hurry. I think your analysis makes sense. > >From my working system (while gbp buildpackage was running sbuild): > > % ls -al /var/lib/sbuild/build/ > total 12 > 4 drwxrws--- 3 sbuild sbuild 4096 Dec 26 23:05 ./ > 4 drwxrws--- 4 sbuild sbuild 4096 Dec 19 2020 ../ > 4 drwxrwx--- 3 tytso sbuild 4096 Dec 26 23:05 f2fs-tools-oT4KHz/ > > Amd on the broken (laptop) system: > > # ls -al /var/lib/sbuild/build/ > total 32 > 4 drwxrws--- 8 fwupd-refresh Debian-exim 4096 Dec 26 22:48 ./ > 4 drwxrws--- 4 sbuild sbuild 4096 Dec 25 14:45 ../ > 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:01 f2fs-tools-9QfprK/ > 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 16:01 f2fs-tools-btkVPv/ > 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 14:20 f2fs-tools-cVTRAh/ > 4 drwxrwx--- 2 tytso Debian-exim 4096 Dec 26 22:48 f2fs-tools-Myld8j/ > ... > > Each of were created from a failed sbuild invocation... And > "Debian-exim" on my laptop has the same group id as "sbuild" on my > desktop (and which is the group id in my chroots). > > This also explains the error message: > > E: Failed to change to directory ‘/<<BUILDDIR>>’: Permission denied > > Oops. > > So I guess I need to either manually juggle group id's in the chroots > (and/or my laptop's root directory --- but it's probably easier to do > it in the chroots, since there are fewer filees to chgrp in the > chroots), or I could recreate the sbuild chroots from scratch using > sbuild-createchroot (but then I would need to recreate all of the > custom hacks so that ccache,eatmydata, apt-auto-proxy, etc. are working > correctly in the chroot). > > What fun.... Note, that if you keep upgrading a Debian unstable chroot across multiple releases, it will end up looking slightly different than a freshly debootstrapped Debian unstable chroot. So I think there is value in semi-regularly re-creating the build chroot from scratch. Maybe write a script that does what you need? That being said, I think the biggest problem is, that the main sbuild contributors these days (me and Jochen) do not use the schroot backend anymore but the unshare backend instead which doesn't suffer from this kind of problem (but of course has different quirks that one needs to be aware of). So I must admit that in the past few years, the schroot backend hasn't gotten the love that it deserves considering that it's the default backend used on the buildd machinery. Finally, I think this is something that could be solved in sbuild. Ultimately, schroot is able to do things as the root user, so it should have sufficient permissions to fix up a chroot that carries incorrect permissions. Could you quickly note in a bug against sbuild on the Debian BTS which steps exactly you carried out so that I am able to reproduce your problem? I'm making no promises that I'll find the time to improve the schroot backend of sbuild to survive the kind of chroot-rsync that you have performed but if this is important to you, then maybe we can make a trade and I implement this sbuild functionality and you have a look at pull requests https://github.com/tytso/e2fsprogs/pull/118 or #107 and leave some comments in return? :) Thanks! cheers, josch
Attachment:
signature.asc
Description: signature