RE: yum roll back option?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: fedora-devel-list-bounces@xxxxxxxxxx [mailto:fedora-devel-list-
> bounces@xxxxxxxxxx] On Behalf Of Jeff Spaleta
> Sent: Saturday, January 13, 2007 12:07 AM
> To: Development discussions related to Fedora Core
> Subject: Re: yum roll back option?
> 
> On 1/12/07, Jerry Williams <jwilliam@xxxxxxxxxxxx> wrote:
> > I was wondering about a way to recover back to a previous working
> system.
> > The yum updates that I installed today broke my 3c590 network card.
> > I can look at /var/log/yum.log and see what was installed, but I am not
> sure
> > what versions I had before that.
> > I ended up swapping the network card with a 3c905 card and it works
> okay.
> > The only thing I can think to do is do a rpm -qa >rpm.txt before I run
> yum
> > and then one after so I can do a diff on the files and know what the
> > previous version was.
> 
> Have you been grepping through your archive or rpmpkgs logs?  The yum
> log is not necessarily sufficient for all admin actions. I can't speak
> for you but in my own experience I can't always do everything I need
> to do via yum and I have to resort to using rpm directly on occasion
> to include things like non-distributable content.
> 
> /etc/cron.daily/rpm  is already present and it should be running on
> your servers and provides a nightly log of the installed package set.
> If you look at the previous day's rpmpkg log wouldn't that give you
> the information you need?
> 
> -jef

Thanks Jeff,
I really didn't post here to try and fix my problem, more to look at the
whole picture.  If you break your server and lots of people depend on it
then that is a bad thing.  And it is hard to have an identical machine
sitting there to test on.  I would like to see Fedora 7 more robust so that
it would be easy to recover from a problem like this.  Does rpm need to be
fixed to keep a previous version or something else?  What if rpm had a cache
that it would keep the previous version and the current version?  And maybe
an option to purge the previous version.

That is looking like I should be keeping a copy of all the rpms on my system
so I don't have to try and get them on the system after a problem.

I got lucky and was going to replace the network card anyway, but it was the
external nic on my firewall so now I have to play games to be able to get to
the internet to get the previous versions of the rpms if I didn't have
another card that would work.  I guess another option would be to not do 34
updates at a time.  Maybe pick some that you thing are safe and then update
them and reboot.  And then do some more.  I didn't have to reboot when I did
the update, but I wouldn't have known I had a problem if I didn't.

So now all I have to do is look at each of the 34 packages and get the
previous version and then put my old network card back and then update one
at a time and stop and start the network until it breaks.

I am thinking it was like a glibc or libxxx or maybe unix-utils.


Jan 12 19:55:57 Updated: libgcc.i386 4.1.1-51.fc6
Jan 12 19:57:10 Updated: glibc-common.i386 2.5-10.fc6
Jan 12 19:57:35 Updated: glibc.i686 2.5-10.fc6
Jan 12 19:57:44 Updated: mono-core.i386 1.1.17.1-4.fc6
Jan 12 19:57:45 Updated: libstdc++.i386 4.1.1-51.fc6
Jan 12 19:57:48 Updated: mono-data.i386 1.1.17.1-4.fc6
Jan 12 19:57:53 Updated: gimp-print.i386 4.2.7-23.fc6
Jan 12 19:57:54 Updated: libgomp.i386 4.1.1-51.fc6
Jan 12 19:57:55 Updated: libgfortran.i386 4.1.1-51.fc6
Jan 12 19:57:58 Updated: gawk.i386 3.1.5-13.fc6
Jan 12 19:58:02 Updated: shadow-utils.i386 2:4.0.17-11.fc6
Jan 12 19:58:06 Updated: glibc-headers.i386 2.5-10.fc6
Jan 12 19:58:09 Updated: glibc-devel.i386 2.5-10.fc6
Jan 12 19:58:11 Updated: mono-web.i386 1.1.17.1-4.fc6
Jan 12 19:58:29 Updated: libgcj.i386 4.1.1-51.fc6
Jan 12 19:58:43 Updated: libstdc++-devel.i386 4.1.1-51.fc6
Jan 12 19:58:45 Updated: postgresql-libs.i386 8.1.6-1.fc6
Jan 12 19:58:49 Updated: lm_sensors.i386 2.10.1-1.fc6
Jan 12 19:58:51 Updated: cpp.i386 4.1.1-51.fc6
Jan 12 19:58:54 Updated: gcc.i386 4.1.1-51.fc6
Jan 12 19:58:59 Updated: selinux-policy.noarch 2.4.6-23.fc6
Jan 12 19:59:01 Updated: gcc-gfortran.i386 4.1.1-51.fc6
Jan 12 19:59:01 Updated: gimp-print-utils.i386 4.2.7-23.fc6
Jan 12 19:59:03 Updated: gcc-c++.i386 4.1.1-51.fc6
Jan 12 19:59:05 Updated: wget.i386 1.10.2-8.fc6.1
Jan 12 19:59:06 Updated: cpuspeed.i386 1:1.2.1-1.46.fc6
Jan 12 19:59:08 Updated: autofs.i386 1:5.0.1-0.rc3.2
Jan 12 19:59:09 Updated: m4.i386 1.4.5-4
Jan 12 19:59:10 Updated: tar.i386 2:1.15.1-24.fc6
Jan 12 19:59:11 Updated: mono-data-sqlite.i386 1.1.17.1-4.fc6
Jan 12 19:59:13 Updated: nscd.i386 2.5-10.fc6
Jan 12 19:59:16 Updated: util-linux.i386 2.13-0.45.4.fc6
Jan 12 19:59:52 Updated: selinux-policy-targeted.noarch 2.4.6-23.fc6
Jan 12 19:59:53 Updated: jpackage-utils.noarch 1.7.3-1jpp.2.fc6

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux