When setting up a machine according to the "Application of Jails" section of FreeBSD Handbook [1], one runs into a problem where "make deinstall" inside of a jail does not work as expected. There is a workaround, which probably should be noted in the chapter. Note that this only applies to ports installed in a jail. Ports installed on the base system do not need the workaround. [1] http://www.freebsd.org/doc/handbook/jails-application.html Original thread: http://forums.freebsd.org/showthread.php?p=213757 Fix: The workaround is to use "make deinstall PREFIX=/s/usr-local", where /s/usr-local is whatever make spits out when you type make deinstall. If you followed the handbook instructions exactly it will be /s/usr-local.
Brandon Thomson <bt@brandonthomson.com> writes: > When setting up a machine according to the "Application of Jails" > section of FreeBSD Handbook [1], one runs into a problem where "make > deinstall" inside of a jail does not work as expected. There is a > workaround, which probably should be noted in the chapter. > > Note that this only applies to ports installed in a jail. Ports > installed on the base system do not need the workaround. > > [1] http://www.freebsd.org/doc/handbook/jails-application.html > > Original thread: http://forums.freebsd.org/showthread.php?p=213757 >>How-To-Repeat: > >>Fix: > The workaround is to use "make deinstall PREFIX=/s/usr-local", where > /s/usr-local is whatever make spits out when you type make > deinstall. If you followed the handbook instructions exactly it will > be /s/usr-local. Maybe it's just that I don't work with jails much, but I'm not following the issue. If you're actually running *inside* the jail, you shouldn't see that prefix. Where you need to run the command that way is if you're using the parent system to update the port that the jail runs. But then your "make install" process is not actually *in* the jail at all.
>>When setting up a machine according to the "Application of Jails" >>section of FreeBSD Handbook [1], one runs into a problem where "make >>deinstall" inside of a jail does not work as expected. There is a >>workaround, which probably should be noted in the chapter. >> >>Note that this only applies to ports installed in a jail. Ports >>installed on the base system do not need the workaround. >> >>[1] http://www.freebsd.org/doc/handbook/jails-application.html >> >>Original thread [2]: http://forums.freebsd.org/showthread.php?p=213757 >> >>The workaround is to use "make deinstall PREFIX=/s/usr-local", where >>/s/usr-local is whatever make spits out when you type make >>deinstall. If you followed the handbook instructions exactly it will >>be /s/usr-local. >If you're actually running *inside* the jail, you shouldn't see that >prefix. Do you mean the directory /s/usr-local should not be visible inside the jail? On the jails I have set up it is, and I believe that is in accord with the instructions in [1]. For example if /s/usr-local were not visible inside the jail, the symlink at /usr/local pointing to ../s/usr-local would be a broken link. So, I think the PREFIX of /s/usr-local *should* be visible inside the jail. >Where you need to run the command that way is if you're using the parent >system to update the port that the jail runs. But then your "make >install" process is not actually *in* the jail at all. I did not attempt to deinstall a port run by the jail from the parent system. My attempt was from inside the jail environment, using jexec. I agree that one would *also* need to adjust the PREFIX if one wanted to deinstall a port in the jail from the parent system. In this case, the PREFIX would need to be set to /usr/jails/s/myjail/usr-local or similar. However, the point of this issue is that PREFIX also needs to be set when running "make deinstall" *inside* the jail environment. If you don't set PREFIX, you will run into the error described in [2]. Note that the host's /usr/jails/s/myjail should be mounted to /s inside the jail, so the PREFIX inside the jail is: /s/usr-local. Hope that makes sense! Jail paths can be really confusing :( I suppose it's also possible that both myself and the original poster in [2] have failed to follow the instructions in [1] correctly in some way that is causing this issue to arise, but that seems unlikely to me. Warm regards, Brandon
[This message didn't make it into GNATS because I left out the address. Just resubmitting so it gets archived] >It seems to me that the Handbook advice includes linking the >/s/usr-local onto /usr/local inside the jail. This is highly desirable >for regular users because having /usr/local/bin in a PATH works just >like on a real system. Yes, I think that is correct. This link exists on my system where I found this issue. Here is a transcript of a shell session demonstrating the issue. I also included some demonstration that the link from /usr/local to /rw/usr_local exists and is working (note that I have used slightly different directory names from the handbook example, so it is /rw/usr_local instead of /s/usr-local) I probably should have included this in the first message! Sorry about that. root@pipe:/usr/ports/ports-mgmt/portaudit # make ===> Fetching all distfiles required by portaudit-0.6.0 for building ===> Extracting for portaudit-0.6.0 ===> Patching for portaudit-0.6.0 ===> Configuring for portaudit-0.6.0 ===> Building for portaudit-0.6.0 root@pipe:/usr/ports/ports-mgmt/portaudit # make install ===> Installing for portaudit-0.6.0 ===> Generating temporary packing list ===> Checking if ports-mgmt/portaudit already installed ===> To check your installed ports for known vulnerabilities now, do: /usr/local/sbin/portaudit -Fda ===> Compressing manual pages for portaudit-0.6.0 ===> Registering installation for portaudit-0.6.0 root@pipe:/usr/ports/ports-mgmt/portaudit # make deinstall ===> Deinstalling for ports-mgmt/portaudit ===> portaudit-0.6.0 has a different PREFIX: /rw/usr_local, skipping root@pipe:/usr/ports/ports-mgmt/portaudit # make deinstall PREFIX=/rw/usr_local ===> Deinstalling for ports-mgmt/portaudit ===> Deinstalling portaudit-0.6.0 The portaudit package has been deleted. root@pipe:/usr/ports/ports-mgmt/portaudit # readlink /usr/local ../rw/usr_local root@pipe:/usr/ports/ports-mgmt/portaudit # ls -la /usr/ total 144 drwxr-xr-x 14 root wheel 16 Mar 16 11:46 . drwxr-xr-x 13 root wheel 20 Apr 18 14:38 .. lrwxr-xr-x 1 root wheel 15 Mar 16 11:46 X11R6 -> ../rw/usr_X11R6 drwxr-xr-x 2 root wheel 475 Mar 16 11:00 bin drwxr-xr-x 2 root wheel 16 Mar 16 10:59 games drwxr-xr-x 53 root wheel 283 Mar 16 10:59 include drwxr-xr-x 7 root wheel 556 Mar 16 10:59 lib drwxr-xr-x 4 root wheel 571 Mar 16 11:00 lib32 drwxr-xr-x 5 root wheel 5 Mar 16 10:59 libdata drwxr-xr-x 6 root wheel 62 Mar 16 11:00 libexec lrwxr-xr-x 1 root wheel 15 Mar 16 11:45 local -> ../rw/usr_local drwxr-xr-x 2 root wheel 2 Mar 16 10:59 obj drwxr-xr-x 68 root wheel 83 Apr 21 20:18 ports drwxr-xr-x 2 root wheel 286 Mar 16 10:59 sbin drwxr-xr-x 27 root wheel 27 Mar 16 10:59 share drwxr-xr-x 22 root wheel 31 Mar 16 04:05 src root@pipe:/usr/ports/ports-mgmt/portaudit # ls -la /usr/local/ total 111 drwxr-xr-x 13 root wheel 13 May 7 09:00 . drwxr-xr-x 12 root wheel 15 May 7 09:00 .. drwxr-xr-x 2 root wheel 2 May 7 09:00 bin drwxr-xr-x 6 root wheel 6 May 7 09:02 etc drwxr-xr-x 3 root wheel 3 May 7 09:00 include drwxr-xr-x 2 root wheel 2 May 7 09:00 info drwxr-xr-x 3 root wheel 3 May 7 09:00 lib drwxr-xr-x 5 root wheel 5 May 7 09:00 libdata drwxr-xr-x 2 root wheel 2 May 7 09:00 libexec drwxr-xr-x 28 root wheel 28 May 7 09:00 man drwxr-xr-x 2 root wheel 2 May 7 09:02 sbin drwxr-xr-x 15 root wheel 15 May 7 09:00 share drwxr-xr-x 2 root wheel 2 May 7 09:00 www root@pipe:/usr/ports/ports-mgmt/portaudit #
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
I'm gonna mark this as overcome by events since the chapter has been rewritten in: https://cgit.freebsd.org/doc/commit/?id=612b7cc1