Date: Sun, 29 May 2016 23:55:55 +0800 From: Julian Elischer <julian@freebsd.org> To: "bapt@freebsd.org" <bapt@freebsd.org>, Tim Kientzle <tim@kientzle.com> Cc: FreeBSD current <freebsd-current@freebsd.org> Subject: Re: pkg chroot issues? Message-ID: <8886a4b1-492b-61ea-90ea-7e694311d03b@freebsd.org> In-Reply-To: <20160522203243.GF11189@ivaldir.etoilebsd.net> References: <9BC1A0E1-696D-4C00-B8C8-B57C4DB3A8EF@kientzle.com> <20160522203108.GE11189@ivaldir.etoilebsd.net> <20160522203243.GF11189@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23/05/2016 4:32 AM, bapt@freebsd.org wrote: > On Sun, May 22, 2016 at 10:31:08PM +0200, bapt@freebsd.org wrote: >> On Sun, May 22, 2016 at 01:24:12PM -0700, Tim Kientzle wrote: >>> Crochet has some experimental hooks to install packages onto the system being built, but this seems to be hitting problems due to limitations in 'pkg -c'. In particular, it seems that pkg performs the chroot before it does any network lookups. This is a problem if the chroot is not a complete system environment (which it cannot be when you're building an image for another system). >>> >>> There's some further discussion on github: >>> >>> https://github.com/freebsd/crochet/issues/141 >>> >>> Any suggestions? >>> >> I'll reply directly to github thanks for pointing me to the ticket >> >> Best regards, >> Bapt > As people might only follow this thread and not the ticket here is what I > answered: > > pkg supports an option for that which is pkg -o NAMESERVER= to avoid having to > copy resolv.conf it was broken in 1.8 but I fixed it in pkg 1.8.0 which has been > released today. > > the problem with pkg -c is that it calls chroot very early. To avoid that > problem we have added pkg -r which does not perform any chroot at all therefore > having not network issue, but the ports tree are is not yet entirely aware of it > and some scripts (preinstall/postinstall) might cause some issues. > at least creating users from the script is safe in that regard. for most simple > case that should work. As Bapt knows (I've been harassing him) pkg needs an "install all this over there" mode. The answer is "-r" but it does suffer from the fact that it requires postinstall scripts to cooperate by knowing to look for the appropriate environment value (I forget its name). I've used three different methods to get around this.. 1/ use -c and prepopulate it with a copy of /rescue, and copying all the pkg files I need in first into /pkg, which I delete afterwards. I'd like clarification in the Man page about setting a good $PATH in the chrooted part of pkg currently I just copy /rescue into /bin but pkg seems to sometimes use full paths for things so that meant also /usr/bin and usr/sbin. (or maybe that was an install script.). (in my application I could just link all 4 locations to be the same place). 2/ use PKG_DBDIR=$(TARGET_DIR)/var/db/pkg pkg add --relocate $(TARGET_DIR) $(PKGFILE) Almost the same as -r from my perspective. 3/ because I need to work as non-root, and pkg doesn't have a -u and -g option like chroot does, there are times when I need to do: sudo chroot -u $ME -g $MYGROUP sh -c "INSTALL_AS_USER pkg add -f -M $(PKGFILE)" instead of using pkg -c. I worked up a patch for -u and -g but lost it.. it was only about 20 lines including the usage() change. I'm sure bapt could redo it much better. using -u automatically enabled install_as_user. I was thinking that in order to do this properly the chrooted child should do all it's fetch requests etc via the non-chrooted parent, but that would have probably been a bit too complicated. (including add requests) > > > Best regards, > Bapt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8886a4b1-492b-61ea-90ea-7e694311d03b>