[opensuse] Manual dist upgrade procedure(s) & tools/progs/aids?
yum check-update localupdate this gave the output:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure: booting from the new media boot-disk and having all packages updated at one time while the system is "offline" (not usable for other tasks). This isn't necessary a trivial or officially supported or sanctioned way to do things, but I have my reasons for doing things this way... When I say "utility" that can help me do this, I mean utility as being one of (or a combination of) a "program", "script", "collection of scripts". I want to upgrade a 'live' system, that was based on an older suse release (suse9.3 in this case) to newer packages -- mostly from 10.3 (or 10.2 for packages that are broken in 10.3). Theoretically, (or ideally), the utility would work with any RPM based distribution, but my main focus is on SuSE's dists right now (as has been case for ... since ~ suse 6.x or 7.x). So -- want to have a util that can inspect my current RPM's, and pick out the updates from the target dist (in this case 10.3), find the needed deps and install them. I want the command to be able to be run over some "set" of older RPM's at 1 time. I'm doing this logged in *remotely* (not at a console), so amusing ssh -- so an example of doing things partially -- would be to upgrade "open-ssh" and its requirements 1st, then install and get it working before continuing (ensuring that remote access will continue to work through the remainder of the upgrade). In my current situation, that's already done. But what gets to be hairy is, making sure mutually dependent RPM's are updated in 1 rpm command so all their reqs & obsoletes are handled in the same command so the system doesn't (ideally) need to transition to a "bad-state" where something is broken. Are there any tools to help me upgrade a package (with the new RPM's being *local* (either on same machine, or on a local subnet available via "whatever" (SMB, NFS, scp/ssh), that would solve (resolve) package dependencies, conflicts and obsoletes and generate or execute a single rpm command, "at a time", that would consistent within itself? I don't want it to upgrade *all* RPM's at one time -- just the necessary, dependent ones. There are two types of RPMs that need to be upgraded: 1) those RPMs that either a) have no prereqs, or b) already have all needed pre-reqs installed 2) those RPM's that need other RPM packages to be updated at the same time in order to solve dependencies Is there command-line utility (prog, script, set of scripts) that does this already? Is this a utility other "manual-updater" hacker-types would find useful or helpful? ------- Right now, I have to go through all of this process manually (which is a bit labor intensive), but I'd like to have a util (or set of utils) that could find needed pre-reqs so I could execute 1 RPM command at a time that would upgrade some interdependent "subset" of packages. So does such exist? Does anyone else go through manual upgrading because they maybe: 1) aren't on the same-update cycle frequency as new distribution-versions are released? and/or 2) Don't want to bring down the active system they are updating except for simple 'reboots' when needed (like to activate a new running kernel)? and/or 3) only want to upgrade *select* newer packages that "need to be updated" (for whatever reason, bugs, features, etc.). --- Maybe there is a utility, perhaps built on top of rpm, that already does most of this? A preliminary look at "yum" didn't seem to show it was what I wanted and its workings were a bit cryptic. I tried it, but my early attempts shed no light on how 'yum' might provide these features. I tried: primary.xml.gz 100% |=========================| 7.8 MB 00:26 opensuse : ################################################## 17136/17136 opensuse-updates 100% |=========================| 1.2 kB 00:00 primary.xml.gz 100% |=========================| 1.7 MB 00:08 opensuse-u: ################################################## 4584/4584 --- This didn't really tell me what it did or what it was trying to do. It didn't appear to do any upgrading of existing older packages, so I'm not sure what it did. I tried adding the '-v'erbose switch, and repeating the command, but that only generated more questions about what it was doing. Partial output: Installroot: / Ext Commands: localupdate Reading Local RPMDB Setting up Package Sacks Building updates object putting libzypp in complex update putting libevent in simple update putting ghostscript-x11 in complex update putting wv in simple update .... [ continues with "putting <pkg> in [simple|complexe] update"] (about 160 pkgs total, then: ) processing libzypp processing ghostscript-x11 .... [ Continues processing *only( 'complex' packages from above ] Matching packages for package list to user args ( Program exits w/status 0) So it doesn't seem to be what I want (that's ok, just wondered if it was going to try to do what I wanted, but it seems it's for a different purpose). Haven't tried any other tools at this point. Ideas? Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools? Thanks much, Linda W. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 05/06/2008 05:39 AM, Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure: booting from the new media boot-disk and having all packages updated at one time while the system is "offline" (not usable for other tasks). <snip>
Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools? I don't think this would be possible (or so far from ideal as to not be too useful). Several limitations come to mind, i.e. newer versions of rpm needed, or glibc, which affect every rpm package in a new distribution. From what I have learned over the years is replacing glibc on a live system is not a good idea. That is why the offline upgrade is best. Upgrading a live system has a lot of pitfalls that would probably make it a nightmare in practice.
-- Joe Morris Registered Linux user 231871 running openSUSE 10.3 x86_64 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joe Morris wrote:
On 05/06/2008 05:39 AM, Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure ... "offline" (not usable for other tasks). <snip> Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools?
I don't think this would be possible (or so far from ideal as to not be too useful). Several limitations come to mind, i.e. newer versions of rpm needed, or glibc, which affect every rpm package in a new distribution. From what I have learned over the years is replacing glibc on a live system is not a good idea. That is why the offline upgrade is best. Upgrading a live system has a lot of pitfalls that would probably make it a nightmare in practice.
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way? Some things require restarting the machine -- currently, on linux, kernel upgrades still usually require a reboot -- but features are being worked on in linux to eliminate that requirement as well. If the *kernel* can do it, tell me one problem that an application has that can't also be overcome? It's also, IMO, poor engineering practice to change everything at once. If you do, you can't tell what has broken where. You upgrade everything at once, and when things inevitably don't work the first time, or immediately, there are way too many possible causes to even begin giving you a hint. But -- like in upgrading incrementally - - from 10.2 -> 10.3, I found the NFS server in 10.3 to be broken/non functional, but reinstalling 10.2 still worked. But with a whole-product upgrade I did on another machine -- I had no clue why NFS wouldn't serve. I gave up trying to track it down -- I had "scheduled" a few hours for what was to be an "easy" auto upgrade -- and it broke things (its a rare upgrade where nothing breaks). It wasn't until I did an incremental update on a more *key* system that I found the problem was specific to the 10.3 NFS server package, and that if I "backgraded" my 10.3's NFS-server package to 10.2, it started working. So in *STRONG COUNTER* to your statement about possibilities -- I find it is nearly impossible for me to upgrade one of my systems automatically and *NOT* have something break. (I'm not using caps for "yelling", just contrasting emphasis to make the point that one (or me, in particular :-)) can be 'screwed' either way. :-) *sigh*. Oh how I wish for SGI's IRIX's "inst" updating package -- was *SO* advanced compared to what's available these days. It could tell you how much space was taken up on *each* partition/volume by installed packages (or what the space Delta would be for adding/removing). And the only time you needed to take the system "offline" (officially) was to replace the 'base' system containing the kernel, drivers and immediate utils to boot the system. Even that was able to be "worked around" for interested parties. The only time I had to install from "offline" (booting from mini-root), was to "*CROSS*-grade" to a different product variation (Trusted IRIX), which had to go through and set the default security permission fields on all of the files and boot from a security-enabled kernel that could interpret and set such flags (and wouldn't work on a normal FS). Sadly -- it is amazing how many computer science advances and features are developed, and *LOST*, as new OS's and new programmers take the place of the previous generation(s). Happened *before* me, and has happened while I've been in the field, and is actively happening again. And so many people, sadly, think that the "new features" are so "cool", and don't realize that computers already had these features 10-40 years ago and that due to industry practice of hiring young cheap programers and "axing" older, experienced workers, how much established knowledge and research is lost. So many advances in computers are *lost*. With complete new "myths" and practices replacing old practices and knowledge. How many people believe that programs released with bugs is "normal"? It didn't used to be. There was exhaustive testing and real alpha/ beta periods that looked at bug-found rates. Only when bug-find rates had dropped below certain levels would products be allowed out -- and in some cases (*important* programs used in hardware control, embedded systems, and secure systems, testing was exhaustive -- with required metrics on test suite coverage). How often is that done today? Isn't the normal practice today to release "Beta" quality products as shipping products and expect that in-field patching will be used to compensate for lack of in-house, pre-release testing? Sorry for long note and to anyone where I'm 'preaching to the choir'. FWIW, while those who do not know the past are doomed to reimplement and repeat it, that *DOESN'T* mean they are not intelligent. It's just that the needed "learned" knowledge base gets larger and isn't adequately sifted and summarized into industry standard (best) practices. Also, FWIW -- I've been working on a script to do/implement the incremental upgrade process (at least as a helper) to handle tasks that have traditionally had to do myself. I can feed the output of an RPM command and it's "errors" into my script, and it can tell me the next thing to try (not complete, but handles many common cases). Ex: I feed output from an error, a message in a log file (even has junk before and after the rpm command due to being from a test-install-script log file) the rpm command) like: EXEC(nobit): /bin/rpm -Uhv --test i586/wv-1.2.2-75.i586.rpm, stat=256, out=error: Failed dependencies: libgsf-1.so.114 is needed by wv-1.2.2-75.i586 my script outputs the "next" rpm command I should try: /bin/rpm -Uhv i586/wv-1.2.2-75.i586.rpm i586/libgsf-1.14.5-23.i586.rpm i586/librsvg-2.18.2-9.i586.rpm i586/gnome-vfs2-2.20.0-3.i586.rpm NOTICE: it doesn't just find the package containing missing dep, but also finds dependencies needed by libgsf (librsvg) and those needed by librsvg(gnome-vfs2). It isn't a finished script, and may not be 100% correct in every case (yet :-)...but there may be diminishing returns for arcane cases for a tool designed to be an "assistant" but it can find and deal with a few problems. Blessings -- and hey -- it's only a 'myth' that if you sail too far you will fall off the edge of the world or be eaten by sea monsters. Many people might die trying to disprove it...and there may be mutinous problems, but that doesn't mean the widely believed myth is true. :-) (Though I'm sure sailing "too far" wasn't officially supported in those days -- since no official wanted to encourage ventures that might cause lots of problems for people. *sigh*... Do we ever really _know_ what is really true? Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Linda Walsh wrote:
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way?
I have to agree - I've upgraded machines from redhat 8 to fedora core while running, obviously not the redhat way, but by using apt-get it was no problem at all to keep the box in service, during the upgrade process. When it was convenient, we booted into the new kernel, marking the final step of the upgrade process. I know people have updated suse the same way - surely we don't need to regress from what we were able to do 5 years ago? Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Linda Walsh wrote:
Joe Morris wrote:
On 05/06/2008 05:39 AM, Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure ... "offline" (not usable for other tasks). <snip> Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools?
I don't think this would be possible (or so far from ideal as to not be too useful). Several limitations come to mind, i.e. newer versions of rpm needed, or glibc, which affect every rpm package in a new distribution. From what I have learned over the years is replacing glibc on a live system is not a good idea. That is why the offline upgrade is best. Upgrading a live system has a lot of pitfalls that would probably make it a nightmare in practice.
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way?
Define "too costly" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2008-05-05 at 22:53 -0400, Sam Clemens wrote:
Linda Walsh wrote:
Joe Morris wrote:
On 05/06/2008 05:39 AM, Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure ... "offline" (not usable for other tasks). <snip> Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools?
I don't think this would be possible (or so far from ideal as to not be too useful). Several limitations come to mind, i.e. newer versions of rpm needed, or glibc, which affect every rpm package in a new distribution. From what I have learned over the years is replacing glibc on a live system is not a good idea. That is why the offline upgrade is best. Upgrading a live system has a lot of pitfalls that would probably make it a nightmare in practice.
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way?
Most companies will spend the time to setup redundancy so that they can take 1 server down at a time during upgrades and still be available so there is no cost hit. This is also smart if being down for any period of time is costly to you in case of hardware failures and the such. But with that said, openSUSE 11 with the latest zypper now supports doing Live updates via the dup arguments. But I think you should reconsider your setup and if its truly costly for you to be down during an upgrade, proper load balancing and fail over should be put in place. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Sam Clemens wrote:
Define "too costly"
Something that costs more than the alternatives? Another, perhaps less direct, but more annoying definition along the lines of "crossing the streams": "the the amount the government will need to pay off the exponentially increasing National Debt. (See: http://video.google.com/videoplay?docid=-9050474362583451279). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Linda Walsh wrote:
Sam Clemens wrote:
Define "too costly"
Something that costs more than the alternatives?
Build a replacement machine in your office, and ship it. By the way, if a crucial component on the current machine died (disk drive, power supply), would it be "too expensive" for someone to go fix it? If not, why is it to expensive for someone to go upgrade the OS offline? Something is wrong here. You've got managers who want IT, but don't want to budget enough money to run and maintain it properly.
Another, perhaps less direct, but more annoying definition along the lines of "crossing the streams": "the the amount the government will need to pay off the exponentially increasing National Debt. (See: http://video.google.com/videoplay?docid=-9050474362583451279).
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, May 5, 2008 at 7:25 PM, Linda Walsh
Joe Morris wrote:
On 05/06/2008 05:39 AM, Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure ...
"offline" (not usable for other tasks). <snip> Anyone else interested in this subject? Is there a better place to find people who might be interested or know about such tools?
I don't think this would be possible (or so far from ideal as to not be too useful). Several limitations come to mind, i.e. newer versions of rpm needed, or glibc, which affect every rpm package in a new distribution. From what I have learned over the years is replacing glibc on a live system is not a good idea. That is why the offline upgrade is best. Upgrading a live system has a lot of pitfalls that would probably make it a nightmare in practice.
------------
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way?
Huge overwrought rant snipped... Now lets suppose it was a power supply, or a memory module. What then? If this machine is so sensitive it can't be taken off line why don't you have a hot spare? Why don't you build, test, debug, and ship a replacement and have some dullard unplug the old one and plug in the new and be down 2 minutes? If its so sensitive and costly to be down, why are you not running SLES on it where upgrades are still being provided with minimal down time requirements? You want to go from 9.3 to 10.3, seamlessly, on a machine that (by all accounts) hasn't been down for more then a heartbeat since 9.3!?! Why? What ever for? If its not broke, don't fix it. Prepare its replacement, but leave it the hell alone, and don't try upgrading in place across a compiler change, 3 (or was it 4) kernel changes, disk driver changes, USB changes, etc, etc, etc. You've already waited TOO LONG to be ranting at others for poor planning or weak upgrade abilities. You're the one in trouble here, do to your own mismanagement and absence of planning. Try to remember the 6 Ps: Prior Planning Prevents Piss Pour Performance. -- ----------JSA--------- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-05-05 at 19:25 -0700, Linda Walsh wrote:
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way?
Have a spare ready. Or use a software system that costs real money and supports real, live, update. Look, you have to replace /every/ software thing in there. All programs depends on libraries, like glibc: every program depends on that one. Once you replace that library, most of the old programs may/will fail to start again. You are stuck. The procedure can work if every needed program is already running and remains running till the end of the procedure, because the running version is kept in memory, while the disk has the new (partial) version. Once you update everything (it is not possible to update some things, unless you use libraries on different paths, which means they are compiled to use those diffrnt paths), you restart everything, including the kernel. Chances are something will go bad. 100 to 1. The only method to update single packages is that you recompile those packages against your set of libraries, and install those. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFIIDaatTMYHG2NR9URAkvMAJ9U8/P/KpuhJwa2eytAy1s4ofFG+wCcCFA3 bEdsRnqPnH7KDbHZg/MXQwc= =epHr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Monday 2008-05-05 at 19:25 -0700, Linda Walsh wrote:
And when offline upgrading is not an option or when it is too costly? You just tell people "too bad?" What about people who don't want to do it the Windows way?
Have a spare ready. Or use a software system that costs real money and supports real, live, update.
Look, you have to replace /every/ software thing in there. All programs depends on libraries, like glibc: every program depends on that one. Once you replace that library, most of the old programs may/will fail to start again. You are stuck.
The procedure can work if every needed program is already running and remains running till the end of the procedure, because the running version is kept in memory, while the disk has the new (partial) version. Once you update everything (it is not possible to update some things, unless you use libraries on different paths, which means they are compiled to use those diffrnt paths), you restart everything, including the kernel.
Chances are something will go bad. 100 to 1.
The only method to update single packages is that you recompile those packages against your set of libraries, and install those.
And that merely delays the inevitable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Linda Walsh wrote:
This topic is not intended at those who only upgrade a system by running the "official" upgrade procedure: booting from the new media boot-disk and having all packages updated at one time while the system is "offline" (not usable for other tasks).
When I say "utility" that can help me do this, I mean utility as being one of (or a combination of) a "program", "script", "collection of scripts".
I want to upgrade a 'live' system, that was based on an older suse release (suse9.3 in this case) to newer packages -- mostly from 10.3 (or 10.2 for packages that are broken in 10.3).
So -- want to have a util that can inspect my current RPM's, and pick out the updates from the target dist (in this case 10.3), find the needed deps and install them.
Your main problem will be that (1) RPMs won't be there any more, (2) RPMs changed their name without any indication what their previous or new name is, and (3) you'll need new RPMs that you even don't know in advance about and that are not listed as dependencies. Alone the name of the kernel packages and associated kernel modules have changed several times between 9.x and 10.3. Therefore, this upgrade will probably be a manual experience for you... Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jschrod@acm.org Roedermark, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Joachim Schrod wrote:
Your main problem will be that (1) RPMs won't be there any more, (2) RPMs changed their name without any indication what their previous or new name is, and (3) you'll need new RPMs that you even don't know in advance about and that are not listed as dependencies. Alone the name of the kernel packages and associated kernel modules have changed several times between 9.x and 10.3.
Therefore, this upgrade will probably be a manual experience for you...
Joachim
---- I don't have to worry about kernel modules. I generally run my own vanilla kernel downloaded and built for my machine from kernel.org. Am a bit "behind" now...as I'm still running 2.6.24 on most of my machines, but I'll get to 2.6.25 before too long. I'm aware of modules changing names. It's not to difficult to figure out what's what, but I was wondering if anyone had already written a utility or toolset to do what I've been doing manually as I was developing a tool to automate some of the busy work and was trying to gage how many people might find such tools useful -- that is, tools to do manual updating -- "cherry-picking" from new releases, as it were, with the eventual overall movement being toward a complete update. It *always* has been a manual experience for me -- since suse 7.x. Why shouldn't I hope that linux would evolve up to the current level of Win(XP) or even 1990's "Unix" vendors. Requiring the machine be off line for upgrades is anachronistic. Even installing a new kernel would be done on live machines, with a reboot needed to activate the new kernel. But to require the machine be down for hours while someone manually upgrades it? Its just so...primitive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue, 06 May 2008 11:15:25 -0700, Linda Walsh wrote:
Why shouldn't I hope that linux would evolve up to the current level of Win(XP)
Oh, some WinXP updates *require* you to reboot to continue installation, mostly when updating drivers. BTW, going from 9.3 to 10.3 in an update is something that will very likely fail. It would save you much hassle to backup the configuration files, do a clean install of 10.3 and then reconfigure the system. I wish you luck anyway ;-) Philipp -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (9)
-
Carlos E. R. -
Joachim Schrod -
Joe Morris -
Joe Sloan -
John Andersen -
John M. Anderson -
Linda Walsh -
Philipp Thomas -
Sam Clemens