Help! Just ran the installation DVD but there is no option to 'upgrade'. Looked at the RHEL docs, http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installati on_Guide/ch-guimode-x86.html#id4594292 referenced off the CentOS Release notes but the CentOS installation doesn't offer the 'upgrade'. I use to be able to upgrade by doing a 'yum update'. That doesn't work either. Guess I'm stuck with 5.6 as I an not about to install a new version and have to rebuild all non-rpm packages from scratch. This is worse than Microsoft!!
On Sat, Jul 23, 2011 at 7:41 PM, Thomas Dukes <tdukes at sc.rr.com> wrote:> Help! > > Just ran the installation DVD but there is no option to 'upgrade'. Looked > at > the RHEL docs, > > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installati > on_Guide/ch-guimode-x86.html#id4594292 referenced off the CentOS Release > notes but the CentOS installation doesn't offer the 'upgrade'. > > I use to be able to upgrade by doing a 'yum update'. That doesn't work > either. > > Guess I'm stuck with 5.6 as I an not about to install a new version and > have > to rebuild all non-rpm packages from scratch. This is worse than > Microsoft!! >Red Hat does not support upgrades between major versions (doesn't necessarily mean it's not possible) http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-upgrade-x86.html http://linsec.ca/blog/2011/02/23/my-adventure-upgrading-rhel5-to-rhel6/ Microsoft Windows and Red Hat Linux have a very different release strategies and version numbers. You can read more about the support lifecycle here: https://access.redhat.com/support/policy/updates/errata/ -- Giovanni Tirloni -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20110723/673efa75/attachment-0001.html>
On Sat, 23 Jul 2011, Thomas Dukes wrote:> I use to be able to upgrade by doing a 'yum update'. That doesn't work > either.A low skill user was never able to go from 2.1 to 3, nor 3 to 4, nor 4 to 5, and an a minimally skilled will not be able to go from 5 to 6. This is the policy of the upstream, and a sensible one, because of invasive changes each major release represents. Functionally, each major is a new product. That said, the CentOS wiki has an UNSUPPORTED method for media based 'upgradeany' transitions of the type you mention. It IS UNSUPPORTED, because it can break systems. For that reason, I specifically added warnings to that article, to take and test backups before trying that path> Guess I'm stuck with 5.6 as I an not about to install a new version and have > to rebuild all non-rpm packages from scratch. This is worse than Microsoft!!Much worse -- you could not steal binaries and license keys from CentOS because we give them away for free CentOS ships no non-RPM packaged packages -- look to whoever put those packages on your box without using the packaging system if you feel the need to blame someone -- Russ herrold
On Sat, Jul 23, 2011 at 5:41 PM, Thomas Dukes <tdukes at sc.rr.com> wrote:> Just ran the installation DVD but there is no option to 'upgrade'. Looked at > the RHEL docs, > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installati > on_Guide/ch-guimode-x86.html#id4594292 referenced off the CentOS Release > notes but the CentOS installation doesn't offer the 'upgrade'. > > I use to be able to upgrade by doing a 'yum update'. That doesn't work > either. > > Guess I'm stuck with 5.6 as I an not about to install a new version and have > to rebuild all non-rpm packages from scratch. This is worse than Microsoft!!@Thomas: I'm a "newbie" home user, with CentOS on our Desktops, and Red Hat Linux, before that. I do not believe you understand the philosophy behind CentOS (an Enterprise OS) or RHEL (the upstream distro). This is a distro with a *LONG* life, and without the "latest and greatest", for security and stability reasons. It has always been recommended to do a "Clean Install" when moving from one major version (ie: 5.x) to a newer version (ie: 6.x) and then to Restore your data, from your backup. If you do it in some other fashion, there are apt to be problems, which will probably not be supported on this list. If you break it, you will fix it. There is a lot of information available, on CentOS.org in the Wiki. HowTos, FAQs, etc. If you look there, you will find many things explained clearly. Also, if you search the archives of the mailing list, you will find a ton of information, from a large group of highly knowledgeable users. People who work with CentOS in the Enterprise, all day, every day. Installing non RPM software on an RPM Distro like CentOS is frowned upon. That is the worst way to do it. There are 3rd party Yum repositories, with lots of things that have been packaged for CentOS and you can install them with Yum, once you have the Repository data ready for yum. You probably won't need to rebuild many packages, if any, if you use the 3rd party repositories. GL
On Saturday, July 23, 2011 10:25:56 PM Alexander Dalloz wrote:> Am 24.07.2011 02:00, schrieb Thomas Dukes: > > > When I say non-rpm, I mean source packages I compiled such as zoneminder. > > And even *if* you would be able to upgrade from CentOS 5.x to 6 - > technically and by personal skills - what makes you think that your self > compiled software would not completely fail, just because libraries change?The specific example of zoneminder is particularly insidious. On our zoneminder systems, even point updates to certain libraries has created problems. A good, modern, package of zoneminder in a repo somewhere would save a lot of grief in that particular case. And even having maintained packages before, I'm not sure I would want to touch rolling my own zoneminder package(s).
On Sunday, July 24, 2011 10:20:07 PM Thomas Dukes wrote:> I'll be moving to Ubunto.Never heard of Ubunto....> They have a 3 year window for support on a > distribution unlike CentOS/RHEL.Right; RHEL has a seven year window, four years longer.> They seem to be more user friendly for a > home networking environment.No, they're not. Been there, done that.
On Monday, July 25, 2011 11:22:37 AM R P Herrold wrote:> 1.24 looks 'doable', although perhaps not without some C6 > libraries -- I see it in rawhide, and in F, after F13, as I > recallI managed to get 1.24.x (VM is shut down right now due to VMware update 'things' going on, so can't check specific version) running, but it wasn't pleasant, and required very specific versions of things to get it working on CentOS 5. It does work, but it is touchy if any of its dependencies gets updated. And now there is a newer version than the one I have running..... And the SELinux business is still there (or rather, not there) and that complicates things. This seems to be more true with network cameras than with native v4l devices. With the library version in C6 being more close to what ZM wants, it should be easier to make it work with C6. Haven't tried out C6 on our VMware setup yet; it's ESX 3.5U5, and AFAIK EL6 isn't supported on ESX3.5. But I'm still digging into that, and seeing if vSphere 4 vmware-tools from packages.vmware.com will work on ESX3.5. If ZM just wasn't the most useful CCTV webcam software out there, bar none, I'd probably not even bother. I haven't found anything even close to ZM in terms of functionality in the open-source realm.
On Tuesday, July 26, 2011 01:51:18 AM ????? wrote:> This is roughly what Microsoft used to aim for (somewhere on the road > between XP and 8 they seem to have totally quit the idea, though).As a slightly off-topic aside, there is a youtube video out there about doing just that; the video shows an upgrade chain that goes from Windows 1.0 (no, that's not a typo) up through Windows 7, all as upgrades, along with all the things that have to be changed along the way.... some of the text the guy enters in textboxes is NSFW, however. So you'll have to google for it yourselves; it made Slashdot a few weeks back, so it shouldn't be hard to find. I'm sure that some of these major upgrades *can* be done, but in a land where the package is the unit of OS granularity, and package maintenance practices vary from package to package as to 'upgradeableness,' it really becomes a task, and this is before even considering the upgrade-hostile attitudes of some software projects that upstream ships packaged in upstream EL. While package groups give an illusion of a unit larger than a package, it's just an illusion, really. The collective set of dependencies defines the full distribution, and nothing in the dependency chain requires rigorous, tested, upgrade path implementation. In the case of other commercial vendors doing this, well, those vendors typically have strict and tight control over all the developers working on it, and have enforcement mechanisms in place to ensure that migration paths are implemented. It's called an employment contract, and it's enforced through the ordinary commercial developer chain of command. While open source developers and packagers are technically capable of doing this, some seem to take great delight in making it difficult to be compatible (partly to prevent closed-source programs from continuing to work). And if just one development group becomes the proverbial fly in the ointment, then all the users of that package that need upgrades to 'just work' suffer. And sometimes the developers care, and sometimes they don't. But consider: upstream doesn't employ a 'critical mass' of developers in all of its shipped packages to reliably enforce upgrade provisions, even if it wanted to do so. Beyond that, there are packages supported by upstream that have serious difficulties with major version upgrades, simply because supporting data in place upgrades is not a priority for that development group. I can think of more than one project that seems 'upgrade hostile' but in reality it's just something that's not front burner; they'd rather develop newer features and fix bugs than 'waste' time on a rarely used procedure that is, in some cases, extremely complex and in other cases simply won't work anyway. That is, there are data sets associated with some upstream packages that are impossible to migrate in place to a newer version in a seamless, nondisruptive, fashion. In a nutshell, it becomes a tradeoff of open source freedom versus the upgrade needs of the users. If the needs of the users trump the freedom of the developers, then developer freedom (the freedom to 'scratch ones own itch'), the very essence of open source, goes out the window. To the OP, if your itch is to have seamless in-place upgrades, then scratch that itch (or pay someone what scratching that itch is really worth... but be prepared to come up with six or seven figures). That's going to be a mighty big itch, though..... especially with over 2,500 upstream packages from nearly as many heterogeneous development groups with many more agendas of their own.
On Tuesday, July 26, 2011 10:45:42 AM Les Mikesell wrote:> Keep in mind that the Linux kernel itself makes no concessions to > backwards compatibility and demands that all related modules be > recompiled to match changes.One of my paragraphs originally included a fairly lengthy passage on kernel ABI compatibility, but I trimmed it out, and I 'genericized' to more than just the one project, and put in parentheses the statement 'partly to prevent closed-source programs from continuing to work' as a more generic thing, more than just binary kernel modules. It's most assuredly not just the kernel.