Re: up2date openssh hangs - Re: duplicate packages after up2date failure

From: Jim Cornette (fc-cornette_at_insight.rr.com)
Date: 10/13/05

  • Next message: harry: "Regained menu bar, thanks Tim."
    Date: Wed, 12 Oct 2005 18:17:19 -0400
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    
    

    Alexander Lazarevich wrote:

    > This problem was previously discussed in post:
    >
    > "duplicate packages after up2date failure" by Damian Menscher on Sun,
    > 9 Oct 2005 16:53:17 -0500 (CDT).
    >
    > We have the same problem on a FC4x86_64 machine. I've notice that
    > up2date of openssh causes a similar (unkillable) useradd process to
    > hang the machine. After a hard reboot, the up2date openssh seems to
    > have succeeded, but the old openssh is still around:
    >
    > openssh.x86_64 4.2p1-fc4.1
    > installed openssh.x86_64 4.0p1-3
    > installed
    >
    > Messy, but ssh seems works.
    >
    > What I'd like to know is, for any future up2date's, is redhat going
    > to fix this FC4U2/up2date/useradd/64bit kernel problem. Or should we
    > just roll back to FC3x86_64, which doesn't have this problem (not
    > that I've heard of, we have a 64bitFC3 system that up2dates just
    > fine).
    >
    > I agree with Damian in that up2date should install and clean each
    > package individually before moving onto the next.
    >
    > Alex
    >

    I believe that rpm operates in the same method when updating groups of
    rpms. Yum and up2date seem to clear the database entries when the
    updating tasks complete. Any sudden interruption in any of the programs
    seems to result in multiple entries for programs replaced during a
    group rpm upgrade.

    Probably filing an RFE regarding updating the db per successfully
    completed operation might get some answers. I think the db being updated
    upon completion is due to resolved dep entries not being complete until
    all packages are installed. Also writing to the db so many times when
    the end result is the same probably saves on disk cycles and lowers the
    possibility the database will become corrupted.

    Of course power loss without a battery backup, programs that peg the
    processor which need a hard kill and shutting down the computer before
    the update process is completed make individually cleaning per package
    install desirable.

    Jim

    -- 
    QOTD:
        If it's too loud, you're too old.
    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
    

  • Next message: harry: "Regained menu bar, thanks Tim."

    Relevant Pages

    • Re: Software Install Best Practice?
      ... I presume up2date still maintains the dependency relationships if I ... install from a third-party repository like that. ... installing Fedora packages on RHEL is a hit-or-miss proposition. ... Yet I can't easily uninstall gtk, because it's got a zillion packages ...
      (RedHat)
    • Re: Fedora up2date and yum
      ... I tried SuSE 9 just to see if it would work as a viable alternative. ... > myself having to install nearly half my common apps from source, ... > regardless of what I tried, so I decided to just have a look at Fedora. ... > When I ran up2date and it hung for a really long time. ...
      (linux.redhat)
    • up2date broken
      ... I've installed numerous RH servers for community groups and I depend on ... up2date to keep them up2date. ... I'm not sure what the story is but it sure shakes my faith in RedHat when I ... the CDs back through the machine as an "Upgrade" install hoping that would ...
      (RedHat)
    • Re: Tarball installation
      ... I issued an up2date command. ... This seemed to install gcc. ... "The following packages were not found. ...
      (linux.redhat.install)