Date: Sat, 13 Oct 2007 22:13:26 +0100 From: RW <fbsd06@mlists.homeunix.com> To: freebsd-questions@freebsd.org Subject: Re: I performed an rm -r on /var/lib/pkg Message-ID: <20071013221326.78ede247@gumby.homeunix.com.> In-Reply-To: <200710131705.11020.fbsd.questions@rachie.is-a-geek.net> References: <1192134379.33933.9.camel@secretariat.lanl.gov> <200710122313.59809.fbsd.questions@rachie.is-a-geek.net> <20071013011349.66164ced@gumby.homeunix.com.> <200710131705.11020.fbsd.questions@rachie.is-a-geek.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Oct 2007 17:05:10 +0200
Mel <fbsd.questions@rachie.is-a-geek.net> wrote:
> On Saturday 13 October 2007 02:13:49 RW wrote:
> > On Fri, 12 Oct 2007 23:13:58 +0200
> >
> > Mel <fbsd.questions@rachie.is-a-geek.net> wrote:
> > > On Friday 12 October 2007 22:19:41 RW wrote:
> > > > On Thu, 11 Oct 2007 14:26:19 -0600
> > > >
> > > > James <jamesh@lanl.gov> wrote:
> > > > > Call it a moment of sheer stupidity, call it a misremembering,
> > > > > call it whatever you want (and I imagine I'll hear a few
> > > > > different ones), but I just did an rm -r /var/lib/pkg.
> > > > >
> > > > > Before I type anything to damage things further, does anyone
> > > > > have any suggestions as to how to recover from this? I have
> > > > > other FreeBSD boxes available to me, none with the same pkg
> > > > > list, though. I'll be reading man pkgdb in the meantime..
> > > >
> > > > This came up recently in another thread, and what seemed to be
> > > > the best solution to me, was this:
> > > >
> > > > 1. work out which leaf-ports you actually need - don't worry
> > > > about the dependencies.
> > > >
> > > > 2. at your leisure build new packages under a chroot
> > > > environment, or on another machine.
> > > >
> > > > 3. back-up /usr/local/etc (or the whole of /usr/local)
> > > >
> > > > 4. rm -rf /usr/local/*
> > > >
> > > > 5. Restore /usr/local/etc and install packages.
> > >
> > > Why would you go through 3-5 when you can just
> > > mv /chroot/build/directory/var/db/pkg /var/db/pkg ?
> >
> > For the reasons that that you snipped off the bottom of my post.
> >
> > > > ... avoids leaving any orphaned files,and most
> > > > importantly makes sure that all of the installed package have an
> > > > entry in /var/db/pkg. If you miss any of these entries, it may
> > > > cause a lot of trouble down the line.
> >
> > /chroot/build/directory/var/db/pkg is only a rough guess as to
> > what was actually installed under /usr/local/.
>
> So don't guess if you're that paranoid.
If you haven't kept a list of origins, you may not have much choice
unless the dependencies are simple. Dealing with conflicts is
bad enough when you have a complete record of what's installed.
> It can be much much harder to
> restore some directories under /usr/local to a working state,
> like /usr/local/pgsql, /usr/local/www and some perl ports like rrd.
Whether that is hard to do or not depends on the individual case,
a backed-up /usr/local can easily be restored, if it doesn't work-out.
> Depending how long builds take, it may be faster let a script run
> over /usr/ports/*/* that runs make generate-plist for each port,
> appends grep -v '^@' ${TMPPLIST} into a file, thus building an index
> of every file that a port can install, then let a script run
> over /usr/local that queries that index for each file it encounters.
> Like I said, for the ultra paranoid.
That assumes that everything was installed from the same ports tree,
you know which tree it was, and that every packing-list is accurate
-otherwise it may flag an essential file for deletion.
> > Maybe some forgotten
> > dependency doesn't get included in the new build. A year from now
> > you may find odd build problems, or new port installs may use
> > orphaned files with critical vulnerabilities that portaudit can't
> > detect.
>
> Nope. Orphaned files create stale deps, which are easily found with
> pkgdb -F, because the dependency check checks if ${LOCALBASE}/bin/foo
> exists and if it does adds the dependency to /var/db/pkg.
> Also, `make missing' for a given port easily lists all dependencies
> that aren't in $PKG_DBDIR, so if you run make missing after a new
> install for a while, you'll easily identify those.
It depends what state the ports were in at the time of the accident. If
you haven't run a leaf-cutting program recently you may have old
dependencies and tools that have become leaves - they may take years
to show-up.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071013221326.78ede247>