nightrecon at hotmail.com
Wed Apr 27 17:38:53 UTC 2011
Julian Fagir wrote:
>> But, the question is quite clear, though I have no idea why [s]he
>> wants to do that downgrade and might want to explore that before
>> encouraging that move.
> That was what I was looking for, and for what was already done and how the
> system is usually updated (binary, sources) or if it was ever updated, and
> what the system does, i.e. which software is installed.
> And even why it shall be 7.2 or 7.1 and nothing newer.
> Regards, Julian
Language difficulties are problematic by themselves, but most professionals
are not concerned with this as long as the information is there with which
to address the actual problem.
There are several methods for upgrading systems and they essentially break
down into two categories - binary or source. I am fairly unfamiliar with the
binary approaches as I have always used the source-based method. I believe
one caveat with the binary method is it only works with the GENERIC (the
original kernel from the base install) kernel, so if you desire to run
custom kernels the source upgrade process may be a better way to go.
The main point to be aware of is the ABI changes (and potential breakages)
which occur when changing major version numbers, e.g., for example when
going from 7.x version to 8.x version. When doing a source based upgrade
(also known as "the make buildworld kernel installxxx..." dance) from one
major version to the next you will need to rebuild all installed ports
immediately after (and indeed as part of) so that they will then be linked
against the new major versions' libraries.
Mostly this process is driven by the need to upgrade, and there are actually
compatibility shims which allow for running a previous version of an
application (let's say an app limited to run only on 6.x or 7.x) on the
newer operating system version. An example would be to install the
/usrports/misc/compat7x port on an 8.x machine in order to support an app
designed for 7.x. Although this is only an example for illustrative
purposes, it also may _not_ be applicable in your situation as it provides
compatibility shims for 7.3.
So there are any number of available avenues open for you to choose from,
and some reading on the upgrade procedures covered in the Handbook might be
a good way to become more familiar in order to make a more informed decision
on exactly which may be the best for your specific situation.
In addition to all the other upgrade methodologies which might actually
allow for you to do an actual "downgrade" successfully, you may also wish to
consider starting from scratch. I would tend to proceed in this direction if
I was taking over a mess someone else had created. Many times a fresh OS can
be installed, the application installed, and the previous configuration
files and data can simply be copied to the new install. This way you know
everything about the machine you are now responsible for as opposed to never
knowing for sure everything your predecessor may have screwed up.
First thing I do is study the situation and not make any changes to anything
until I've figured out exactly what I need to do. Backups of all data is
essential; I always dump everything so I can always recover back to a known
good if something goes terribly wrong. First and foremost question I have is
concerning the statement: "And even why it shall be 7.2 or 7.1 and nothing
newer. "</quote> We really need to understand this completely first. More
details on this may be useful for potentially providing better advice.
PS: I don't like any app which absolutely says it 'requires' a version of an
operating system which may not receive security updates and whose End-of-
Life may expire before I need to stop relying on this application. Whenever
I've seen this in the past it has most often been associated with bad and
defective coding by whoever wrote the app, and nursing it along only pushed
off into the future actually dealing with the problem of a broken app.
More information about the freebsd-questions