Re: Upgrade SLC5 to SLC6 ?
I would expect that amount of problems depends on what is installed. And how much /etc differs from default. One story if it is, let say, minimal install with dhcp server, another story if it is host filled with all possible software in active use. Anton. On Jul 30, 2013, at 5:58 PM, Paul Robert Marino prmari...@gmail.com wrote: gennerally its possible to upgrade from one minor release to the next but not major releases so 5.1 to say 5.9 is possible but 5.x to 6.x is not. you can attempt it through yum but you will have tons of problems. Fedora you usually can upgrade versions but even Fedora has version cut offs where you have to do a scratch install for example 16 to 17 was one of those cutoffs. On Mon, Jul 29, 2013 at 4:08 AM, Tom H tomh0...@gmail.com wrote: On Thu, Jul 25, 2013 at 12:48 PM, Lamar Owen lo...@pari.edu wrote: On 07/25/2013 01:28 AM, David G.Miller wrote: The problem of upgrading from FC-n to FC-n+1 is basically the same as upgrading EL-n to EL-n+1. No; upgrading ELx to ELx+1 is like upgrading Fn to Fn+k(x), where k(x) is an element of an array of integer constants; x is the starting EL release, so k(3)=3 [RHEL3 was based on what I'm going to call 'Fedora Core 0,' which was the pre-fedora RHL 10 beta; see footnote 1]; k(4)=3, k(5)=6 (or 7, since some F13 packages showed up in EL6), and k(6) will probably be 7 or so. Doing this without going stepwise through the Fedora releases is a challenge. I forget how large of an increment preupgrade can do, but I remember doing it F12 to F13 to F14, and it had issues even going Fn to Fn+1, especially if any part of the massive yum transaction fails for any reason (it leaves the system with a half completed yum transaction that yum-complete-transaction simply won't deal with, and then you have to finish the upgrade manually and manually remove the older packages) I have done this twice on two separate machines, one had issues going from F12 to F13 and the other one had issues going from F13 to F14. The Fn to Fn+1 upgrade path is somewhat expected to work; Fn to Fn+2 probably won't work correctly, especially if major changes are in both releases. In theory, preupgrade can upgrade a system to the latest Fedora release; I assume from a still supported release so it's Fn to Fn+2. I have a colleague who went on his laptop from 12 to 14 and you can find people skipping a release on mailing lists and forums. But they're there because they have a problem. :) Both preupgrade and fedup are the source of quite a few list and forum posts. A more usable upgrade system would be one where you could snapshot a system transparently before an upgrade and fallback to the original in case of failure, like Solaris with its Boot Environment. In the Ubuntu world, this is like taking Ubuntu LTS 6.06 straight to 8.04, or worse. I've done the 6.06 to 8.04 thing, by the way, and have no desire to repeat it. Ubuntu/Canonical support LTS-to-LTS upgrades (6.06 to 8.04 to 10.04 to 12.04) where intermediate versions are skipped (so they must be QAd quite extensively; and companies with support contracts must be on-hand for all phases of the upgrade). I've tested an 8.04 to 10.04 upgrade (as I've tested preupgrade and fedup upgrades) but I've never used Linux upgrades in a live/production setting.
Re: Upgrade SLC5 to SLC6 ?
While that's somewhat true the really concern is unresolvable conflicts between packages during the update also you may experience selinux issues among other things.-- Sent from my HP Pre3On Jul 30, 2013 12:05, Anton Starikov ant.stari...@gmail.com wrote: I would expect that amount of problems depends on what is installed. And how much /etc differs from default. One story if it is, let say, minimal install with dhcp server, another story if it is host filled with all possible software in active use. Anton. On Jul 30, 2013, at 5:58 PM, Paul Robert Marino prmari...@gmail.com wrote: gennerally its possible to upgrade from one minor release to the next but not major releases so 5.1 to say 5.9 is possible but 5.x to 6.x is not. you can attempt it through yum but you will have tons of problems. Fedora you usually can upgrade versions but even Fedora has version cut offs where you have to do a scratch install for example 16 to 17 was one of those cutoffs. On Mon, Jul 29, 2013 at 4:08 AM, Tom H tomh0...@gmail.com wrote: On Thu, Jul 25, 2013 at 12:48 PM, Lamar Owen lo...@pari.edu wrote: On 07/25/2013 01:28 AM, David G.Miller wrote: The problem of upgrading from FC-n to FC-n+1 is basically the same as upgrading EL-n to EL-n+1. No; upgrading ELx to ELx+1 is like upgrading Fn to Fn+k(x), where k(x) is an element of an array of integer constants; x is the starting EL release, so k(3)=3 [RHEL3 was based on what I'm going to call 'Fedora Core 0,' which was the pre-fedora RHL 10 beta; see footnote 1]; k(4)=3, k(5)=6 (or 7, since some F13 packages showed up in EL6), and k(6) will probably be 7 or so. Doing this without going stepwise through the Fedora releases is a challenge. I forget how large of an increment preupgrade can do, but I remember doing it F12 to F13 to F14, and it had issues even going Fn to Fn+1, especially if any part of the massive yum transaction fails for any reason (it leaves the system with a half completed yum transaction that yum-complete-transaction simply won't deal with, and then you have to finish the upgrade manually and manually remove the older packages) I have done this twice on two separate machines, one had issues going from F12 to F13 and the other one had issues going from F13 to F14. The Fn to Fn+1 upgrade path is somewhat expected to work; Fn to Fn+2 probably won't work correctly, especially if major changes are in both releases. In theory, preupgrade can upgrade a system to the latest Fedora release; I assume from a still supported release so it's Fn to Fn+2. I have a colleague who went on his laptop from 12 to 14 and you can find people skipping a release on mailing lists and forums. But they're there because they have a problem. :) Both preupgrade and fedup are the source of quite a few list and forum posts. A more usable upgrade system would be one where you could snapshot a system transparently before an upgrade and fallback to the original in case of failure, like Solaris with its "Boot Environment". In the Ubuntu world, this is like taking Ubuntu LTS 6.06 straight to 8.04, or worse. I've done the 6.06 to 8.04 thing, by the way, and have no desire to repeat it. Ubuntu/Canonical support LTS-to-LTS upgrades (6.06 to 8.04 to 10.04 to 12.04) where intermediate versions are skipped (so they must be QAd quite extensively; and companies with support contracts must be on-hand for all phases of the upgrade). I've tested an 8.04 to 10.04 upgrade (as I've tested preupgrade and fedup upgrades) but I've never used Linux upgrades in a live/production setting.
Re: Upgrade SLC5 to SLC6 ?
On Thu, Jul 25, 2013 at 12:48 PM, Lamar Owen lo...@pari.edu wrote: On 07/25/2013 01:28 AM, David G.Miller wrote: The problem of upgrading from FC-n to FC-n+1 is basically the same as upgrading EL-n to EL-n+1. No; upgrading ELx to ELx+1 is like upgrading Fn to Fn+k(x), where k(x) is an element of an array of integer constants; x is the starting EL release, so k(3)=3 [RHEL3 was based on what I'm going to call 'Fedora Core 0,' which was the pre-fedora RHL 10 beta; see footnote 1]; k(4)=3, k(5)=6 (or 7, since some F13 packages showed up in EL6), and k(6) will probably be 7 or so. Doing this without going stepwise through the Fedora releases is a challenge. I forget how large of an increment preupgrade can do, but I remember doing it F12 to F13 to F14, and it had issues even going Fn to Fn+1, especially if any part of the massive yum transaction fails for any reason (it leaves the system with a half completed yum transaction that yum-complete-transaction simply won't deal with, and then you have to finish the upgrade manually and manually remove the older packages) I have done this twice on two separate machines, one had issues going from F12 to F13 and the other one had issues going from F13 to F14. The Fn to Fn+1 upgrade path is somewhat expected to work; Fn to Fn+2 probably won't work correctly, especially if major changes are in both releases. In theory, preupgrade can upgrade a system to the latest Fedora release; I assume from a still supported release so it's Fn to Fn+2. I have a colleague who went on his laptop from 12 to 14 and you can find people skipping a release on mailing lists and forums. But they're there because they have a problem. :) Both preupgrade and fedup are the source of quite a few list and forum posts. A more usable upgrade system would be one where you could snapshot a system transparently before an upgrade and fallback to the original in case of failure, like Solaris with its Boot Environment. In the Ubuntu world, this is like taking Ubuntu LTS 6.06 straight to 8.04, or worse. I've done the 6.06 to 8.04 thing, by the way, and have no desire to repeat it. Ubuntu/Canonical support LTS-to-LTS upgrades (6.06 to 8.04 to 10.04 to 12.04) where intermediate versions are skipped (so they must be QAd quite extensively; and companies with support contracts must be on-hand for all phases of the upgrade). I've tested an 8.04 to 10.04 upgrade (as I've tested preupgrade and fedup upgrades) but I've never used Linux upgrades in a live/production setting.
Re: Upgrade SLC5 to SLC6 ?
On Thu, Jul 25, 2013 at 8:08 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Thu, Jul 25, 2013 at 5:28 AM, Tom H tomh0...@gmail.com wrote: On Thu, Jul 25, 2013 at 1:28 AM, David G.Miller d...@davenjudy.org wrote: I'm guessing you could back-port FedUp to EL and have a reasonable shot at upgrading EL-n to EL-n+1. I wouldn't want to guarantee that an arbitrarily complex installation will work though and the people who really want to upgrade are those with really complex systems that they don't want to have to re-create from a clean installation. So we end up stuck with the contradiction that simple installations could probably be upgraded but the complex installations that people really want to upgrade can't. If you package and script your configuration, there's no such thing as a complex system. Your faith in the ability of scripting to read human minds seems to be boundless. Mine is far lower. For example, simply updating Subversion from one version to another is irreversible: all the working copies checked out with Subversion 1.4 (from Scientific Linux 4) to Subversion 1.6.11 (the current copy in Scientific Linux 6) get updated when used, and are no longer compatible with the older Subversion 1.4 client. If you have a home directory that will still be used with SL 4 operating systems in the same work environment, it's a *big* problem. Similar problems occur with locally compiled packages that were written to require versions of Python or gcc that are no longer availalbe in the new OS. And you would not *believe* the number of packages I've had to help rebundle in the last 5 years because the authors were unable, or unwilling, to et off Apache 1.3 and I had to help switch their base OS to something still supported. I've been spoilt by working in a large environment with dev, uat, and prod boxes where roll-outs/installs/patches/upgrades are tested extensively before moving to prod and a subversion-type problem would be caught and dealt early on. Anyway, developers cannot maintain backward compatibility on a permanent and eternal basis; it complicates and slows down development and testing. I also hear you about legacy stuff. Until two years ago we had a few Solaris 2.5.1 installs (EOLd in 2005 and still have one instance of 2.6 in production, EOLd in 2006) because they were running an application whose developer team didn't want to dedicate any time to upgrade (rewrite?) for a more recent version of Solaris or Linux. It was a headache in more ways than one. Sun makes a bundle when we keep legacy stuff around - and Red Hat will also if we ever keep an older EL around because we won't upgrade to a newer one and mess around to get an application to work on it. In these cases, it all comes down to willingness and ability to pay.
Re: Upgrade SLC5 to SLC6 ?
On Thu, Jul 25, 2013 at 1:28 AM, David G.Miller d...@davenjudy.org wrote:
Tom H tomh0665@... writes:
On Wed, Jul 24, 2013 at 1:25 AM, David G.Miller dave@... wrote:
Jeffrey Anderson jdanderson at ... writes:
The message I get from the official voices in this thread is that there is
no supported method of upgrading major versions, only minor point
versions. It's no big deal. I just did a fresh install, then some
cfengine magic and am back up and running in a couple hours. I was just
surprised because major version upgrades have been available for every
version of SL and TUV for the past 15+ years, and when the install media
did not give me that option here I wanted to make sure I wasn't overlooking
something.
Intriguingly, Fedora now has a semi-official upgrade process called FedUp.
It is very much a work in progress and has been known to fail rather
spectacularly but TUV through Fedora seems to be moving towards eventually
supporting major version upgrades. Or FedUp may never make it out of
Fedora...
Why semi-official?! It's the official replacement of preupgrade and is
the only recommended method to perform a Fedora upgrade given that the
new Anaconda has lost its upgrade capability.
I once mentioned that I'd love to see preupgrade in EL and Nico
pointed out that upgrading a six-month-old installation is far simpler
than upgrading EL-X to EL-X+1 with the large jump in versions between
the latter two.
I say semi=official since it seems that the preferred method is still a
clean install and FedUp seems to have more than a few issues. At least
that's what I read on the Fedora user list.
All upgrades can be problematic whether Fedora or Ubuntu/Debian (where
upgrades are used much more often than in the TUV/Fedora world).
Preupgrade had its share of problems in the past too, perhaps not as
many as fedup has currently but the latter's still a young tool,
relying on new features of systemd, dracut, and anaconda (all three of
which are in heavy development).
It's now the only approved upgrade mechanism and is therefore a
release-blocking piece of the Fedora installation infrastructure: For
each one of the release-blocking package sets ('minimal', and the
package sets for each one of the release-blocking desktops), it must
be possible to successfully complete an upgrade from a fully updated
installation of the previous stable Fedora release with that package
set installed, using all officially recommended upgrade mechanisms.
The upgraded system must meet all release criteria.
So official and somewhat buggy would be more accurate.
The problem of upgrading from FC-n to FC-n+1 is basically the same as
upgrading EL-n to EL-n+1. There tends to be more of them and that means
working out things like dependencies and obsolete packages is even uglier.
You also run into TUV wants an installation of EL that is rock solid. If an
upgraded FC system is unstable, that's almost to be expected. If an
upgraded EL system is unstable, TUV gets bad press.
Exactly. It's far simpler to upgrade six-month-old key
packages/executables/libraries than 2-3-4-year-old key
packages/executables/libraries. So the likelihood of a fedup for EL is
low. Anyway, I don't see how upgrades would be OK'd in some
environments, especially given how quickly and simply a VM can be
killed and installed from scratch.
I'm guessing you could back-port FedUp to EL and have a reasonable shot at
upgrading EL-n to EL-n+1. I wouldn't want to guarantee that an arbitrarily
complex installation will work though and the people who really want to
upgrade are those with really complex systems that they don't want to have
to re-create from a clean installation. So we end up stuck with the
contradiction that simple installations could probably be upgraded but the
complex installations that people really want to upgrade can't.
If you package and script your configuration, there's no such thing as
a complex system.
Re: Upgrade SLC5 to SLC6 ?
On 07/25/2013 01:28 AM, David G.Miller wrote: The problem of upgrading from FC-n to FC-n+1 is basically the same as upgrading EL-n to EL-n+1. No; upgrading ELx to ELx+1 is like upgrading Fn to Fn+k(x), where k(x) is an element of an array of integer constants; x is the starting EL release, so k(3)=3 [RHEL3 was based on what I'm going to call 'Fedora Core 0,' which was the pre-fedora RHL 10 beta; see footnote 1]; k(4)=3, k(5)=6 (or 7, since some F13 packages showed up in EL6), and k(6) will probably be 7 or so. Doing this without going stepwise through the Fedora releases is a challenge. I forget how large of an increment preupgrade can do, but I remember doing it F12 to F13 to F14, and it had issues even going Fn to Fn+1, especially if any part of the massive yum transaction fails for any reason (it leaves the system with a half completed yum transaction that yum-complete-transaction simply won't deal with, and then you have to finish the upgrade manually and manually remove the older packages) I have done this twice on two separate machines, one had issues going from F12 to F13 and the other one had issues going from F13 to F14. The Fn to Fn+1 upgrade path is somewhat expected to work; Fn to Fn+2 probably won't work correctly, especially if major changes are in both releases. To get an EL5 system up to EL6 stepwise with yum, the only semi-sane way would be to upgrade EL5 (FC6 or so based) to F7, then to F8, then to F9, then to F10, then to F11, then to F12, and you might maybe possibly be able to get F12 up to EL6 reasonably easily. That's a k(5) of 6; EL6 to EL7 may be a bit harder, with a k(6) of 7 (assuming EL7 really does get based off of F19). This of course goes through the KDE 3.5 to KDE 4.3 upgrade, so there's a very big difference if you're a KDE user. Having said that, back in the days when I was a user of Aurora SPARC Linux on some Sun Ultra hardware, yum upgrades were the norm, since install media wasn't spun for every release. And it was not a single, simple yum transaction; certain packages had to be upgraded before others, and some had to be parachuted in with rpm. And some things were, well, pretty difficult to deal with on a couple of the increments. In the Ubuntu world, this is like taking Ubuntu LTS 6.06 straight to 8.04, or worse. I've done the 6.06 to 8.04 thing, by the way, and have no desire to repeat it. In the Windows world well, there's actually several Youtube videos of that, and it's hilarious what had to be done to get a Windows 1.0 install upgraded through every step to Windows 7 and 8. And the artifacts left behind. [2][3] Upgrades are hard to do properly, especially in a non-engineered system like a Linux distribution (I know, I know, upstream has engineers working on it and doing integration, but as long as there are packages whose own upstream is outside of TUV's control, it's not an engineered distribution in the strict sense.). (What I want is the 'Redneck' language back for installs) I wouldn't want to guarantee that an arbitrarily complex installation will work though and the people who really want to upgrade are those with really complex systems that they don't want to have to re-create from a clean installation. Heh. Try doing the upgrade with yum alone from EL4 to EL5 (or EL5 to EL6) on a server with an active PostgreSQL database. For that matter, try using the unsupported 'upgradeany' anaconda boot argument and watch your working database go bye-bye. [1] https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Relationship_to_free_and_community_distributions [2] https://www.youtube.com/watch?v=eY-UHdswFkg (note the length! and goes to 8) [3] http://rasteri.blogspot.com/2011/03/chain-of-fools-upgrading-through-every.html (note that the video is somewhat NSFW due to some text that is entered.)
Re: [SCIENTIFIC-LINUX-USERS] Upgrade SLC5 to SLC6 ?
On Tue, Jul 23, 2013 at 9:02 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Jul 23, 2013 at 8:56 PM, Jeffrey Anderson jdander...@lbl.gov wrote: The message I get from the official voices in this thread is that there is no supported method of upgrading major versions, only minor point versions. It's no big deal. I just did a fresh install, then some cfengine magic and am back up and running in a couple hours. I was just surprised because major version upgrades have been available for every version of SL and TUV for the past 15+ years, and when the install media did not give me that option here I wanted to make sure I wasn't overlooking something. I'm glad for you, and startled myself. Our favorite upstream vendor certainly supported doing updates from major OS versions to major OS versoins: you just couldn''t gracefully do it *live, because changing things like major versions of glibc and rpm while you're in the midst of using them to do the update is.. intriguingly problematic. (Tried it once: don't recommend it!) Fedup solves the live problem by performing the upgrade from a custom initramfs. (I've been upgrading to rawhide for a few years by upgrading rpm/yum/python then kernel/glibc then init/udev then everything else but I haven't checked the Fedora wiki for a LONG time to see whether this is still the approved method. They seem to be OTT because every step seems to pull in more and more dependencies with every new Fedora version!)
