I'm on fedora core 8, and I may have a need to upgrade to the latest, v12, because of an issue I'm encountering (described in "some background", below, but my main query is here). Essentially, I'm going to have to either upgrade frin fc8 to fc12 or perform an isolated kernel upgrade from 2.6.23 to 2.6.32 (that may not be without issues).
If I understand the issue I'm having correctly, what will fix it is a kernel ugprade. I've attempted to upgrade the kernel to latest (2.6.31 at the time) but I've run into some problems that will require troubleshooting, and given that I extremely rarely upgrade kernels, it could take me a while (fwiw, I tried the kernel ugprade on a vmware instance, don't know if that can lead to kernel upgrade problems that I otherwise wouldn't have).
So before going down that path, I would like to know:
1. If there are any chances that kernel compatibility with certain userland tools could be broken (once the kernel is correctly booting, that is) given the "large" version jump from 2.6.23 to 2.6.32 (might as well update to latest). For example, would some commands for traffic control (tc) not work anymore?
2. If it actually would be simpler & safer to just upgrade the distribution? (as long as the paths to the various network scripts haven't changed, mostly around interfaces, VLANs, etc)
In terms of keeping the various tools on the machine compatible with the kernel, I am tempted to go with #2. However, how safe is it to jump directly from fedora core 8 to fedora core 12? I guess most upgrades are tested from FC version N to N+1. I would jump 4 versions directly.
For what it's worth, I have an image of the machine running on vmware, so I could attempt the ugprade there first.
Any suggestions as to which path I should take? Isolated kernel upgrade or upgrade the distribution?
Thanks, sting
----------------------------
Big PS: (if you care about the context)
We use a fedora core 8 box as a router, mostly to shape traffic for network simulation purposes. We have many projects (games or games-related, actually) that use real-time network communication, and employ various network models. Via the use of VLANs, we allow for machines anywhere in our studio to hop on this router, at which point we apply selective traffic shaping rules. So, we have a large number of interfaces (due to the large number of VLANs), and in order to shape traffic bidirectionally, we also use the ifb device which adds even more interfaces. So:
- We have lots of interfaces: 52 (26 VLAN interfaces, 26 equivalent ifb interfaces) - We mostly use the token buffer filter (tbf) and netem queueing disciplines - We use the mirroring action to redirect ingress traffic from the regular VLAN interfaces to the IFB devices
Every now and then, when replacing/removing/adding qdiscs on the fly (and I think it only happens when a tbf qdiscs is involved), the kernel locks. No crash, just a lock, seemingly stuck in an endless loop.
There seems to have been some work done on around endless loops in the kernel network scheduler around nov 2006. Kernel 2.6.23 (which I have) was released around sept 2007. Maybe it takes that long to promote some changes from dev to release. Hopefully that's what I'm hitting. And hopefully by doing a kernel upgrade it will go away.
sting writes:
I'm on fedora core 8, and I may have a need to upgrade to the latest, v12, because of an issue I'm encountering (described in "some background", below, but my main query is here). Essentially, I'm going to have to either upgrade frin fc8 to fc12 or perform an isolated kernel upgrade from 2.6.23 to 2.6.32 (that may not be without issues).
Given a choice between trying to built the current kernel and cram it into such an old distro, versus updating Fedora 8 to Fedora 12, I would choose an upgrade to Fedora 12, without hesitating.
- If there are any chances that kernel compatibility with certain
userland tools could be broken (once the kernel is correctly booting, that is) given the "large" version jump from 2.6.23 to 2.6.32 (might as well update to latest). For example, would some commands for traffic control (tc) not work anymore?
Historically, both the Linux kernel and glibc have a very good track record for backwards compatibility. However, upgrading the entire distro will, of course, end up upgrading your tc binary. Whether or not the tc binary in Fedora 12 is backwards compatible, in all respects, with tc in Fedora 8 is something that I do not know. You can grab the man page for tc in Fedora 12, compare it with what you have in Fedora 8, and draw your own conclusions.
- If it actually would be simpler & safer to just upgrade the
distribution? (as long as the paths to the various network scripts haven't changed, mostly around interfaces, VLANs, etc)
I'm fairly sure that some of these things have changed. And I'm also quite sure that dealing with that is much easier than dealing with building your own kernel and cramming it into an older distro.
In terms of keeping the various tools on the machine compatible with the kernel, I am tempted to go with #2. However, how safe is it to jump directly from fedora core 8 to fedora core 12? I guess most upgrades are tested from FC version N to N+1. I would jump 4 versions directly.
Correct. Such upgrade paths are not tested by anyone. I have, previously, upgraded from N to N+2 without any issues. I just did it again, upgrading from F10 to F12 (because I could not upgrade to F11 due to a bug in F11's anaconda).
Your probability of success depends solely on how well you've cared for your existing F8 system. If you did not mess with it, if you only installed software using RPM, and used the system's configuration tools, where available, or kept manual editing of various config files to a minimum, you shouldn't have any problems. On the other hand, if you hand-compiled a bunch of stuff; if you routinely grabbed various random tarballs, and went the configure/make/make-install route, spraying untracked files and dependencies all over the filesystem, rather than building proper RPMs, you'll likely to have a major mess on your hands after an upgrade.
I do recall that, some time ago, there was a major upgrade to the RPM database format -- a switch to a new major version of the DB back end. Anaconda, on the upgrade path, took care of converting the old format to the new one.
I think that happened before F8, but you need to double check. If this happened in F9, I would suggest piecemeal updates. I'm sure you will still easily find F9 images to download and install, the after updating to F9 (presuming that's the release that switched to the new RPM DB format), jump to F12.
In either case, after updating to F12, you will need to run 'updatedb', then use 'locate' to find all 'rpmsave' and 'rpmnew' configuration files the upgrade process introduced, then manually reconcile them with the active configuration files. That should be the extent of the manual effort involved in upgrading to F12 from an older version.
On Sun, Dec 06, 2009 at 23:05:06 -0500, Sam Varshavchik mrsam@courier-mta.com wrote:
I think that happened before F8, but you need to double check. If this happened in F9, I would suggest piecemeal updates. I'm sure you will still easily find F9 images to download and install, the after updating to F9 (presuming that's the release that switched to the new RPM DB format), jump to F12.
He isn't going to be able to go directly from F8 to F12 without a lot of futzing around. A fresh install might be less work.