Amit Kulkarni wrote on 11/08/16 07:22:
On Tue, Nov 8, 2016 at 12:53 AM, Clint Pachl <pa...@ecentryx.com> wrote:
Ax0n wrote on 09/03/16 13:12:
I've got a Toshiba NB305 netbook that's been my daily-use laptop for more
than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in
early May 2011. I've been quite happy with how it works, and I've been
doing bsd.rd upgrades and M:Tier binary updates ever since.
There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with
an
atime of my last level 0 dump several months ago. Looks like pkg_add -u
left a bunch of stuff behind. Is there a recommended way to clean this
stuff up, or should I just start chopping away with something like:
find /usr/local/lib -type f -atime +90 | doas xargs rm
(after a new level 0 dump, obviously...)
Ax0n wrote on 09/03/16 13:12:
I've got a Toshiba NB305 netbook that's been my daily-use laptop for more
than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in
early May 2011. I've been quite happy with how it works, and I've been
doing bsd.rd upgrades and M:Tier binary updates ever since.
There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with
an
atime of my last level 0 dump several months ago. Looks like pkg_add -u
left a bunch of stuff behind. Is there a recommended way to clean this
stuff up, or should I just start chopping away with something like:
find /usr/local/lib -type f -atime +90 | doas xargs rm
(after a new level 0 dump, obviously...)
I've been removing the old system during the upgrade script since 4.9,
coincidentally. I haven't had a problem yet while upgrading two production
servers and my two laptops, from release to release.
After selecting the OS sets during the upgrade, but before hitting ENTER,
type ! at the “Set name(s)?� prompt to enter a shell. Then run: `cd /mnt
&&
rm -rf bin sbin usr/!(local) && exit`. Then just hit enter and continue
running the upgrade script.
WARNING: this will wipe out your system, so if the upgrade fails for some
reason, you are TOTALLY SCREWED!
I periodically (every few releases) clean out /usr/local. First, get a
list of manually installed packages using `pkg_info -m`. Then uninstall
everything. It is interesting to see what gets left behind. If any garbage
is left over, remove it. Then reinstall from your generated list. I don't
do this very often anymore as `pkg_delete -a` seems to clean up quite well.
As insurance, I take level 0 dumps just before upgrading or cleaning
/usr/local. Also, one of my laptops is a spare that has all the same
software installed as the production servers and my main laptop. So this
laptop is a test run if you will. If there are quirks, my main laptop is my
second chance to make sure I know what the hell I'm doing before finally
upgrading my two production systems.
Also, just a public announcement, test your restore-from-backup process
once in awhile.
I've always thought about sharing this process, but always thought it is
probably not the best advice.
Clint,
pkg_add sysclean
This will restore your system as close to a new install as possible. What
you are doing is quite dangerous.
But the very next step in the upgrade blows away the system by
overwriting it anyway. Right?
What could happen? What if following the normal procedure of untaring
the OS sets on top of the existing system fails midway? Then you have an
inconsistent system too.
I'd rather start with a clean slate and build on top of that than chip
away at an existing, running system, which others have recommended via
the sysclean package (I haven't looked at the code so I don't know what
it does, but I wouldn't trust it until I inspected the code).
I have all my OS sets and packages stored on a local server along with
my level 0 dumps, which I've never needed by the way. If the worst
happens, I just PXE boot the ramdisk image and do a quick restore of the
system to where it was just before the upgrade.
I've always liked the clean install process, and this modified process
gets me close without actually doing a clean install. I've done this for
11 releases now with 4 systems without any problems. Just thought I'd
share, but with the warnings I provided earlier.
This behavior of mine may stem from my days as a hard-real-time embedded
systems engineer where we had to get rid of every single byte that did
not matter. I used to count the assembly instructions and add up all the
clock cycles for each hardware interrupt routine to make sure we would
never stall/slow the system. I just like minimal I guess.
