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
Description: OpenPGP digital signature