Portmaster process hangs during install of port

I use portmaster exclusively to install ports. Now, when I try to install a port, the build appears to go successfully, but then the process hangs with this message:
Code:
===>>> Waiting for background read of distinfo files to finish
After letting it run for many minutes, I kill the process and nothing is installed.

This has also happened with all other ports that I have tried to install.
How can I fix this problem?

I recently upgraded from 13.1 to 13.2.
My system:
Code:
FreeBSD chubb 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 releng/13.2-n254638-d20ece445acf GENERIC amd64


Here is an example trying to install sysutils/cpuid:
Code:
root@chubb:/usr/ports # portmaster sysutils/cpuid

===>>> Port directory: /usr/ports/sysutils/cpuid

===>>> Gathering distinfo list for installed ports

===>>> Launching 'make checksum' for sysutils/cpuid in background
===>>> Gathering dependency list for sysutils/cpuid from ports
make: chdir /usr/ports/databases/ldb14: No such file or directory
===>>> Initial dependency check complete for sysutils/cpuid


===>>> Starting build for sysutils/cpuid <<<===

===>>> All dependencies are up to date

===>  Cleaning for cpuid-etallen-20230120
===>>> Waiting on fetch & checksum for sysutils/cpuid <<<===
===>  License GPLv2 accepted by the user
===>   cpuid-etallen-20230120 depends on file: /usr/local/sbin/pkg - found
=> cpuid-20230120.src.tar.gz doesn't seem to exist in /usr/ports/distfiles//.
=> Attempting to fetch http://www.etallen.com/cpuid/cpuid-20230120.src.tar.gz


===>  License GPLv2 accepted by the user
===>   cpuid-etallen-20230120 depends on file: /usr/local/sbin/pkg - found
===> Fetching all distfiles required by cpuid-etallen-20230120 for building
===>  Extracting for cpuid-etallen-20230120
=> SHA256 Checksum OK for cpuid-20230120.src.tar.gz.
===>  Patching for cpuid-etallen-20230120
/usr/bin/sed -i.bak 's,CFL=.*,& -pthread,' /usr/ports/sysutils/cpuid/work/cpuid-20230120/Makefile
===>   cpuid-etallen-20230120 depends on package: gmake>=4.3 - found
===>   cpuid-etallen-20230120 depends on package: perl5>=5.36<5.37 - found
===>  Configuring for cpuid-etallen-20230120
===>  Building for cpuid-etallen-20230120
gmake[1]: Entering directory '/usr/ports/sysutils/cpuid/work/cpuid-20230120'
cc  -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -g  -Wall -W -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wimplicit-fallthrough -Wunused-parameter -Wundef -D_FILE_OFFSET_BITS=64 -DVERSION=20230120 -pthread  -fstack-protector-strong  -o cpuid cpuid.c
gzip < cpuid.man > cpuid.man.gz
pod2man -r "20230120" -c "" cpuinfo2cpuid > cpuinfo2cpuid.man
gzip < cpuinfo2cpuid.man > cpuinfo2cpuid.man.gz
gmake[1]: Leaving directory '/usr/ports/sysutils/cpuid/work/cpuid-20230120'
===>>> Building the port required 4 seconds
===>  Staging for cpuid-etallen-20230120
===>   Generating temporary packing list
install  -s -m 555 /usr/ports/sysutils/cpuid/work/cpuid-20230120/cpuid /usr/ports/sysutils/cpuid/work/stage/usr/local/bin/cpuid-etallen
install  -m 444 /usr/ports/sysutils/cpuid/work/cpuid-20230120/cpuid.man.gz /usr/ports/sysutils/cpuid/work/stage/usr/local/man/man1/cpuid-etallen.1.gz
====> Compressing man pages (compress-man)
===>  Installing for cpuid-etallen-20230120
===>  Checking if cpuid-etallen is already installed
===>   Registering installation for cpuid-etallen-20230120
Installing cpuid-etallen-20230120...

