Doing something really silly, which erased /var/lib/rpm/. Sigh.
Found http://www.sharp-tools.net/archives/000765.html which talks about recovering from an erasure by using a log file /var/lib/rpmpkgs that a cron job did on his system. Can't find any such file on my system.
Any suggestions really appreciated.
Sean
On 09/25/2011 08:18 PM, Clive Hills wrote:
Reinstall!
ridiculous.
or restore from backups , you *do* have backups ?
that is a last resort.
you need to run;
man rpm or info rpm
also.
'man --initdb' is a much easier way, and would be more accurate than backups.
most _users_ who make backups do not have them current. some of us do. B-D
btw, if you reply to this post, please do so in 'text/plain', which gmail can do also.
which is better for getting response because a lot of folks filter out html text. some to a separate folder, some to trash.
On 09/25/2011 08:15 PM, sean darcy wrote:
Doing something really silly, which erased /var/lib/rpm/. Sigh.
Found http://www.sharp-tools.net/archives/000765.html which talks about recovering from an erasure by using a log file /var/lib/rpmpkgs that a cron job did on his system. Can't find any such file on my system.
Any suggestions really appreciated.
1] use either;
man rpm or info rpm
search for word;
--initdb
2] learn how to back up your system.
hth.
On 09/25/2011 11:28 PM, g wrote:
On 09/25/2011 08:15 PM, sean darcy wrote:
Doing something really silly, which erased /var/lib/rpm/. Sigh.
Found http://www.sharp-tools.net/archives/000765.html which talks about recovering from an erasure by using a log file /var/lib/rpmpkgs that a cron job did on his system. Can't find any such file on my system.
Any suggestions really appreciated.
1] use either;
man rpm or info rpm
search for word;
--initdb
This is of no use whatsoever in this situation, it doesn't help reconstructing the accidentally erased rpmdb contents.
2] learn how to back up your system.
While good advise, this doesn't help after the fact either.
The best option is to see if the db can be undeleted as-is: avoid writing on the filesystem where /var/lib/rpm/ was and give extundelete (or other similar tool) a go: see http://extundelete.sourceforge.net/ for general undelete instructions.
Extundelete is packaged in Fedora but you can't use rpm/yum to install it, you'll need to download it to some other partition than /var and unpack with rpm2cpio (and hope you had its dependencies installed) and use it from that temporary location.
The all-important file is /var/lib/rpm/Packages, everything else is just indexes that can be recreated from the Packages file. IF you can find that with undelete-tricks then there should be zero loss of data: put the undeleted Packages file back to /var/lib/rpm/, run 'rpmdb --rebuilddb' and that's it.
If undelete is not possible (eg /var has been written to which may have caused the deleted contents to be actually destroyed), things harder and more error prone. Your best chance might be /var/lib/yum/rpmdb-indexes/pkgtups-checksums, the script below will pull out a package list similar to what /var/log/rpmpkgs used to be:
-- cut here -- #!/usr/bin/python f = open('/var/lib/yum/rpmdb-indexes/pkgtups-checksums') for x in [1, 2]: f.readline() lines = [] for l in f.readlines(): lines.append(l.strip()) pd = zip(*[lines[i::7] for i in range(7)]) for (n,a,e,v,r,x,y) in pd: print '%s-%s-%s.%s' % (n,v,r,a) -- cut here --
With that data, you can then try to reconstruct the rpmdb contents similarly to described in eg http://www.sharp-tools.net/archives/000765.html. Whether this is worth the trouble depends - reinstall might well be an easier option in practise.
- Panu -
On Mon, Sep 26, 2011 at 03:01:16PM +0300, Panu Matilainen wrote:
This is of no use whatsoever in this situation, it doesn't help reconstructing the accidentally erased rpmdb contents. <<suggestions elided>>
Hmm...single point of failure...Bad Thing(TM).
If this can cause a system to become unusable to the point of requiring reinstallation, perhaps its design should be rethought; maybe a shadow copy, or something similar. (A consideration that perhaps should be given to any single point-of-failure data element.)
Cheers, -- Dave Ihnat dihnat@dminet.com
Am 26.09.2011 15:19, schrieb Dave Ihnat:
On Mon, Sep 26, 2011 at 03:01:16PM +0300, Panu Matilainen wrote:
This is of no use whatsoever in this situation, it doesn't help reconstructing the accidentally erased rpmdb contents. <<suggestions elided>>
Hmm...single point of failure...Bad Thing(TM).
If this can cause a system to become unusable to the point of requiring reinstallation, perhaps its design should be rethought; maybe a shadow copy, or something similar. (A consideration that perhaps should be given to any single point-of-failure data element.)
you can not prepare all against a single point of failure what would be your solution for "rm -rf /etc/"?
the prevention for user-mistakes is known as backup and everything where no backups are existing can not be important
On 09/26/2011 08:49 AM, Dave Ihnat wrote:
On Mon, Sep 26, 2011 at 03:01:16PM +0300, Panu Matilainen wrote:
This is of no use whatsoever in this situation, it doesn't help reconstructing the accidentally erased rpmdb contents. <<suggestions elided>>
Hmm...single point of failure...Bad Thing(TM).
It is not a single point of failure, your system works even with the rpm database erased, you lose the ability to use rpm appropriately, that is all. What do you propose?, to have a master slave database with another server to store the RPM DB? two directories, that does not solves the "ohh my god, I deleted /var, parent of both rpm databases"
If this can cause a system to become unusable to the point of requiring reinstallation, perhaps its design should be rethought; maybe a shadow copy, or something similar. (A consideration that perhaps should be given to any single point-of-failure data element.)
Cheers,
Dave Ihnat dihnat@dminet.com
On Mon, Sep 26, 2011 at 09:08:35AM -0430, Robert Marcano wrote:
It is not a single point of failure, your system works even with the rpm database erased, you lose the ability to use rpm appropriately, that is all.
That's a failure, at least in a production environment; if you can't apply updates in a timely and 'appropriate' manner, you can't trust that system.
Fedora isn't (or shouldn't be) a production system, but RPM is used in production systems.
What do you propose?, to have a master slave database with another server to store the RPM DB? two directories, that does not solves the "ohh my god, I deleted /var, parent of both rpm databases"
I don't know what to propose; that's why I tossed this out. It's not only loss of the RPM database that would scrag a system--/etc/passwd & /etc/group (the shadow copies wouldn't be enough), numerous other files & directories would all drive a system to its knees.
Reinstallation is not really what anyone would call a production recovery. For one thing, it brings a system "back" in a virgin state, with any generated critical data lost.
Full backup recovery has also been, over the decades--and I've been there--less than an optimal solution. How often have I found that client backups hadn't been running, or were corrupted? Even if they're good, it's a long and painful downtime.
Maybe a utility to which critical files/directories are identified that can take "appropriate action". Maybe appropriate action is a shadow archive on a different drive, or NAS/SAN, or another computer, or even backup media.
Or maybe people shrug and say, "What we've been doing is good enough." But it should be a conscious decision, not a de facto one.
Cheers, -- Dave Ihnat dihnat@dminet.com
On Mon, 2011-09-26 at 08:52 -0500, Dave Ihnat wrote:
Reinstallation is not really what anyone would call a production recovery. For one thing, it brings a system "back" in a virgin state, with any generated critical data lost.
Now if you backup correctly. You may somehow lose small amounts of data, depending on what you backup and what didn't work when backing up or whatever, but if you did it correctly and tested every so often to make sure it works, then it's not as bad as you make it out.
Full backup recovery has also been, over the decades--and I've been there--less than an optimal solution. How often have I found that client backups hadn't been running, or were corrupted? Even if they're good, it's a long and painful downtime.
That is true, lots of downtime but it does happen. Just helps to have a plan just in case.
I do wonder why you couldn't back up the rpm database or soemthing and at least restore it to an older version, or an initial version from an install or something. Least you have *something* to fall back on and then just update it.
On 09/26/2011 04:19 PM, Dave Ihnat wrote:
On Mon, Sep 26, 2011 at 03:01:16PM +0300, Panu Matilainen wrote:
This is of no use whatsoever in this situation, it doesn't help reconstructing the accidentally erased rpmdb contents. <<suggestions elided>>
Hmm...single point of failure...Bad Thing(TM).
If this can cause a system to become unusable to the point of requiring reinstallation, perhaps its design should be rethought; maybe a shadow copy, or something similar. (A consideration that perhaps should be given to any single point-of-failure data element.)
That's what backups are for. An accidental 'rm -rf /' is also a single point of failure from that perspective.
- Panu -
On Mon, 26 Sep 2011 08:19:28 -0500 Dave Ihnat dihnat@dminet.com wrote:
On Mon, Sep 26, 2011 at 03:01:16PM +0300, Panu Matilainen wrote:
This is of no use whatsoever in this situation, it doesn't help reconstructing the accidentally erased rpmdb contents. <<suggestions elided>>
Hmm...single point of failure...Bad Thing(TM).
You cannot make a system completely idiot proof. It's already a transactional database to protect against corruption but if someone deletes it or mistakenly reformats their hard disk there are limits to what can be done to bulletproof it.
If you have a backup restore it, if not I guess it wasn't a single point of failure ... you had at least two failures. Time to back up the user data, re-install and restore the user data on top.
You can do clever stuff with rpm --dbonly but it's probably less work long term to do the backup/reinstall cycle.
Alan
sean darcy ha scritto / said the following il giorno/on 25/09/2011 22:15:
Doing something really silly, which erased /var/lib/rpm/. Sigh.
Found http://www.sharp-tools.net/archives/000765.html which talks about recovering from an erasure by using a log file /var/lib/rpmpkgs that a cron job did on his system. Can't find any such file on my system.
Any suggestions really appreciated.
Sean
http://rikers.org/rpmbook/node42.html
-
Alan Cox -
antonio montagnani -
Clive Hills -
Dave Ihnat -
g -
Mike Chambers -
Panu Matilainen -
Reindl Harald -
Robert Marcano -
sean darcy