Perl upgrade fails with ./+INSTALL: Permission denied

kkaos

kkaos

I upgraded from FreeBSD 9.1 to 9.2 today. Now I'm trying to upgrade my ports via portmaster. When upgrading perl5.14, I get the following error output:

Code: 
===>  Installing for perl-5.14.4_2
===>  Checking if lang/perl5.14 already installed
./+INSTALL: Permission denied
pkg_add: install script returned error status
*** [install-package] Error code 1

I'm not sure from where the permission issue is originating. I'm also not sure where this +INSTALL file is located; otherwise, I would check if the filesystem that contains the file is configured to allow execute privileges. I've already verified that the ZFS filesystems for /usr/ports and /var/tmp have the exec boolean set to "on". Also, kern.securelevel is set to "-1".

Any ideas?
 
The +INSTALL file should be in /var/db/pkg/perl-*/ somewhere. I don't think it needs execute permissions but it should be readable. It's been a while since I used 'old-school' packages :e
 
Apparently, the permissions issue was with /tmp because after setting the ZFS exec boolean to "on" for that filesystem, the upgrade worked. I've upgraded the perl5.14 port before (though not to the same version, 5.14.4_2) on several of my FreeBSD 9 systems without this issue so I find it strange that suddenly this upgrade needs to execute a file in /tmp.

Anyway, thanks all for your responses! SirDice, what do you mean by 'old-school' packages?
 
kkaos said:
SirDice, what do you mean by 'old-school' packages?
Click to expand...
The type of packages you are using now. There's a new package manager being developed for FreeBSD called PKGNG. This will become the standard on 10.0. They tried to solve a lot of the issues that plague the 'old' pkg_add(1) and friends. It works differently when it comes to the files in /var/db/pkg/. Unfortunately there's no official repository for it yet but if you set it up yourself the new packages work really well.
 
I also came across this issue and I associated it with the new staging system for ports. In case you're not familiar with it: all ports can now use a so called staging directory which in short will allow non-root users to build packages from a port. This is done by getting the ports to install in the staging directory instead of the actual installation directory. For more information see the wikipage.

However, I get the impression that some ports don't handle this too well as of yet. Especially when a default staging directory hasn't been defined (I think this should also be handled by the port itself whenever no default was set).

(Edit): Actually, after answering @kkaos below I now come to conclude that whenever no staging directory has been defined the scripts will default to /tmp. This will go just fine if the Makefile only needs to copy and/or package stuff. But it will run into problems the moment it needs to execute other scripts while you have exec turned off (something which @kkaos and myself seem to have in common).

Alas, so far I managed to get rid of these kind of errors (I've seen this with more ports besides lang/perl5.14) by adding:

Code: 
# No staging
NO_STAGE=yes
To /etc/make.conf.

Which forces the ports to use the installation setup as it was in use before. As far as I can tell (didn't dive too deep into staging yet) this basically points the staging directory to the default installation directory. Which is /usr/local.
 
Last edited by a moderator:
kkaos said:
Apparently, the permissions issue was with /tmp because after setting the ZFS exec boolean to "on" for that filesystem, the upgrade worked.
Click to expand...
Be very careful with that, especially if you run a web server. Because it could be a potential entrance for script kiddies the very moment they manage to inject something into your website.

Because having execute permissions on /tmp allows everyone, also the www user, to run scripts from there.
 
ShelLuser said:
Alas, so far I managed to get rid of these kind of errors (I've seen this with more ports besides lang/perl5.14) by adding:

Code: 
# No staging
NO_STAGE=yes
To /etc/make.conf.

Which forces the ports to use the installation setup as it was in use before. As far as I can tell (didn't dive too deep into staging yet) this basically points the staging directory to the default installation directory. Which is /usr/local.
Click to expand...

A recent thread on freebsd-ports suggests that NO_STAGE was never meant to be a user settable variable in make.conf but only for the individual port Makefiles.

http://lists.freebsd.org/pipermail/freebsd-ports/2013-October/086688.html
 
kpa said:
A recent thread on freebsd-ports said that NO_STAGE was never meant to be a user settable variable in make.conf but only for the individual port Makefiles.
Click to expand...
Correct, it needs to be handled with care. But in the mean time we're still in the situation where several ports which should have this defined in their Makefile actually do not. So then the options are to individually edit the offending Makefile, use it on the commandline (which is basically the same thing) or this approach.
 
And so I'm suffering a bit from a code block and in an attempt to spend my morning different looked into this issue because it's most likely going to cause issues for me too.

First I stand corrected; this is most likely related to the new staging feature, but not in the way I imagined it. When you build lang/perl5.14 you'll soon discover a stage directory within the work directory and this turns out to be the so called staging directory in which the whole port binary structure gets placed.

During the whole run the package perl-5.14.4_2.tbz is build in the work directory, and then the trouble begins. This package is added to your system using pkg_add. And from pkg_add(1):

Code: 
FILES
     /var/tmp     Temporary directory for creating the staging area, if envi-
                  ronmental variables PKG_TMPDIR or TMPDIR do not point to a
                  suitable directory.
     /tmp         Next choice if /var/tmp does not exist or has insufficient
                  space.
     /usr/tmp     Last choice if /var/tmp and /tmp are not suitable for creat-
                  ing the staging area.
     /var/db/pkg  Default location of the installed package database.
So it seems to me as if PKG_TMPDIR should have been set and pointed somewhere else. Because if I focus my attention on the newly created Perl package I can reproduce the error easily:

Code: 
root@smtp2:/usr/ports/lang/perl5.14/work # pkg_add -vf perl-5.14.4_2.tbz
Requested space: 59M bytes, free space: 116G bytes in /var/tmp/instmp.aQqbSy
Running pre-install for perl-5.14.4_2..
./+INSTALL: Permission denied
pkg_add: install script returned error status
pkg_add: 1 package addition(s) failed
I can trace pkg_add back to /usr/ports/Mk/bsd.commands.mk and /usr/ports/Mk/bsd.port.mk but since my Ports collection is not maintained by Subversion I can't look into any recent changes.

It looks like a bug to me. I could imagine that the new pkgng package manager does things differently, but that's only a guess on my part.
 
SirDice said:
The type of packages you are using now. There's a new package manager being developed for FreeBSD called PKGNG. This will become the standard on 10.0.
Click to expand...
Not sure, but one can opt out if upgrading from v9, at least while the sources for the old pkg_add are still readily available. Just wanting clarification...
They tried to solve a lot of the issues that plague the 'old' pkg_add(1) and friends.
Click to expand...
Success, but I suspect some lower-power machines may suffer gotchas. Also, IMHO it needs a flowchart that can be updated so that not trivial use cases can be alleviated more quickly.
It works differently when it comes to the files in /var/db/pkg/.
Click to expand...
Does it not effectively put them behind an API, meaning they no longer exist for plain old commands such as grep?
Unfortunately there's no official repository for it yet but if you set it up yourself the new packages work really well.
Click to expand...
BTW if that aforementioned flowchart appears, I'd recommend that its use be understood fully before putting the new pkg tools to use on a production machine, at least one that needs to be updated periodically. This may have the side effect, if it comes to pass, as another reason to recommend FreeBSD over other unix (etc) operating systems as a desktop or server instance.

Apologies for any misinformation put forth or implied herein. I try to keep informed about it all...
 
You must log in or register to reply here.
Back
Top