===>>> Waiting for background read of distinfo files to finish


^C
===>>> Build/Install for sysutils/cpuid exiting due to signal
===>>> Installation of sysutils/cpuid (cpuid-etallen-20230120) complete


===>>> You can restart from the point of failure with this command line:
       portmaster <flags> sysutils/cpuid

This command has been saved to ~/portmasterfail.txt

root@chubb:/usr/ports #
 
I also found that bug report and it is similar to my issue. In my case, entering CR has no effect. Also, I did not use the -P or --package option. In addition, I applied this patch locally, re-ran and got the same results.
 
I think it might be because of this:
Code:
===>>> Gathering dependency list for sysutils/cpuid from ports
make: chdir /usr/ports/databases/ldb14: No such file or directory
I'm guessing it's waiting to download the distfiles from this missing port. Which is never going to complete.

Wondering why it's trying to use databases/ldb14 though, that port was removed a while ago.
 
distinfo should be generated by the port maintainer and it will store the size and checksum of the source file in the port directory. It should not be generated manually via make makesum as it will try to download and create the distinfo regarding of it's size/checksum and if it fail to fetch the fail it will hang up/timeout. So i'm wonder why Portmaster is trying to generate it again.

Edit:
ohh it generate list of the distinfo files, not the actual distinfo. You can ignore my post.
 
Wondering why it's trying to use databases/ldb14 though, that port was removed a while ago.
Would be picked as one of the dependencies of "currently installed" ports.

I myself never used portmaster (using portupgrade from when I first found it as the "only one" port upgrading tool at the moment, and until when FLAVOUR is introduced. After FLAVOUR, which portupgrade cannot handle properly, is introduced, I've switched to pkg_replace) so not 100% sure, though.
 
Lots of folks also "forget" to run pkg-autoremove(8) to remove old dependencies.
Is it safe now?
I don't give myself the authority to do so with my old experience.
In relatively early days when pkg is introduced, I've tried it and it deinstalled EVERY PORTS MARKED AS AUTOMATIC. If I didn't created ZFS snapshots of all datasets mounted under /usr/local and /var, and rolling back was impossible, it should have been catastrophic. Is it fixed now?
Instead, I kept using ports-mgmt/pkg_rmleaves for the purpose. It detects actual leaf ports, lists them with dialog like ports options, and mark what port to deinstall and actually deinstall them. And after that, checks for new leaves appeared as the result and allows recursive deinstall until no more new leaves appears.
 
I've tried it and it deinstalled EVERY PORTS MARKED AS AUTOMATIC. If I didn't created ZFS snapshots of all datasets mounted under /usr/local and /var, and rolling back was impossible, it should have been catastrophic.
There's a yes/no question. Don't choose 'yes' if it wants to delete things you need.

Secondly, you can set packages to non-automatic. You sometimes need to do this if a tool you used was originally installed as a dependency but the original dependent package/port was removed. pkg set -A0 <packagename> See pkg-set(8).
 
There's a yes/no question. Don't choose 'yes' if it wants to delete things you need.
Unfortunately, I cannot recall whether it was displayed or not. But possibly, I've missingly touched "y" key at the moment...but did not intentional, at least. It was too early days of pkg.
You sometimes need to do this if a tool you used was originally installed as a dependency but the original dependent package/port was removed.
If I recall correctly, all ports installed by ports-mgmt/portupgrade was considered as automatic even if it was a leaf port at the moment.
 
Unfortunately, I cannot recall whether it was displayed or not.
By default it does and has done so since it's inception. It also defaults to "no", in case you just absentmindedly hit enter. You can run this entirely automatic but I don't recommend doing that as it can and will remove everything that doesn't have a dependency any more.

If I recall correctly, all ports installed by ports-mgmt/portupgrade was considered as automatic even if it was a leaf port at the moment.
build dependencies are always installed as 'automatic'. You may be thinking of those. They are not required for a port/package to run and can be removed once the build is done.
 
Back
Top