Re: Critique this plan?

On 2017/07/20 11:22, Jeffrey Bouquet wrote:
>   It seems I've a brick wall [too many ports to use pkg effectively ] -- [ 3551 ] 
> and too many need ' pkg lock ' in ' v11 ' for ino64 fixes, 12.0-CURRENT, and quite a few
> others fail to build from ports, either compiler, so are also 'pkg lock ' or in a few
> instances binaries/trees copied from other installs, so that my DESKTOP can continue
> running a if it were 2003 Microsoft based, vs 2004 Freebsd January based, where a reinstall
> seems in order OR, I should just sit and wait til 13.0-CURRENT and proceed that way.

You're proposing to make a backup of your system in spare space on your
hard drive, and then install a pristine system and backport your various
changes to it in order to bring your system up to date?

Waiting for 13.0-CURRENT probably won't solve all your compilation and
package management problems, or at least, not all of them.  You'ld be
better off updating now, but trying to clean up all your local changes
as far as possible so that future upgrades are less traumatic.

> ..................
>   Meantime, how is the following as a workaround
>   mv /usr/src /src-2017
>   mv /usr/obj /obj-2017
>   mkdir -p /usr/src
>   mkdir -p /usr/obj
>   cd /usr/src
>   bw, etc
> ....................
> or
> .....................
>  [ clean install ]
>  mount -t ufs /dev/gpt/2004root /mnt-root
>  mount -t ufs /dev/gpt/2004var  /mnt-var
>  mount -t ufs /dev/gpt/2004tmp  /mnt-tmp
>   mount -t ufs /dev/gpt/2004usr /mnt-usr
>  into which I surmise an installworld would fail as multiple DESTDIRS are included. 

You can do:

mount -t ufs /dev/gpt/2004root /mnt
mount -t ufs /dev/gpt/2004var  /mnt/var
mount -t ufs /dev/gpt/2004tmp  /mnt/tmp
mount -t ufs /dev/gpt/2004usr  /mnt/usr

so your copy of your 2004 system is laid out below /mnt as it would be
when live.  If you also do:

mount -t devfs devfs /mnt/dev

then you can chroot into /mnt, although I'm not sure quite how useful
that would be to you.

> .................
>   nullfs ?
> ...............
>  Revert to all-in-one / system, no /var /tmp /usr?
> .............
>  or some new install 
> .............
>   None of these are plans as of yet, save proceeding without any upgrade whatsoever.  I recall
> unpacking base.txz [etc] to fix a failing installworld in the recent past, so any foolproof
> method of that would also be welcome.  But I suspect much would remain undone, 
> initial *proper* setup of /etc/mail, /etc/groups, as well as the loss of fine-tunings I've
> done over the past 13 years or so, if it were done preplanned as a new-then-rsync-the-old
> system-over-it sort of reinstall  [ not looking forward to undoing years of week-by-week
> this-rc  that-rc fixups...      newbie in so many areas who just copy-pasted the
> work of others into this system, to excellent, usually effect.    ] 
> .............. 

Yeah.  You've a lot of work ahead reviewing each of your changes and
porting what you need to the new version.

As a matter of routine system maintenance, it is good practice to try
and revert local changes and track updates to the default system when
possible -- ie. to adopt any upstream fixes as they become available.

>   Apologies for the email that went on three times longer [ more verbose  ] than I planned, sort
> of making its Subject:            a  misstatement of the body of the email.
> ......................
> ...................

If you're planning on working from a new install, my advice would be to
summarize what functionality you want from your system as a series of
bullet points and then only port whichever of your changes you need in a
directed fashion to achieve each of those points.  Do this as cleanly as
possible, so you can achieve your required functionality with the
minimum amount of configuration work / local patches.

	Cheers,

	Matthew