Solved "make config" never offers any options

R

rpert

Whenever I try to make config a port it does not give me any options eg.

Code: 
# make config
===> Options unchanged
#

Also checking make rmconfig, it's the same.

Code: 
# make rmconfig
===> No user-specified options configured for postfix-2.11.5,1
#

What should I be looking for that's missing in my configuration that prevents make offering up the various compile options for various ports?

Code: 
# uname -a
FreeBSD localhost 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
#
 
UPDATE: My investigation into this problem led me to:
man ports and /usr/ports/Mk/bsd.port.mk which led me to understand what was missing was the port options dialog offered by the package dialog4ports. That package was not installed and missing on my system. After installing it the port options dialog appears again as it should.
 
junovitch said:
That's rather strange. For me make config on a system without it will trigger an installation of ports-mgmt/dialog4ports automatically. Do you have any changes or customization that would prevent that behavior?
Click to expand...

I'll confess that more than a year ago this box was FreeBSD-9.0 RELEASE and I entered rm -Rvf * will logged in as root from within the / directory. It cleared out everything in / /etc /bin and plenty of l /usr/local before I caught it. /boot was safe as it is on a separate partition. I repaired the system using files which I copied over from memstick.img and since then I've used freebsd-update to upgrade to FreeBSD-10.1 RELEASE. This involved upgrading to pkg from the old tool-set. To date everything works fine with only very infrequent hiccups.

I'm still not sure why automatic installation of ports-mgmt/dialog4ports didn't get triggered by make. Maybe it didn't because it was once installed and removed by file deletion rather that the correct deinstallation method. If this makes sense, is there a database somewhere I should examine on my system to find other packages that were not removed correctly i.e by file deleting?

junovitch said:
Unrelated observation based on your uname -a, you should run a freebsd-update fetch and freebsd-update install to play catch up on security advisories. See https://www.freebsd.org/security/advisories.html.
Click to expand...

Thanks for that.

Code: 
# uname -a
FreeBSD boxx.roth.ca 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
#

Does it look better now?
 
AnthonyL said:
I'll confess that more than a year ago this box was FreeBSD-9.0 RELEASE and I entered rm -Rvf * will logged in as root from within the / directory. It cleared out everything in / /etc /bin and plenty of l /usr/local before I caught it. /boot was safe as it is on a separate partition. I repaired the system using files which I copied over from memstick.img and since then I've used freebsd-update to upgrade to FreeBSD-10.1 RELEASE. This involved upgrading to pkg from the old tool-set. To date everything works fine with only very infrequent hiccups.
Click to expand...

Since you are using freebsd-update(8), try a freebsd-update IDS. I would have thought the upgrade process would have replaced any files that are important but that should give you a baseline as to whether anything in the base system doesn't match up to what should be there. Only config files under /etc should be reported.

AnthonyL said:
I'm still not sure why automatic installation of ports-mgmt/dialog4ports didn't get triggered by make. Maybe it didn't because it was once installed and removed by file deletion rather that the correct deinstallation method. If this makes sense, is there a database somewhere I should examine on my system to find other packages that were not removed correctly i.e by file deleting?
Click to expand...

I don't believe so and I don't think it would matter. For example, if I delete a file it gets reported as unavailable when the package gets removed but doesn't stop the process.
# rm /usr/local/bin/vim
# pkg delete vim-lite
Code: 
[test-jail] [1/1] Deinstalling vim-lite-7.4.712...
[test-jail] [1/1] Deleting files for vim-lite-7.4.712:   0%
pkg: cannot stat /usr/local/bin/vim: No such file or directory
[test-jail] [1/1] Deleting files for vim-lite-7.4.712: 100%
# pkg info vim-lite
Code: 
pkg: No package(s) matching vim-lite

I'm assuming you re-installed all packages as part of the major revision change. If so, that should have resolved any issues from the inadvertent rm.

AnthonyL said:
Does it look better now?
Click to expand...
Yes and a few less issues to be concerned about by staying up to date on security fixes.
 
junovitch said:
Since you are using freebsd-update(8), try a freebsd-update IDS. I would have thought the upgrade process would have replaced any files that are important but that should give you a baseline as to whether anything in the base system doesn't match up to what should be there. Only config files under /etc should be reported.
Click to expand...

Thanks for freebsd-update IDS recommendation. There were a few thousand errors most of which were SHA256 mismatch errors. I used sed to reformat the output of freebsd-update IDS and run it as a script to replace mismatched files. Now, excluding the obvious in /etc there remains only a few lines of errors after running freebsd-update IDS.

Code: 
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.1-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
/etc/mtree/BSD.include.dist has SHA256 hash 7e5a09073df75bbdf1dc214a266b41d999a9e369104374fd14d1bc129
/etc/mtree/BSD.root.dist has SHA256 hash 6359e749f80ecfc3c71ffe420904c2ea27115bf049fc4ee58f79202e45fc
/etc/mtree/BSD.sendmail.dist has SHA256 hash 6072ac6c0d42a4b028a88805a9138b09af48e9b1fa4cc0a2be6dd975
/etc/mtree/BSD.usr.dist has SHA256 hash 0ec33ebd3f125b63ad369484fe62afbebe08b4b94511b8231ceedb702bb57
/etc/mtree/BSD.var.dist has SHA256 hash 5e2e4bb53ed967a9c7f8fa378406fb9f65ad06e12b1fd9c36aab85956e003
/tmp has 0777 permissions, but should have 1777 permissions.
/var/db/mergemaster.mtree has SHA256 hash b23b31a47aa6efd174b8a12e81c37eaed4c6e98194ea6c85f4dbf005841
/var/db/mergemaster.mtree has SHA256 hash b23b31a47aa6efd174b8a12e81c37eaed4c6e98194ea6c85f4dbf005841
/var/db/mergemaster.mtree has SHA256 hash b23b31a47aa6efd174b8a12e81c37eaed4c6e98194ea6c85f4dbf005841
From the above I can't seem to correct the permissions on /tmp.

Here is the output of ls -la / | grep tmp (Something is wrong here, I think.)
Code: 
drwxrwxrwt  16 root  wheel     1216 May 28 12:58 tmp

Also, I'm unsure about what to do with the files /etc/mtree/ and /var/db/mergemaster.mtree

Everything else seems to be fine now, I hope.
 
You must log in or register to reply here.
Back
Top