Results 1 to 5 of 5

Thread: How to safely verify rpm database

  1. #1
    Join Date
    Jan 2013
    Location
    Shrewsbury MA USA
    Posts
    6

    Question How to safely verify rpm database

    We have a package installation application where we need to verify the integrity of the RPM database first so that we don't crash or bail out in the middle of installing a bunch of RPMs. I'm having trouble finding a way to safely (i.e. without crashing or modifying the database making it worse) and reliably do this. A page on the rpm.org wiki says to use rpmdb_verify, but this does not exist on our OpenSuSE 12.1 distribution. Doing some tests, rpm -qa --dump seems oblivious to some corruptions, but on the other hand, so do -i and -e (I haven't found a corruption yet that --dump misses that -i or -e catch, but I'd like to do a more thorough verify anyway -- I am afraid that a cursory read-only operation like --dump will miss a read/write error). Am I stuck with rpm -qa --dump or is there a tool I haven't discovered yet that will do this? What happened to rpmdb_verify and rpmdb_stat?

    Thanks,
    Eric

  2. #2

    Default Re: How to safely verify rpm database

    You're wanting to verify the DB's integrity? I assume this is because of
    something special your software does, since you should not be trying to do
    with with any old random application installation. If you want to do this
    type of thing without modify the DB you could always copy it somewhere
    else (a temporary directory) and then do whatever from that location,
    though again this is all a bit abnormal for a regular package
    installation. Is your package focused on data integrity or recovery? IF
    so, installing via RPM seems like a bad idea. You could always create
    your own RPM DB somewhere (one command) and then install into that so that
    your software is installed but the main RPM database is not touched.

    Without a business case for all of this it's hard to come up with good
    suggestions (above is probably not good... in fact, it may even be bad,
    though functional based on wild speculation about your business case).
    Provide more details for better answers, please.

    Good luck.

  3. #3
    Join Date
    Jan 2013
    Location
    Shrewsbury MA USA
    Posts
    6

    Post Re: How to safely verify rpm database

    I'm wanting to verify the DB's integrity so that we fail gracefully at the beginning of an install instead of catastrophically in the middle with cryptic and frightening error messages if the RPM database is corrupt. We've already seen this in the field. The package is just installing normal system RPMs, they don't pertain to data integrity or recovery per se. The business case is that the user gets a nice informative error message before the installation starts, rather than getting part way through what should be an atomic install and it dies with a scary message, leaving the system in a potentially inconsistent state. Dying in the middle of an install is about the worst thing that can happen.

    I guess the bottom line is we want an atomic installation -- it should either work, or not work, and not get halfway through and die for preventable reasons.

    Does that make things a bit clearer?
    Last edited by eewanco; 22-Jul-2013 at 12:24. Reason: Edited for clarity.

  4. #4
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    20,007
    Blog Entries
    1

    Default Re: How to safely verify rpm database

    Quote Originally Posted by eewanco View Post
    I'm wanting to verify the DB's integrity so that we fail gracefully at the beginning of an install instead of catastrophically in the middle with cryptic and frightening error messages if the RPM database is corrupt. We've already seen this in the field. The package is just installing normal system RPMs, they don't pertain to data integrity or recovery per se. The business case is that the user gets a nice informative error message before the installation starts, rather than getting part way through what should be an atomic install and it dies with a scary message, leaving the system in a potentially inconsistent state. Dying in the middle of an install is about the worst thing that can happen.

    I guess the bottom line is we want an atomic installation -- it should either work, or not work, and not get halfway through and die for preventable reasons.

    Does that make things a bit clearer?
    The 'db_verify' command may be useful for this. It's a good idea to make a copy of the database first, then check the integrity of that copy, (just in case some other concurrent process writes to the DB while checking as db_verify does not perform any locking AFAIU).

    Repair an RPM database safely

  5. #5
    Join Date
    Mar 2010
    Location
    Austin - Texas
    Posts
    10,140
    Blog Entries
    48

    Smile Re: How to safely verify rpm database

    Quote Originally Posted by eewanco View Post
    We have a package installation application where we need to verify the integrity of the RPM database first so that we don't crash or bail out in the middle of installing a bunch of RPMs. I'm having trouble finding a way to safely (i.e. without crashing or modifying the database making it worse) and reliably do this. A page on the rpm.org wiki says to use rpmdb_verify, but this does not exist on our OpenSuSE 12.1 distribution. Doing some tests, rpm -qa --dump seems oblivious to some corruptions, but on the other hand, so do -i and -e (I haven't found a corruption yet that --dump misses that -i or -e catch, but I'd like to do a more thorough verify anyway -- I am afraid that a cursory read-only operation like --dump will miss a read/write error). Am I stuck with rpm -qa --dump or is there a tool I haven't discovered yet that will do this? What happened to rpmdb_verify and rpmdb_stat?

    Thanks,
    Eric
    For help with Zypper and including rpm database repair, have a look at my bash script here: Zypper Command - Zypper Package Management Menu System - Version 2.00 - Blogs - openSUSE Forums

    Thank You,
    My Blog: https://forums.opensuse.org/blogs/jdmcdaniel3/

    Software efficiency halves every 18 months, thus compensating for Moore's Law

    Its James again from Austin, Texas

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •