bin/109334: pkg_add(1) using chroot exits with error if wrong directory

Garrett Cooper yanegomi at
Wed Mar 24 07:00:12 UTC 2010

The following reply was made to PR bin/109334; it has been noted by GNATS.

From: Garrett Cooper <yanegomi at>
To: bug-followup at, nick at
Cc: randi at
Subject: Re: bin/109334: pkg_add(1) using chroot exits with error if wrong 
Date: Tue, 23 Mar 2010 23:52:42 -0700

     The original comment states that sysinstall was the primary
 consumer of the -C option, and while that may have been the case (once
 upon a time), it isn't today according to the code I see in
 usr.sbin/sysinstall/package.c .
     So what I'm going to propose is the following: change the chroot,
 s.t. it only affects the install, operation, which means that instead
 of chroot'ing immediately, it'll first try to open the packages, then
 prior to executing the install instructions will do the chroot and
 will `chdir' to the default prefix (user specified); the default value
 will be '/'. That way the chdir back to the starting point will be
     Another less invasive solution would be to merely pop '/' on to
 the playpen `stack' for the master in make_playpen, i.e.:
     if (!getcwd(cwd, FILENAME_MAX)) {
         return NULL;
     if (chdir(pen) == FAIL) { /* <-- 2. source of confusion */
         errx(2, "%s: can't chdir to '%s'", __func__, pen);
     strcpy(PenLocation, pen);
     return pushPen(cwd); /* <-- 2. source of confusion */
     The pseudo code being:
     if chroot'ed then push '/' on the stack
     else push the current working directory on the stack
     The only potential issue I could see is when installing multiple
 packages, but that use is tainted anyhow because we chrooted early on,
 so the assumption is that the packages have been properly mirrored in
 the target environment like they are in the host non-chrooted
     It's up to you guys -- it's a toss-up either way as there will be
 some level of confusion, but given that pkg_install is a mess and I
 hope to refactor it over the course of the next couple of years, this
 will be a minor mess that will need to be cleaned up later.

More information about the freebsd-bugs mailing list