bob prohaska <fbsd_at_www.zefox.net> wrote on
Date: Sun, 06 Nov 2022 03:12:04 UTC :
> On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> >
> > Your /etc/rc.d/ldconfig script seems to have not been updated
> > by use of etcupdate or mergemaster or other such. (How much
> > else is also out of date? How much of what you have for /etc/
> > and the like goes back to 2022-Jan-07 or before?)
> >
>
> Alas, that is too true. The system was set up on July 2, 2020
> and I've never managed to make sense of either mergemaster nor
> etcupdate. Far as I could tell it didn't matter, the host ran
> correctly, until now.
>
> It's been transplanted to a new hard drive, which allows the
> installation of a ports tree. Ports don't install because of
> the stale /etc/rc.d/ldconfig file.
>
> Since no changes have been made to /etc/ apart from /etc/rc.conf
> is it possible to simply let mergemaster or etcupdate install
> the latest defaults? I have looked at the manpage for etcupdate
> and didn't recognize any straightforward way to simply accept
> all updates. This particular system is expendable, so I'd be
> glad to try things that might not work well, or at all.
>
> Apologies if I'm being dumb (probably guilty) or lazy (definitely
> guilty). The barrage of questions generated by etcupdate and
> mergemaster is simply overwhelming. And, I suspect, largely
> unnecessary.
[We will see if this helps or not . . .]
Before worrying about the actual updates, I'd start by just
establishing a set of default files to look at.
There are 2 contexts overall:
A) The source commit vintage for the live system
vs.
B) The source commit vintage for the update to be installed
at some point
At this point I'm only dealing with (A).
Is your /usr/src/ the proper content for (A)? (B)? Something
else?
If you do not have a /usr/src/ that is the proper content for
(A), then you need to create a directory tree that does contain
such a source tree, such as via using git or other such to
establish the source tree.
I'll refer to: /usr/livesrc/
The command:
# etcupdate extras -s /usr/livesrc
will create: /var/db/etcupdate/current/
There you can look at the various default file contents.
More than /etc/ material will be present, for example:
/var/db/etcupdate/current/.cshrc
/var/db/etcupdate/current/.profile
/var/db/etcupdate/current/COPYRIGHT
/var/db/etcupdate/current/root/.cshrc
/var/db/etcupdate/current/root/.k5login
/var/db/etcupdate/current/root/.login
/var/db/etcupdate/current/root/.profile
/var/db/etcupdate/current/root/.shrc
/var/db/etcupdate/current/usr/share/nls/POSIX
/var/db/etcupdate/current/usr/share/nls/en_US.US_ASCII
/var/db/etcupdate/current/var/crash/minfree
Some files that you create or edit might not show up
under current/ at all. ( /etc/fstab and /etc/rc.conf
would be examples. )
You might not want to look at all the mismatches. But
you might want to look at the output of something like:
# find -s /var/db/etcupdate/current/ -print | more
to see if it reminds you of any files that you do want
preserve a copy of the old content of for reference. An
example might be: /etc/sysctl.conf
There could be others.
I'd expect that the following sort of command sequence
would mostly replace the live system's files with the
defaults (presumes done as root to be sure that files
are replaceable):
# cd /var/db/etcupdate/current/
# cp -aRx . /
However, there might be questions about hard links and
softlinks in the from-side or the to-side and how
things end up with such involved (after the cp -aRx
completes).
Note that you may have more build installs around that
you might need to be sure that they track, such as
directories for chroot use. This can get into using
command line options that indicate context so that
each context gets its own tracking. It should also
change things, like /var/db/etcupdate/current/
to have a path prefix involved:
/PATHPREFIX/var/db/etcupdate/current/
As for updates, I have scripts that do something like:
# #PRIOR source update and buildworld buildkernel ACTIVITY HERE.
# etcupdate . . . -p
# etcupdate . . . resolve -p
# make . . . installkernel . . .
# make . . . installworld . . .
# etcupdate
# etcupdate resolve
# make . . . delete-old check-old -DBATCH_DELETE_OLD_FILES
Note: delete-old-libs may need to be in its own time frame,
after one is sure that those libraraies are no longer
in use so that the delete will not break anything.
# etcupdate status
# etcupdate resolve
However, being paranoid, I use a script that runs each
etcupdate command with a context specified. An example
is:
env __MAKE_CONF="/usr/home/root/src.configs/make.conf" \
SRCCONF="/dev/null"
SRC_ENV_CONF="/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host"
\
MAKEOBJDIRPREFIX="/tmp/usr/obj/BUILDs/main-CA72-nodbg-clang" \
etcupdate $* -s /usr/main-src -M TARGET_ARCH=aarch64
Note the $* which is where the command line arguments to the
script would go.
Similarly for my make commands:
kldload -n filemon && \
cd /usr/main-src && \
mkdir -p /usr/obj/BUILDs/main-CA72-nodbg-clang/sys-typescripts && \
env __MAKE_CONF="/usr/home/root/src.configs/make.conf" \
SRCCONF="/dev/null"
SRC_ENV_CONF="/usr/home/root/src.configs/src.conf.CA72-nodbg-clang.aarch64-host"
\
MAKEOBJDIRPREFIX="/usr/obj/BUILDs/main-CA72-nodbg-clang" \
WITH_META_MODE=yes \
make $*
Part of this is that I've got far more than just one
environment that I build/install. Thus parts of my context
do not make for simple examples.
(I'll not get into why I have /tmp in the front of the
MAKEOBJDIRPREFIX for etcupdate --but not for make .)
===
Mark Millard
marklmi at yahoo.com
