pkg not found .real_xxxxxxxx

[petabsd]

Hello all,

I set up a local pkg server. When I do pkg install, sometimes I get the following error.

pkg: http://server_address/pkg-default/.real_1412358959/All/xxx.txz: Not Found

I am using poudriere to build the pkg repository, the only possible reason I can think of is that I was using two jails to build the packages, they may be conflict with each other somehow. I can resolve this issue by removing database files in /var/db/pkg, but this is only a quick-fix solution, I wanted to know what causes this issue, If any one can shed some light on this, that would be great! Thanks in advance!

 

[Beeblebrox]

Poudriere changes the.real_xxx name based on its internal programming. Therefore that's not the right path to the package repository.

Look in <path>/poudriere/data/packages/jailname-default. You'll see "All, Latest, digests.txz, meta.txz, packagesite.txz, .real_xxx" as listing. That's your correct repo path and the existing sym-links will point to the new .real_xxx following each poudriere run.

 

[kpa]

I've seen that when ports-mgmt/poudriere fails with of an internal error that leaves the repository in an inconsistent state. You can try to manually figure out which of the directories with names starting with a dot under the repository directory has the packages built so far from the failed run and remove them completely with the directory and then run pkg-repo(8) manually on the repository directory to put it back into a sane state. The development version ports-mgmt/poudriere-devel I'm using now seems to be much more resilient against such errors.

 

[petabsd]

I've seen that when ports-mgmt/poudriere fails with of an internal error that leaves the repository in an inconsistent state. You can try to manually figure out which of the directories with names starting with a dot under the repository directory has the packages built so far from the failed run and remove them completely with the directory and then run pkg-repo(8) manually on the repository directory to put it back into a sane state. The development version ports-mgmt/poudriere-devel I'm using now seems to be much more resilient against such errors.

Thanks for the valuable info @kpa! But I have few follow-up questions. In what machine, should I do the routine you mentioned, the machine which runs poudriere or client machine? I also didn't find failed directories with a dot in the repository directory, the only one with a dot is the one most recently built. And it seemed to me that pkg in the client machine always tries to find the same path, is there anything I can do to update the downloading path in the client machine? Thanks again!

 

[kpa]

It's completely on the repository side, the poor client is just trying to download updated repository catalogs but the symbolic links in the repository directory are pointing to wrong or non-existing directories. Once you have fixed the repository you can force the client to redownload the catalogues with pkg update -f and everything should work.

 

[Beeblebrox]

Try to manually figure out which of the directories with names starting with a dot under the repository directory has the packages built so far from the failed run and remove them completely with the directory and then run pkg-repo(8) manually on the repository directory to put it back into a sane state.

This gets complicated when poudriere has not cleaned up its temporary build folder named packages/jailname-default/.building. Sorting through that is a waste of time. Just delete a trivial package from the repository and re-run poudriere for same trivial package. The repository and folder structure should now be in repaired state, and the .building folder usually removed (some exceptions).

If you ever run into an error where poudriere refuses to start with some message like "cannot delete xyz.txz. No such file", check the .building folder for any symlinks and delete/unlink them. Poudriere should now start without previous error.

The symbolic links in the repository directory are pointing to wrong or non-existing directories.

Above-described poudriere re-run with trivial build will repair this issue also.

ports-mgmt/poudriere-devel seems to be much more resilient.

I concur.

 

[petabsd]

@Beeblebrox, @kpa Thank you so much! I have recovered the poudriere to the repaired state, currently It seems that the problem has been solved, I also will try to use poudriere-devel instead of poudriere for the later management. Thanks again!