Re: I performed an rm -r on /var/lib/pkg
Feeding pkgdb/pkg_which a port creates a directory for that port in /var/db/pkg. It then returned a question mark, which kind of sucked, silence being golden in unix, but I had an entry for openmpi appear in /var/db/pkg Is this really just meaningless grasping at straws? It looked like this in conjunction with pkgdb -L would work. James I've been running this for a while now, and it looks like it's working, it just needs liberal doses of pkgdb -F occasionally. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, 2007-10-18 at 20:11 +0100, RW wrote: On Thu, 18 Oct 2007 12:51:33 -0600 James [EMAIL PROTECTED] wrote: 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] I just discovered pkg_which. I'm thinking I can use this to solve my (still haven't worked on) problem. Any ideas why this might be a bad idea? I essentially feed it a list from /usr/ports/distfiles and move on. Do you have the database file? The default location is in the directory you deleted. Yes. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Feeding pkgdb/pkg_which a port creates a directory for that port in /var/db/pkg. It then returned a question mark, which kind of sucked, silence being golden in unix, but I had an entry for openmpi appear in /var/db/pkg Is this really just meaningless grasping at straws? It looked like this in conjunction with pkgdb -L would work. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] I just discovered pkg_which. I'm thinking I can use this to solve my (still haven't worked on) problem. Any ideas why this might be a bad idea? I essentially feed it a list from /usr/ports/distfiles and move on. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, 18 Oct 2007 12:51:33 -0600 James [EMAIL PROTECTED] wrote: 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] I just discovered pkg_which. I'm thinking I can use this to solve my (still haven't worked on) problem. Any ideas why this might be a bad idea? I essentially feed it a list from /usr/ports/distfiles and move on. Do you have the database file? The default location is in the directory you deleted. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Saturday 13 October 2007 02:13:49 RW wrote:
On Fri, 12 Oct 2007 23:13:58 +0200
Mel [EMAIL PROTECTED] wrote:
On Friday 12 October 2007 22:19:41 RW wrote:
On Thu, 11 Oct 2007 14:26:19 -0600
James [EMAIL PROTECTED] 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. 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.
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.
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.
--
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Sat, 13 Oct 2007 17:05:10 +0200
Mel [EMAIL PROTECTED] wrote:
On Saturday 13 October 2007 02:13:49 RW wrote:
On Fri, 12 Oct 2007 23:13:58 +0200
Mel [EMAIL PROTECTED] wrote:
On Friday 12 October 2007 22:19:41 RW wrote:
On Thu, 11 Oct 2007 14:26:19 -0600
James [EMAIL PROTECTED] 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.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Oct 11, 2007, at 5:39 PM, James wrote: On Thu, 2007-10-11 at 18:14 -0400, Robert Huff wrote: James writes: What has happened, though, is I've never ran rm in /usr/ports/distfiles. I'm going to think for a little bit about a script that can move through /usr/ports/distfiles and reinstall everything that exists there. Having been in almost the identical situation for different rasons, I sympathize. Yes, this will involve a sweep through /usr/ports distfiles. If you haven't ever deleted anything, I suggest a prelimiary manual run deleting everything but the most recent version. This has a down-side, but it will prevent cluttering the rebuilt system with unused ports. /usr/ports/distfiles is definitely looking promising. awk is too damn painful to work with, so I'm going to dust off my perl skills. Hell, this could actually turn out to be fun. And if I write the script properly, it might make a nice disaster recovery tool for /usr/ports/ports-mgmt - it can be called WhenYou'reAnIdiotLikeJamesWasOnFreeBSDQuestions Well, if you figure out what ports you have installed, you can regenerate the pkgdb using: make -DNO_BUILD -DNO_INSTALL generate-plist fake-pkg for each port. I just tested that using a temporary PKG_DBDIR. In case you wanna see what happens, here's what I did: mkdir -p /tmp/var/db/pkg cd /usr/ports/shells/bash env PKG_DBDIR=/tmp/var/db/pkg make -DNO_BUILD -DNO_INSTALL \ generate-plist fake-pkg Wow, that's great! I understand that it has the caveats that you mentioned, but it's *at least* a fantastic start. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] If you don't run 'make clean' then you can look for the 'work' directory to know if you've installed it or not. But some of the port tools automatically run make clean for you so they would disappear. A simple 'find /usr/ports -type d -name work' would probably work well enough unless you wanted it all automated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Fri, Oct 12, 2007 at 10:57:59AM -0600, James wrote: This isn't quite as simple as I'd hoped it'd be to fix. Here's my findings thus far (I haven't started writing my script yet, but I will later today): 1. /usr/ports/distfiles contains everything I need 2. distfiles contains several versions of some packages, but that's pretty trivial to resolve. 3. distfiles contains some packages whose source tarballs are named *differently* to the packages themselves, such as unrar. A few more problems: a) Not every port will have a corresponding tarball in /usr/ports/distfiles. A few ports have all the source directly in the ports tree. This means that your point 1) above is not necessarily true. b) Several ports have many tarballs in /usr/ports/distfiles c) A few of the tarballs can be used by more than one port. It's number 3 that's getting me. It looks like the simplest thing might be an if statement: if (make search name=$PACKAGE) score! else grep -r $PACKAGE /usr/ports But before I go that far, I wanted to see if anyone had an alternate idea for what might work. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Friday 12 October 2007 18:57:59 James wrote:
This isn't quite as simple as I'd hoped it'd be to fix. Here's my
findings thus far (I haven't started writing my script yet, but I will
later today):
1. /usr/ports/distfiles contains everything I need
2. distfiles contains several versions of some packages, but that's
pretty trivial to resolve.
3. distfiles contains some packages whose source tarballs are named
*differently* to the packages themselves, such as unrar.
It's number 3 that's getting me. It looks like the simplest thing might
be an if statement:
if (make search name=$PACKAGE)
score!
else
grep -r $PACKAGE /usr/ports
But before I go that far, I wanted to see if anyone had an alternate
idea for what might work.
Depends on your time and harddisk speed I suppose. You could:
for CAT in *; do
if test -d ${CAT}; then
cd ${PORTSDIR:=/usr/ports}/${CAT}
for PORT in *; do
if test -d ${PORT}; then
cd ${PORT}
make -V DISTNAME /usr/ports/distname.idx
cd ..
fi
done
fi
done
This would give you a distname index to work with. I checked INDEX-6 but don't
see a DISTNAME listed in there. I suppose I'd make the decision myself based
on how many I can't locate. Doing this for 10 ports I can easily guess myself
is nice for academics, but not when you're on the clock.
--
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Oct 12, 2007, at 11:57 AM, James wrote:
This isn't quite as simple as I'd hoped it'd be to fix. Here's my
findings thus far (I haven't started writing my script yet, but I will
later today):
1. /usr/ports/distfiles contains everything I need
2. distfiles contains several versions of some packages, but that's
pretty trivial to resolve.
3. distfiles contains some packages whose source tarballs are named
*differently* to the packages themselves, such as unrar.
It's number 3 that's getting me. It looks like the simplest thing
might
be an if statement:
if (make search name=$PACKAGE)
score!
else
grep -r $PACKAGE /usr/ports
But before I go that far, I wanted to see if anyone had an alternate
idea for what might work.
James
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
[EMAIL PROTECTED]
Try something more akin to this.
find /usr/ports/devel -name distinfo -exec grep -l ddd-3.3.11.tar.gz
'{}' \; | cut -d / -f 1-5
You'd have to change ddd-3.3.11.tar.gz(I used it because I had it), but
you can then output a list of all the directories you need to build the
port in. You can then probably use xargs to automatically make that
port.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Friday 12 October 2007 00:39:27 James wrote:
On Thu, 2007-10-11 at 18:14 -0400, Robert Huff wrote:
James writes:
What has happened, though, is I've never ran rm in
/usr/ports/distfiles. I'm going to think for a little bit about
a script that can move through /usr/ports/distfiles and reinstall
everything that exists there.
Having been in almost the identical situation for different
rasons, I sympathize.
Yes, this will involve a sweep through /usr/ports distfiles.
If you haven't ever deleted anything, I suggest a prelimiary manual
run deleting everything but the most recent version. This has a
down-side, but it will prevent cluttering the rebuilt system with
unused ports.
/usr/ports/distfiles is definitely looking promising. awk is too damn
painful to work with, so I'm going to dust off my perl skills.
Hell, this could actually turn out to be fun. And if I write the script
properly, it might make a nice disaster recovery tool
for /usr/ports/ports-mgmt - it can be called
WhenYou'reAnIdiotLikeJamesWasOnFreeBSDQuestions
Well, if you figure out what ports you have installed, you can
regenerate the
pkgdb using:
make -DNO_BUILD -DNO_INSTALL generate-plist fake-pkg
for each port.
I just tested that using a temporary PKG_DBDIR. In case you wanna see
what happens, here's what I did:
mkdir -p /tmp/var/db/pkg
cd /usr/ports/shells/bash
env PKG_DBDIR=/tmp/var/db/pkg make -DNO_BUILD -DNO_INSTALL \
generate-plist fake-pkg
Wow, that's great! I understand that it has the caveats that you mentioned,
but it's *at least* a fantastic start.
OK, found the culprit after some digging. Quite enlightening. The pkg_create
command gets fed the output of make actual-depends-list, which generates a
package dependency list based on what's really installed, by looking
into /var/db/pkg. Of course this doesn't work for you.
The solution lies in PKG_ARGS. I created a Makefile.local in x11/kdebase3 (cuz
I was there), with the following one-liner:
PKG_ARGS= -v -c -${COMMENT:Q} -d ${DESCR} -f ${TMPPLIST} -p
${PREFIX} -P `cd ${.CURDIR} ${MAKE} package-depends | ${GREP} -v -E
${PKG_IGNORE_DEPENDS} | ${SORT} -u -t : -k 2` ${EXTRA_PKG_ARGS}
$${_LATE_PKG_ARGS}
This is a copy of PKG_ARGS as defined in /usr/ports/Mk/bsd.port.mk with the
difference that it uses package-depends rather then actual-package-depends to
generate the dependency list.
I'm 90% sure this ignores any WITH_ knobs/options you've set to generate the
dependency list, so you'll have to fix any stale dependencies with pkgdb -F
or similar tools later.
Adding the above line to /etc/make.conf should work for you - make sure it's
one line or escape properly ;)
--
Mel
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
This isn't quite as simple as I'd hoped it'd be to fix. Here's my findings thus far (I haven't started writing my script yet, but I will later today): 1. /usr/ports/distfiles contains everything I need 2. distfiles contains several versions of some packages, but that's pretty trivial to resolve. 3. distfiles contains some packages whose source tarballs are named *differently* to the packages themselves, such as unrar. It's number 3 that's getting me. It looks like the simplest thing might be an if statement: if (make search name=$PACKAGE) score! else grep -r $PACKAGE /usr/ports But before I go that far, I wanted to see if anyone had an alternate idea for what might work. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, 11 Oct 2007 14:26:19 -0600 James [EMAIL PROTECTED] 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. (If you have xorg installed, and it's not up-to-date, you may need to consider /usr/X11R6 too) This seems to be a good solution, it avoids more than a few minutes disruption, 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Friday 12 October 2007 22:19:41 RW wrote: On Thu, 11 Oct 2007 14:26:19 -0600 James [EMAIL PROTECTED] 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 ? -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Fri, 12 Oct 2007 23:13:58 +0200 Mel [EMAIL PROTECTED] wrote: On Friday 12 October 2007 22:19:41 RW wrote: On Thu, 11 Oct 2007 14:26:19 -0600 James [EMAIL PROTECTED] 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/. 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
I performed an rm -r on /var/lib/pkg
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.. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
James 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.. I'm guessing you might be Real Tired(tm). Do you mean /var/db/pkg? $ ll /var/lib/pkg ls: /var/lib/pkg: No such file or directory Kevin Kinsey -- The proof of the pudding is in the eating. -- Miguel de Cervantes ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, 2007-10-11 at 15:53 -0500, Kevin Kinsey wrote: James 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.. I'm guessing you might be Real Tired(tm). Do you mean /var/db/pkg? $ ll /var/lib/pkg ls: /var/lib/pkg: No such file or directory Kevin Kinsey Yes, you're right. On all counts, I'm afraid. But, yes, ultimately. And the more I'm reading man pages, the more I'm thinking that the only solution here will be to reinstall everything. I was wondering if portmaster or something similar might be able to solve this, but it looks like /var/db/pkg is what *everything* refers to. I'm feeling like the least competent user in the world right now. Though it *does* teach me a valuable lesson about backing up. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, Oct 11, 2007 at 03:07:37PM -0600, James wrote: On Thu, 2007-10-11 at 15:53 -0500, Kevin Kinsey wrote: James 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.. I'm guessing you might be Real Tired(tm). Do you mean /var/db/pkg? $ ll /var/lib/pkg ls: /var/lib/pkg: No such file or directory Kevin Kinsey Yes, you're right. On all counts, I'm afraid. But, yes, ultimately. And the more I'm reading man pages, the more I'm thinking that the only solution here will be to reinstall everything. I was wondering if portmaster or something similar might be able to solve this, but it looks like /var/db/pkg is what *everything* refers to. Yes, /var/db/pkg/ is where all the information about installed ports/packages is stored. To recreate that information you will have to reinstall everything. I'm feeling like the least competent user in the world right now. Though it *does* teach me a valuable lesson about backing up. Backups are good, yes. Regular, up-to-date, backups are even better. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
James wrote: Yes, you're right. On all counts, I'm afraid. But, yes, ultimately. And the more I'm reading man pages, the more I'm thinking that the only solution here will be to reinstall everything. I was wondering if portmaster or something similar might be able to solve this, but it looks like /var/db/pkg is what *everything* refers to. I'm feeling like the least competent user in the world right now. Though it *does* teach me a valuable lesson about backing up. Well, first off, be glad you weren't in / with your rm. :-) I'll go out on a limb (IANAE), and suggest to you that /var/db/pkg is very important when installing, removing, and upgrading ports (or 3rd party software), but it's not critical to the moment by moment operating of such ports. So, it's quite possible that everything can wait until you get some sleep. However, you are probably right about reinstall everything being the course of action to take. Another possibility: get another box, install everything on that, and copy /var/db/pkg over. You will probably face some issues with consistency in the package database as a result. This will cause a few problems when you get ready to update in the future; however, you can't really get stuck too badly as a deinstall/reinstall will usually fix such things. ... then, of course, you have the possibility that a dependency will not work with the new program. This sort of thing bites in any number of ways, especially after a reboot. I'd probably try to wait for a period of relatively low demand on the box, then do the reinstalling. And get some sleep first ;-) But, as I said, IANAE. Kevin Kinsey -- One way to make your old car run better is to look up the price of a new model. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, 2007-10-11 at 23:13 +0200, Erik Trulsson wrote: On Thu, Oct 11, 2007 at 03:07:37PM -0600, James wrote: On Thu, 2007-10-11 at 15:53 -0500, Kevin Kinsey wrote: James 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.. I'm guessing you might be Real Tired(tm). Do you mean /var/db/pkg? $ ll /var/lib/pkg ls: /var/lib/pkg: No such file or directory Kevin Kinsey Yes, you're right. On all counts, I'm afraid. But, yes, ultimately. And the more I'm reading man pages, the more I'm thinking that the only solution here will be to reinstall everything. I was wondering if portmaster or something similar might be able to solve this, but it looks like /var/db/pkg is what *everything* refers to. Yes, /var/db/pkg/ is where all the information about installed ports/packages is stored. To recreate that information you will have to reinstall everything. I'm feeling like the least competent user in the world right now. Though it *does* teach me a valuable lesson about backing up. Backups are good, yes. Regular, up-to-date, backups are even better. Alas, though, regular, up-to-date backups ain't happened here. What has happened, though, is I've never ran rm in /usr/ports/distfiles. I'm going to think for a little bit about a script that can move through /usr/ports/distfiles and reinstall everything that exists there. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
James writes: What has happened, though, is I've never ran rm in /usr/ports/distfiles. I'm going to think for a little bit about a script that can move through /usr/ports/distfiles and reinstall everything that exists there. Having been in almost the identical situation for different rasons, I sympathize. Yes, this will involve a sweep through /usr/ports distfiles. If you haven't ever deleted anything, I suggest a prelimiary manual run deleting everything but the most recent version. This has a down-side, but it will prevent cluttering the rebuilt system with unused ports. The other thing you want do is start with something /big/ - OpenOffice, FireFox, GIMP, Java, Apache. While rebuilding it will take time (possibly days) it will automatically suck in the dependencies. Send the output of the rebuild to a file; have a cron job e-mail you the last 50 lines every hour. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thursday 11 October 2007 23:29:05 James wrote: What has happened, though, is I've never ran rm in /usr/ports/distfiles. I'm going to think for a little bit about a script that can move through /usr/ports/distfiles and reinstall everything that exists there. Well, if you figure out what ports you have installed, you can regenerate the pkgdb using: make -DNO_BUILD -DNO_INSTALL generate-plist fake-pkg for each port. I just tested that using a temporary PKG_DBDIR. In case you wanna see what happens, here's what I did: mkdir -p /tmp/var/db/pkg cd /usr/ports/shells/bash env PKG_DBDIR=/tmp/var/db/pkg make -DNO_BUILD -DNO_INSTALL \ generate-plist fake-pkg # ls /tmp/var/db/pkg/bash-3.2.25/ +COMMENT+DEINSTALL +INSTALL +CONTENTS +DESC +MTREE_DIRS It's missing +REQUIRED_BY and @pkgdep lines in +CONTENTS, but haven't been able to figure out yet why that is. I hope this gets you a bit closer. -- Mel ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I performed an rm -r on /var/lib/pkg
On Thu, 2007-10-11 at 18:14 -0400, Robert Huff wrote: James writes: What has happened, though, is I've never ran rm in /usr/ports/distfiles. I'm going to think for a little bit about a script that can move through /usr/ports/distfiles and reinstall everything that exists there. Having been in almost the identical situation for different rasons, I sympathize. Yes, this will involve a sweep through /usr/ports distfiles. If you haven't ever deleted anything, I suggest a prelimiary manual run deleting everything but the most recent version. This has a down-side, but it will prevent cluttering the rebuilt system with unused ports. /usr/ports/distfiles is definitely looking promising. awk is too damn painful to work with, so I'm going to dust off my perl skills. Hell, this could actually turn out to be fun. And if I write the script properly, it might make a nice disaster recovery tool for /usr/ports/ports-mgmt - it can be called WhenYou'reAnIdiotLikeJamesWasOnFreeBSDQuestions Well, if you figure out what ports you have installed, you can regenerate the pkgdb using: make -DNO_BUILD -DNO_INSTALL generate-plist fake-pkg for each port. I just tested that using a temporary PKG_DBDIR. In case you wanna see what happens, here's what I did: mkdir -p /tmp/var/db/pkg cd /usr/ports/shells/bash env PKG_DBDIR=/tmp/var/db/pkg make -DNO_BUILD -DNO_INSTALL \ generate-plist fake-pkg Wow, that's great! I understand that it has the caveats that you mentioned, but it's *at least* a fantastic start. James ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
