Professional Web Applications Themes

Redhat upgrade problem - packages fail rpm -Va - Linux Setup, Configuration & Administration

I am having problems upgrading from Redhat 8.0 to Redhat 9. The upgrade process seems to finish without error, but when I do an 'rpm -Va' to verify all 700 packages in the installation, I get 314 files with errors. If I force the upgrade of these packages with the command 'rpm -Uvh --replacepkgs <package name>' I can get rid of the errors for that one package, but I have 35 more packages to go. I can set up a script to automate the upgrading of the remaining packages, but my worry is that I may be messing up some ...

  1. #1

    Default Redhat upgrade problem - packages fail rpm -Va

    I am having problems upgrading from Redhat 8.0 to Redhat 9. The upgrade process seems to finish without error, but when I do an 'rpm -Va' to verify all 700 packages in the installation, I get 314 files with errors. If I force the upgrade of these packages with the command 'rpm -Uvh --replacepkgs <package name>' I can get rid of the errors for that one package, but I have 35 more packages to go.
    I can set up a script to automate the upgrading of the remaining packages, but my worry is that I may be messing up some important files. Some of the problems are just timestamp differences, others are in packages I don't use, but there are some that look like errors in core system files, like /dev/shm.
    The system is running now, and I love the new screen savers, but I'm very uncomfortable leaving so many files "out-of-sync" with the distribution. I would like to be able to verify my installation with 'rpm -Va' whenever I have a worry.

    Has anyone had similar problems with Redhat upgrades? Is it common to have so many files show up as errors with the 'rpm -Va' command?

    Notes on the history of this system:
    1) I have installed "bleeding edge" updates of a Python distribution on two occasions. Generally, the Python folks are carefull not to disturb existing installations, but this could explain a few of the errors.
    2) I had an incorrect Install CD #1 in the box from Red Hat on 10/01/03. This CD may have installed a bunch of these files before I found the cause of the problem and continued the upgrade from known good images on my hard drive.

    -- Dave

    Dave Guest

  2. #2

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    Dave wrote:
     

    So does everyone. Have you considered reading the Google threads on this
    topic?

    1. Back up your data.

    2. ERASE the HDD.

    3. Install RH 9 (actually, 2 and 3 can be done at once in the RH 9 install).

    4. Restore your data.

    --
    Paul Lutus
    http://www.arachnoid.com

    Paul Guest

  3. #3

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    Dave wrote:
     

    ..... do a fresh install, saving off /home
    ..
    --
    /// Michael J. Tobler: motorcyclist, surfer, skydiver, \\\
    \\\ and author: "Inside Linux", "C++ HowTo", "C++ Unleashed" ///
    Statisticians probably do it.

    mjt Guest

  4. #4

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    "Paul Lutus" <zzz> wrote in message
    news:supernews.com... 
    >
    > So does everyone. Have you considered reading the Google threads on this
    > topic?[/ref]

    Yes, I've been reading a lot in the newsgroups this week, trying to figure
    out if other Linux distributions are just as bad. I've been hearing good
    things about Debian, but I see some complaints there too about install /
    upgrade problems.
     
    install). 

    I was trying to avoid all the effort I made when I first installed Linux,
    configuring the network, file sharing system, printer, etc. If I have to go
    through this again, it won't be with Red Hat.

    I can't believe that Red Hat has n it so badly on this upgrade process.
    rpm is a good package manager. It has all the capability I need. The
    problem seems to be that Red Hat has dropped the ball on the few remaining
    steps to make it all work smoothly.
    1) Sub-version numbers need to be put on the disks. They can't just call
    everything release "9".
    2) The install program ( I assume its a front-end to rpm.) needs to check
    the subversion number, display it prominently during the install, and
    provide a better warning if the disks don't all have the same subversion
    number. It would help also if the md5sums were displayed, and could be
    compared to published numbers on their website.
    3) The install program needs the same options as 'rpm' to allow forcing an
    upgrade, verification, etc.
    4) The whole process needs to be more transparent. What is happening with
    config files during the upgrade, etc.
    5) rpm needs a better output format. I have a script which I can post on
    my website if anyone is interested.
    6) We need better support during the 30-day install period. The techs at
    that level are not even aware that there are multiple versions all labelled
    "9".

    -- Dave


    Dave Guest

  5. #5

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    Dave wrote:
     
    >>
    >> So does everyone. Have you considered reading the Google threads on this
    >> topic?[/ref]
    >
    > Yes, I've been reading a lot in the newsgroups this week, trying to figure
    > out if other Linux distributions are just as bad.[/ref]

    RH 9 isn't bad. It just represents too great a change to support reliable
    upgrades from RH 8. I think the people at RH underestimated how much
    non-portahble binary code most people end up with after about a year of
    using RH 8, none of which works with RH 9. This is because the RH 8 -> RH 9
    change was a sweeping one, involving replacement of the compiler, all
    libraries and binaries at once, with no interoperability.

    The entire premise of the upgrade was that most of the system code would be
    replaced by the upgrade binaries, and the user would figure out that the
    remainder would need recomplilation from source or a compatible binary
    upgrade. But this just isn't happening.

    As to your issue about the difficulty of upgrading, the way I handle that is
    to take copious notes. Also I have written a lot of scripts to automate
    most of the upgrade reconfiguration between versions.

    The positive side is that I get to erase my HDD and start fresh. This really
    solves a lot of problems.

    BTW, if you want people to recognize you in new threads (which I didn't
    until I saw your longer, more descritive second post) is to use two names,
    not one.

    --
    Paul Lutus
    http://www.arachnoid.com

    Paul Guest

  6. #6

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    "Robert M. Riches Jr" <net> wrote in message
    news:localnet...
    [...] 

    These are generally marked with a 'c' in the output of 'rpm -Va'.
    Configuration files like this are allowed to change, and maintaining these
    changes through the upgrade process is what a good upgrade command should
    do.
     

    This should not be the case with a "standard" set of packages. The
    distributor should decide which is the correct final state of the shared
    file and make that the specified state for verification. If it were an
    *added* package, then I could see a challenge. The ideal installer should
    warn that a shared file is about to be replaced, show which packages claim
    "ownership" of the file, and offer an option to leave the file as is.
     

    I'm seeing that also. The 'dev' package alone accounts for 215 of my
    current 312 errors. /dev/shm has an error code M. Most of the others are
    showing U and G errors.

    I'm seeing some other discrepancies also - files that are modified *after*
    the install, but are not config files.
    The package 'up2date' is a good example.


    [rootsaguaro redhat]# rpm -Uvh --replacepkgs up2date-3.1.23.2-1.i386.rpm

    Preparing... ###########################################
    [100%]

    1:up2date ###########################################
    [100%]

    [rootsaguaro redhat]# rpm -V up2date

    SM5....T c /etc/sysconfig/rhn/up2date

    S.5....T c /etc/sysconfig/rhn/up2date-uuid

    {Only config files in verify error list. Good so far.}

    [rootsaguaro redhat]# cd /usr/share/rhn/up2date_client

    [rootsaguaro up2date_client]# ll | grep up2dateUtils

    -rwxr-xr-x 1 root root 4980 Aug 28 19:36 up2dateUtils.py

    -rwxr-xr-x 1 root root 7484 Aug 28 19:35 up2dateUtils.pyc

    .... {Notice the dates of these freshly installed files.}

    [rootsaguaro redhat]# up2date

    {Your system is fully updated. No new packages are needed.}

    [rootsaguaro redhat]# rpm -V up2date

    SM5....T c /etc/sysconfig/rhn/up2date

    S.5....T c /etc/sysconfig/rhn/up2date-uuid

    SM5....T /usr/share/rhn/up2date_client/up2dateUtils.pyc

    {Notice the extra error - not a config file.}

    [rootsaguaro redhat]# cd /usr/share/rhn/up2date_client

    [rootsaguaro up2date_client]# ll | grep up2dateUtils

    -rwxr-xr-x 1 root root 4980 Aug 28 19:36 up2dateUtils.py

    -rw-r--r-- 1 root root 8053 Oct 11 11:04 up2dateUtils.pyc

    {Notice the changed date.}

    There are a lot these '.pyc' python object files in the distribution. I
    don't know why it should ever be necessary to change a program file that is
    not a config file, but assuming there is some good reason for this, we may
    need some improvements in rpm to maintain the integrity of the verify
    process. The fix I'm thinking of would require adding a new category of
    file to the "config" files that rpm already recognizes. We could call these
    "generated" files, and flag them with a "g" so they could be excluded from
    our error lists. These files are expected to change frequently and
    automatically, but unlike config files, they are generated automatically
    without any user input. We can think of them as temporary files.
     

    This is my plan ( if I stay with Redhat.)

    I'm really looking for a system that I can "lock down" the critical files,
    and not worry too much about adding things over time, and not have to ever
    repeat a configuration once I have painfully worked out the details. I have
    tried to keep notes on these configurations, and it never works. No matter
    how careful I am, I can't follow my notes the next time around. If I were a
    system administrator, I would learn this stuff. As a user, I expect
    upgrades to go a lot more smoothly.

    In spite of the possible limitation of not recognizing "generated" files,
    discussed above, I still think the problems I've encountered these last few
    days are not inherent in rpm. rpm seems like a robust and well-designed
    package managment system. I think the fault lies with the package builders
    and the distributor. They have failed to get things organized properly so
    non-expert users can do an upgrade. The machinery is all there. They just
    need to focus more effort on the individual user, and not expect everyone to
    be part of some "enterprise" account where the experts take care of all
    setups.

    We can lean something from Microsoft's install process. Not that we should
    duplicate all the bizarre "registry" crap, but we should expect to get the
    same level of "installability" in Linux packages. When I install or
    uninstall a package in Windows, it almost always goes smoothly. The upgrade
    from W2K to XP was a breeze.

    -- Dave


    Dave Guest

  7. #7

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    "Dave" <0.0.1> writes:

    ]This is a multi-part message in MIME format.

    ]------=_NextPart_000_03E2_01C38F35.A93CAB30
    ]Content-Type: text/plain;
    ] cht="iso-8859-1"
    ]Content-Transfer-Encoding: quoted-printable

    ]I am having problems upgrading from Redhat 8.0 to Redhat 9. The upgrade =
    ]process seems to finish without error, but when I do an 'rpm -Va' to =
    ]verify all 700 packages in the installation, I get 314 files with =
    ]errors. If I force the upgrade of these packages with the command 'rpm =
    ]-Uvh --replacepkgs <package name>' I can get rid of the errors for =
    ]that one package, but I have 35 more packages to go.
    ]I can set up a script to automate the upgrading of the remaining =
    ]packages, but my worry is that I may be messing up some important files. =
    ] Some of the problems are just timestamp differences, others are in =
    ]packages I don't use, but there are some that look like errors in core =
    ]system files, like /dev/shm.
    ]The system is running now, and I love the new screen savers, but I'm =
    ]very uncomfortable leaving so many files "out-of-sync" with the =
    ]distribution. I would like to be able to verify my installation with =
    ]'rpm -Va' whenever I have a worry.

    ]Has anyone had similar problems with Redhat upgrades? Is it common to =
    ]have so many files show up as errors with the 'rpm -Va' command?

    ]Notes on the history of this system:
    ]1) I have installed "bleeding edge" updates of a Python distribution on =
    ]two occasions. Generally, the Python folks are carefull not to disturb =
    ]existing installations, but this could explain a few of the errors.
    ]2) I had an incorrect Install CD #1 in the box from Red Hat on 10/01/03. =
    ] This CD may have installed a bunch of these files before I found the =
    ]cause of the problem and continued the upgrade from known good images on =
    ]my hard drive.

    ]<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <Rest elimiated>
    Please DO NOT post to usenet with html. html is unreadable by many
    newsreaders, and just clogs up the net.
    remember rpm -Va checks EVERY byte of every file. Thus if you add a user
    (like root) to /etc/passwd, then the package of which that is the file
    will fail.

    NOte also that in upgrding across major divisions, the packages
    themselves change. Thus you may get the situation where say /etc/passwd
    is part of setup package on one verions and security on the other.
    Then when rpm upgrades say setup on the new one, it will not remove
    security, and thus the name passwd will show up in both packages and
    will fail inone.
    Generally, upgrade within major package numbers, and reinstall across
    major numbers ( eg 8.1 to 9.0)

    Bill Guest

  8. #8

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    "Bill Unruh" <physics.ubc.ca> wrote in message
    news:bmhoqk$7r4$physics.ubc.ca...
    [..] 

    I was not aware that this was happening. I had selected "Plain Text" and
    not "Rich Text (HTML)" on the Format menu in Outlook Newsreader. Now I see
    that there is another place where this same option is set to HTML ( Tools ->
    Options -> Send -> News Sending Format -> HTML ). I just changed that to
    Plain Text also. Unless there is yet another place to set this option, I
    should be OK now. Let me know if you see any more HTML in my posts.

    -- Dave


    Dave Guest

  9. #9

    Default Re: Redhat upgrade problem - packages fail rpm -Va

    On Tue, 14 Oct 2003 14:23:31 -0700, Dave wrote:
     
    ^^^^^^^^^^^^^^

    Except that Outlook Express is *still* a FPOS. :) If you need/want to
    use Windows sometimes, I recommend Eudora for e-mail and Free Agent for
    Usenet. Or, if you're willing to pay for it, Agent covers both.

    Ed Guest

  10. #10

    Default Re: [OT] Redhat upgrade problem - packages fail rpm -Va

    "Ed Murphy" <rr.com> wrote in message
    news:rr.com... [/ref]
    and [/ref]
    see [/ref]
    Tools -> [/ref]
    to 
    > ^^^^^^^^^^^^^^
    >
    > Except that Outlook Express is *still* a FPOS. :) If you need/want to
    > use Windows sometimes, I recommend Eudora for e-mail and Free Agent for
    > Usenet. Or, if you're willing to pay for it, Agent covers both.[/ref]

    I've been a long-time user of Eudora, and I agree it is the best. We were
    forced to switch to Outlook by our corporate IT department -- some nonsense
    about better security and lower support costs. This happened in spite of
    the fact that our principle business is developing software for Unix / Linux
    systems. Talk about a gap between the suits and the techies. Dilbert
    should write a story on this one.

    After a year of viruses, spam, and increased support costs, many of us
    quietly abandoned Outlook, in defiance of our corporate policy. I guess the
    IT guys are too embarrassed to say anything. To this day, we don't know who
    it was that made the decision to switch to Outlook. They blame it on our
    CEO, but I think his order was simply "cut costs". Most of the cost is in
    user time - for me, about a three-day hit over the first six months in
    moving from Eudora to Outlook. This does not appear on anyone's bottom
    line, so I suspect that IT was able to still show some cost savings, or at
    least hide the true costs.

    As for the newsreader, I'll take a look at Agent. Thanks for the
    recommendation. I am really short of time, however (and somewhat lazy) so
    I'll probably stick with Outlook for a while. Other than this "HTML when I
    selected Plain Text" it hasn't been a problem so far.

    -- Dave


    Dave Guest

Similar Threads

  1. apt-get upgrade Packages Held Back
    By Ian O'Brien in forum Ubuntu
    Replies: 1
    Last Post: March 20th, 08:31 AM
  2. Redhat 9 Upgrade Problem
    By David Thomas in forum Linux Setup, Configuration & Administration
    Replies: 0
    Last Post: August 25th, 01:21 AM
  3. redhat 8: upgrade php from 4.2.2 to 4.3.2
    By Chris W. Parker in forum PHP Development
    Replies: 1
    Last Post: August 15th, 06:00 PM
  4. Replies: 0
    Last Post: August 2nd, 01:20 PM
  5. RedHat support of Debian packages
    By Derrick 'dman' Hudson in forum Debian
    Replies: 4
    Last Post: July 8th, 10:50 PM

Bookmarks

Posting Permissions

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139