12:57 a.m.
Since there has been a lot of talk about servers.
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.
On other unix boxes I work on there is the option to save files that are
replaced and then you can clean that out after you know things are working.
Or if things don't work you can put those files back.
Also might be nice to change the yum.log to show what version was updated to
the new version instead of just what the new version is.
Example:
/var/log/yum.log
Jan 12 19:59:10 Updated: tar.i386 2:1.15.1-24.fc6
Would look like:
Jan 12 19:59:10 Updated: tar.i386 1.15.1-23.fc6 2:1.15.1-24.fc6
1:07 a.m.
On 1/12/07, Jerry Williams <jwilliam(a)xmission.com> 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
1:56 a.m.
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
bounces(a)redhat.com] 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(a)xmission.com> 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
2:43 a.m.
On 1/12/07, Jerry Williams <jwilliam(a)xmission.com> wrote:
Does rpm need to be fixed to keep a previous version or something
else?
There are aspects of rpm operation which are very difficult to
rollback. You are thinking in terms of rpm payload, but you aren't
thinking about things like post-install scriptlet actions, which work
on files in a way which are not tracked by the rpmdb. There is also
the complication of rpm triggers which are even less obviously
trackable. Triggers are somewhat rarer aspects of rpm packages, but
since they only get...triggered...in certain situations they greatly
complicate the scenario matrix, in ways that can be difficult to
confirm.
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.
yum has a caching option, which you are free to enable.
man yum.conf, look for keepcache
Taken together with the available rpmpkg log, you can reinstall older
versions of a package.
I believe there is a yum plugin that you will find useful, if you
don't want to resort to rpm -Uvh --oldpackage, to do the dirty work.
yum info yum-allowdowngrade
"This plugin adds a --allow-downgrade flag to yum to make it possible to
manually downgrade packages to specific versions."
But I have to stress that there is no garuntee that downgrading to a a
previously installed package version for any particular package will
give you back exactly what you had before. scriptlets nor trigger
actions are necessarily rolled-back, along with the trackable
payloads.
-jef
3:29 a.m.
On Fri, 12 Jan 2007, Jeff Spaleta wrote:
yum has a caching option, which you are free to enable.
man yum.conf, look for keepcache
Taken together with the available rpmpkg log, you can reinstall older
versions of a package.
I believe there is a yum plugin that you will find useful, if you
don't want to resort to rpm -Uvh --oldpackage, to do the dirty work.
yum info yum-allowdowngrade
"This plugin adds a --allow-downgrade flag to yum to make it possible to
manually downgrade packages to specific versions."
Or you can enable rpm rollbacks. You can't use yum to do the actual
rollback but you can use rpm cli for that, yum (or actually rpmlib) will
create the rollback packages on erasures and upgrades.
See for example http://www.linuxjournal.com/article/7034 and
http://www.oreillynet.com/onlamp/blog/2006/01/rpm_rollback_in_fedora_core...
forsome further info on the topic.
- Panu -
11:48 a.m.
On Saturday 13 January 2007 04:29, Panu Matilainen wrote:
On Fri, 12 Jan 2007, Jeff Spaleta wrote:
... post install scripts ..
In principal the package could provide and uninstall script which would
reverse the scripts. THis is of course an additional burdon on the
maintainer - and well may be a better thing to target enterprise and have
customer cover the cost.
g/
11:48 a.m.
On Saturday 13 January 2007 12:48, Mail List wrote:
In principal the package could provide and uninstall script which
would
reverse the scripts. THis is of course an additional burdon on the
maintainer - and well may be a better thing to target enterprise and have
customer cover the cost.
And you can know how to "rollback" those scripts for every possible rollback
point? Not just D->C, but D->B, D->A or maybe D-> B as upgraded by A, and
D-> B directly installed.
--
Jesse Keating
Release Engineer: Fedora
12:14 p.m.
On Saturday 13 January 2007 12:48, Jesse Keating wrote:
And you can know how to "rollback" those scripts for every
possible
rollback point? Not just D->C, but D->B, D->A or maybe D-> B as upgraded
by A, and D-> B directly installed.
Indeed - I suspect 99% of customers would be happy with a single rollback.
But in principal with a good scheme to keep prev files etc one could iterate
the scripts restoring 1 version back at a time until you've reached the level
you want.
2:10 p.m.
On 1/13/07, Mail List <lists(a)sapience.com> wrote:
Indeed - I suspect 99% of customers would be happy with a single
rollback.
But in principal with a good scheme to keep prev files etc one could iterate
the scripts restoring 1 version back at a time until you've reached the level
you want.
I think you grossly over-simplify the problem space. But at a basic
level how do you suggest we actually verify that the roll-back
succeeded correctly for any given scriplet action for any given
package? Not all files on the system are tracked by rpmdb, and
scriplets can act on any file.
For example... some scripts can and will change ownership or
permissions under certain conditions.. on items like configuration
files why may or may not be tracked. How exactly do you roll-back
those individual system permissions or ownership as a package
maintainer? All you can do is roll-back to a default for all
systems... but that is not a garuntee to be roll-back to the previous
system state of any particular system.
And in some cases it makes absolutely no sense to roll the action back
automatically.
What about packages that add groups or users onto your system? Are you
suggesting you roll-back scriptlet actions and remove those users and
groups automatically.. potentially leaving users unable to access
files which are owned by that group?
The only way you are going to get real system roll-back is by
drastically reducing the amount of functionality that scriptlets are
allowed to do by defining very strict policy statements. I've looked
into my crystal ball... that's not happening in Fedora for at least
the first 16 releases, I'd look further into the future but my crystal
ball only as a 4 bit clock.
I would however encurage you to get familiar with discussions
concerning carrier grade linux and its servicability requirement
discussions to make for more informed discussions here.
-jef
2:51 p.m.
Le samedi 13 janvier 2007 à 12:48 -0500, Mail List a écrit :
On Saturday 13 January 2007 04:29, Panu Matilainen wrote:
> On Fri, 12 Jan 2007, Jeff Spaleta wrote:
> ... post install scripts ..
In principal the package could provide and uninstall script which would
reverse the scripts. THis is of course an additional burdon on the
maintainer - and well may be a better thing to target enterprise and have
customer cover the cost.
This would be very hard to do. On post install you know the target state
of the system, but how are you supposed to guess what are you roll
backing to ?
IMHO if you want working rollback rpm or yum needs to intercept file
writes and snapshot their previous state (which still leaves other
operations like sending dbus signals for the packager to rollback
manually)
--
Nicolas Mailhot
11:25 a.m.
On Saturday 13 January 2007 15:51, Nicolas Mailhot wrote:
> In principal the package could provide and uninstall script
which would
This would be very hard to do. On post install you know the target state
of the system, but how are you supposed to guess what are you roll
backing to ?
I think the reasoble choice is to roll back to state as it was when the rpm
was installed - noone would expect to roll back to an arbitrary state.
g/
noon
Le dimanche 14 janvier 2007 à 12:25 -0500, Mail List a écrit :
On Saturday 13 January 2007 15:51, Nicolas Mailhot wrote:
> > In principal the package could provide and uninstall script which would
>
> This would be very hard to do. On post install you know the target state
> of the system, but how are you supposed to guess what are you roll
> backing to ?
I think the reasoble choice is to roll back to state as it was when the rpm
was installed - noone would expect to roll back to an arbitrary state.
But then the *package* itself does not know this state. The system does.
--
Nicolas Mailhot
5:25 p.m.
On Sunday 14 January 2007 13:00, Nicolas Mailhot wrote:
But then the *package* itself does not know this state. The system does.
I'm sure I'm missing something - but if a package install changes a file -
sat /etc/foo and saves the old in /etc/foo.rpmold - then at least in that
case foo can be restored - all that needs be done is keep a history of things
that were replaced so they can be restored.
1:54 a.m.
Le Lun 15 janvier 2007 00:25, Mail List a écrit :
On Sunday 14 January 2007 13:00, Nicolas Mailhot wrote:
>
> But then the *package* itself does not know this state. The system does.
I'm sure I'm missing something - but if a package install changes a
file -
sat /etc/foo and saves the old in /etc/foo.rpmold
Since .rpmnew/.rpmsave files are generated at rpm not packager scriplets
level today, I'll take that as a +1
--
Nicolas Mailhot
11:15 a.m.
On 1/14/07, Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
Le samedi 13 janvier 2007 à 12:48 -0500, Mail List a écrit :
> In principal the package could provide and uninstall script which would
> reverse the scripts. THis is of course an additional burdon on the
> maintainer - and well may be a better thing to target enterprise and have
> customer cover the cost.
This would be very hard to do. On post install you know the target state
of the system, but how are you supposed to guess what are you roll
backing to ?
RPM could provide a mechanism for storing various types of data and
macros for common changes (eg changes of file attributes), so that
when the install scripts run, any changes they make can be stored
somewhere by rpm. Then, when the scripts run to undo the install
script, this data can be used to put things back the way they were
previously (provided they haven't been modified since the install
script ran, which might mean you get .rpmrollback files instead).
The majority of install scripts (eg lots of update-index-x and
ldconfig) could even be replaced by inbuilt macros designed to support
rollbacks. For other packages that do more specialized things in
scripts, the storage mechanism and extra scripts would be required.
If the support was there in rpm and there was consensus that this is a
good feature to put in Fedora, then we could begin by loosely
requiring (unless it is technically not feasible or at all practical)
that new packages support rollback. RPM could detect if a package
supports rollbacks by either the presence of rollback scripts or if
the package uses no scripts or only the new rollback safe macros (we
could make macros like %ldconfig etc) in scripts.
There are also other advantages to having macros like %ldconfig made
in that rpm can use this to optimize updates/installs by only running
ldconfig at the very end, or before any dependent packages are
updated/installed.
Not all the packages would need to be rollback safe for the system to
work nicely. If you wanted to rollback some particular update/install,
as long as all the packages involved in that update/install were
rollback safe there would be no issues with performing a rollback.
Eventually more and more packages (and hopefully any important system
ones) would support rollback. If the user asks rpm to rollback an
update/install that involved a non-'rollback safe' package, rpm could
either; warn the user and ask if it should continue, or just fail with
an error message about the package not supporting rollbacks.
Here is some quick stats from this box:
- Number of packages installed: 1576
- Number of packages containing some kind of rpm script: 731
- Number of packages containing scripts without completely obvious
methods of rolling back*: 192
Essentially this means that all but 192 of the rpms installed on my
machine could have their rpm scripts replaced with macros made to do
the same thing, or involve operations that could be marked (like
%rollback_safe('cmd')) as not needing any rollback. Of these 192, I
don't think there are very many that couldn't be made rollback safe
with small bit of work.
n0dalus.
* I did this by quick visual inspection of the scripts in each package
after dumping them to a big file. I removed any scripts which; only
added users, updated some cache (eg gtk-update-icon-cache), setup a
trigger for prelink, removed .pyc files, created font indexes or
updated info pages, ran ldconfig, chkconfig/service or other init.d
scripts.
2:51 p.m.
On 1/15/07, n0dalus <n0dalus+redhat(a)gmail.com> wrote:
RPM could provide a mechanism for storing various types of data and
macros for common changes (eg changes of file attributes), so that
when the install scripts run, any changes they make can be stored
somewhere by rpm.
do you account for multiple packages, making changes to the same file?
So far I see assumptions being made about simple one-to-one mapping
of packages to file changes.
But if foo and bar both edit a file as part of scriptlet action, what
happens if you rollback bar but not foo or foo and not bar? Simple
diffs of file state at package install time are not necessarily
adequate, unless you can garuntee that scriplets from multiple
packages do not re-edit files. Can we be so sure of that?
-jef"I know! How about we just have rpm make an rdiff-backup snapshot
of the full system state with each package installation"spaleta
3:20 p.m.
Le lundi 15 janvier 2007 à 11:51 -0900, Jeff Spaleta a écrit :
On 1/15/07, n0dalus <n0dalus+redhat(a)gmail.com> wrote:
> RPM could provide a mechanism for storing various types of data and
> macros for common changes (eg changes of file attributes), so that
> when the install scripts run, any changes they make can be stored
> somewhere by rpm.
do you account for multiple packages, making changes to the same file?
So far I see assumptions being made about simple one-to-one mapping
of packages to file changes.
…
Simple
diffs of file state at package install time are not necessarily
adequate,
You're assuming all changed files are text files here
unless you can garuntee that scriplets from multiple
packages do not re-edit files. Can we be so sure of that?
The simple stupid robust answer is:
— don't assume anything, snapshot all changed files
— only allow full-transaction rollbacks
– when a rollback is requested, also rollback all the packages that
touched the snapshoted files since
You can get by without all this most of the times, but then Murphy says
the day you need the rollback you'll have one of the corner cases
shotcuts don't handle
--
Nicolas Mailhot
3:47 p.m.
On 1/15/07, Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
The simple stupid robust answer is:
— don't assume anything, snapshot all changed files
— only allow full-transaction rollbacks
– when a rollback is requested, also rollback all the packages that
touched the snapshoted files since
Did you read my sig? Sounds just like an rdiff-backup of the system to me.
-jef
4:21 p.m.
Le lundi 15 janvier 2007 à 12:47 -0900, Jeff Spaleta a écrit :
On 1/15/07, Nicolas Mailhot <nicolas.mailhot(a)laposte.net>
wrote:
> The simple stupid robust answer is:
> — don't assume anything, snapshot all changed files
> — only allow full-transaction rollbacks
> – when a rollback is requested, also rollback all the packages that
> touched the snapshoted files since
Did you read my sig? Sounds just like an rdiff-backup of the system to me.
With some rpm plumbing to associate packages to backups, sure
--
Nicolas Mailhot
6:05 p.m.
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> wrote:
Le lundi 15 janvier 2007 à 11:51 -0900, Jeff Spaleta a écrit :
[...]
> unless you can garuntee that scriplets from multiple
> packages do not re-edit files. Can we be so sure of that?
The simple stupid robust answer is:
— don't assume anything, snapshot all changed files
OK.
— only allow full-transaction rollbacks
Define "full transaction"...
– when a rollback is requested, also rollback all the packages that
touched the snapshoted files since
Great idea. One package breaks, get it fixed (by its latest version) and
get back all breakage fixed by the last round of updates.
You can get by without all this most of the times, but then Murphy
says
the day you need the rollback you'll have one of the corner cases
shotcuts don't handle
Exactly.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
7:30 p.m.
On 1/16/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 1/15/07, n0dalus <n0dalus+redhat(a)gmail.com> wrote:
> RPM could provide a mechanism for storing various types of data and
> macros for common changes (eg changes of file attributes), so that
> when the install scripts run, any changes they make can be stored
> somewhere by rpm.
do you account for multiple packages, making changes to the same file?
So far I see assumptions being made about simple one-to-one mapping
of packages to file changes.
But if foo and bar both edit a file as part of scriptlet action, what
happens if you rollback bar but not foo or foo and not bar? Simple
diffs of file state at package install time are not necessarily
adequate, unless you can garuntee that scriplets from multiple
packages do not re-edit files. Can we be so sure of that?
If you had read the rest of that paragraph, you would have noticed I
said "...provided they haven't been modified since the install script
ran, which might mean you get .rpmrollback files instead."
In other words, after the install scripts run, they need to save
whatever data (sha1sum, etc) needed so that the rollback script can
check to see if the data has been changed since. If it has been
changed, it can either perform the rollback but make .rpmrollback
files, or just abort.
There is always going to a few packages with complex rpm scripts that
won't ever be rollback safe. I'm sure you could ponder my assumptions
and come up with several rpms that break them, but luckily it doesn't
really matter. The vast majority of packages (look at my numbers in my
previous post) could easily be made safe for rolling back, and a
rollback system would still be useful for rolling back any of these
packages.
As I looked through the rpm scripts, I found they could be split into
a few main categories (ordered more or less by frequency):
1) Updating a cache or index. This is rollback safe, the cache/index
updater just needs to be run after rollback.
2) Installing info pages. It would be nice if these could be installed
without any scripts, as with man pages, but either way it is fairly
easy to rollback.
3) Changing chkconfig stuff and restarting/stopping services
after/before updates/removals. If Fedora ever changes to a new init
system, the former may be possible to do by just installing files into
the right directories. Anyway, this is also rollback safe.
4) Adding users and groups. Rollback safe.
5) Setting up directories and permissions. I have no idea why this is
being done in scripts instead of just in the package. They probably
need to be decided on a case by case basis as to what to do on
rollback (eg, keep the directory, or remove it including any
contents).
6) Other things, long scripts which convert database formats and
things like that. Some of these might not be rollback safe.
n0dalus.
6:11 p.m.
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
bounces(a)redhat.com] On Behalf Of Panu Matilainen
Sent: Saturday, January 13, 2007 2:30 AM
To: Development discussions related to Fedora Core
Subject: Re: yum roll back option?
On Fri, 12 Jan 2007, Jeff Spaleta wrote:
>
> yum has a caching option, which you are free to enable.
> man yum.conf, look for keepcache
>
> Taken together with the available rpmpkg log, you can reinstall older
> versions of a package.
> I believe there is a yum plugin that you will find useful, if you
> don't want to resort to rpm -Uvh --oldpackage, to do the dirty work.
> yum info yum-allowdowngrade
> "This plugin adds a --allow-downgrade flag to yum to make it possible to
> manually downgrade packages to specific versions."
Or you can enable rpm rollbacks. You can't use yum to do the actual
rollback but you can use rpm cli for that, yum (or actually rpmlib) will
create the rollback packages on erasures and upgrades.
See for example http://www.linuxjournal.com/article/7034 and
http://www.oreillynet.com/onlamp/blog/2006/01/rpm_rollback_in_fedora_core_
45.html
forsome further info on the topic.
- Panu -
I went and looked at the example and created the /etc/rpm/macros and put
%_repackage_all_erasures 1 in it.
Then I ran the rpm -Uvh --oldpackage on about 10 packages.
I shutdown the machine and put the old network card back in and it worked
fine.
I also changed keepcache=1 in /etc/yum.conf.
Then I ran yum update for a few packages at a time and left glibc last.
I installed all of the updates that I had put back and it still works fine.
So then I tried to power of the box and unplug it and it still works.
So I don't know what to say about the error. But it has been a very good
learning experience for me.
I again have learned some new things and I want to thank everyone for their
comments and help.
I have thought about the different things people have said and this doesn't
seem to be an easy problem. It turns out that some of the packages haven't
been changed from the original release, this was their first time.
I also noticed in that Jan 07 10:50:15 Updated: tar.i386 2:1.15.1-23.fc6 is
in the yum.log, but that it never shows up in any of my rpmpkgs logs.
# grep tar.i386 yum.log
Nov 30 01:00:18 Updated: tar.i386 2:1.15.1-21.fc6
Dec 12 23:19:46 Updated: tar.i386 2:1.15.1-22.fc6
Jan 07 10:50:15 Updated: tar.i386 2:1.15.1-23.fc6
Jan 12 19:59:10 Updated: tar.i386 2:1.15.1-24.fc6
# grep ^tar rpmpkgs*
rpmpkgs:tar-1.15.1-24.fc6.i386.rpm
rpmpkgs.1:tar-1.15.1-22.fc6.i386.rpm
rpmpkgs.2:tar-1.15.1-22.fc6.i386.rpm
rpmpkgs.3:tar-1.15.1-22.fc6.i386.rpm
rpmpkgs.4:tar-1.15.1-22.fc6.i386.rpm
Also the man page for yum doesn't match the default in the yum.conf file:
yum clean packages
Eliminate any cached packages from the system. Note that pack-
ages are not automatically deleted after they are downloaded.
I think that default in the yum.conf should be changed to keep the files, or
at least the config and man page should agree.
I think that I would be happy to just be able to go back to the previous
version. In most cases I would have the original media and could put the
original files back. I like the idea of the %_repackage_all_erasures but I
think that I would feel better with the original rpm file. Which makes me
think of another idea.
Some thing like yum clean packages keep=2 or change the option in yum.conf
keepcache=2 where it would keep 2 versions of a package. Or maybe it would
be another option. Or arguments like none, no, all, or a number for how
many versions you would like to keep.
I also noticed that yum didn't use the /etc/rpm/macros file, but someone did
mention an option for yum.conf. But like I said I prefer to use the
original rpm file and not spend the time doing the repackage.
I was wondering why yum.log uses the format it does to do the logging?
And what is the 2: for in like: Jan 12 19:59:10 Updated: tar.i386
2:1.15.1-24.fc6?
I was just thinking it might be easier to pull into a script if it looked
like:
Jan 12 19:59:10 Updated: tar-1.15.1-23.fc6.i386.rpm
tar-1.15.1-24.fc6.i386.rpm
Date updated: old package name new package name
2:44 a.m.
On 1/13/07, Jerry Williams <jwilliam(a)xmission.com> wrote:
> -----Original Message-----
[...]
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.
While I sympathize with your situation. I think your suggestion brings
RPM way beyond what it should be doing, into the realm of Yum.You can
have yum cache all files that are downloaded. And unless you do an
http `rpm -i`, you should have a copy of an RPM, it would then be up
to you to store it safely. Alone those lines, I was quite dissapointed
to find out that Fedora had changed the yum default of caching
downloaded RPMs to not caching them. Maybe it was mentioned in the
release notes, but I found that out at a rather bad time - I had come
to depend on a backup copy of the RPM being in the yum cache folder.
But back to your point...yum _should_ be able to:
1) "rollback" a package (and maybe it's dependancies) to a previos
version...downloading the packages if necessart
2) roll back the entire RPM system to a particular point in time..sort
of like System Restore , or whatever it is called in Windows...a
restore point I think they call it.
A sample scenario is that a kernel patch/fix/update causes your system
to bork...and it is not a widespread issue, so you don't except a fix
soon. At least you could roll back the kernel package - but that is a
very bad example since the last 2 kernels are kept.
--
Fedora Core 6 and proud
10:46 a.m.
On Sat, 2007-01-13 at 02:44 -0600, Arthur Pemberton wrote:
On 1/13/07, Jerry Williams <jwilliam(a)xmission.com> wrote:
> > -----Original Message-----
[...]
> 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.
While I sympathize with your situation. I think your suggestion brings
RPM way beyond what it should be doing, into the realm of Yum.You can
have yum cache all files that are downloaded. And unless you do an
http `rpm -i`, you should have a copy of an RPM, it would then be up
to you to store it safely. Alone those lines, I was quite dissapointed
to find out that Fedora had changed the yum default of caching
downloaded RPMs to not caching them. Maybe it was mentioned in the
release notes, but I found that out at a rather bad time - I had come
to depend on a backup copy of the RPM being in the yum cache folder.
But back to your point...yum _should_ be able to:
1) "rollback" a package (and maybe it's dependancies) to a previos
version...downloading the packages if necessart
I think "tsflags=repackage" still works in /etc/yum.conf, right?
Keeping in mind, of course, that a repackaging is not *completely*
equivalent to the original RPM.
2) roll back the entire RPM system to a particular point in
time..sort
of like System Restore , or whatever it is called in Windows...a
restore point I think they call it.
You could try version-controlling the repackaging area
(/var/spool/repackage ?). Of course I understand you're looking for a
Shiny Red Button, but the back end is mostly there.
A sample scenario is that a kernel patch/fix/update causes your
system
to bork...and it is not a widespread issue, so you don't except a fix
soon. At least you could roll back the kernel package - but that is a
very bad example since the last 2 kernels are kept.
--
Paul W. Frields, RHCE http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
Fedora Project Board: http://fedoraproject.org/wiki/Board
Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject
6348
days inactive
6351
days old
23 comments
10 participants
participants (10)
-
Arthur Pemberton -
Genes MailLists -
Horst H. von Brand -
Jef Spaleta -
Jerry Williams -
Jesse Keating -
n0dalus -
Nicolas Mailhot -
Panu Matilainen -
Paul W. Frields