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