On 9/30/21 5:49 AM, Simon Matter wrote:>> On 9/29/21 3:24 PM, Gesti? Servidors wrote:
>>> Hi,
>>>
>>> I'm doing some tests of upgrading CentOS from 7 to 8 reading
this
>>> step-by-step guide:
>>>
https://netshopisp.medium.com/how-to-upgrade-linux-servecentos-7-to-centos-8-ec2db96a189b
>>>
>>> I'm trying this upgrade in a VM, so I can save
"snapshots" and restart
>>> in a past saved point. However, all my test ends wrong, exacly in
Step 4
>>> when I run "rpm -e `rpm -q kernel`". Then, systems says
that some
>>> packages are kernel dependencies. After I remove that dependencies,
I
>>> can't remove kernel...
>
> One problem which could show up here is that kernel packages have
> changed/splitted and therefore things are more complicated. At least
> that's what has happened in the past, don't know about 7->8.
>
>>
>> That specific step is probably useless.
>> Installing new kernels for Centos8 will sooner or later remove older
>> kernels coming form C7.
>> If you really want to do this manually you could specify the version on
>> your "rpm -e" command.
>>
>> If you are not ready to tweak the process a bit while upgrading and
just
>> expect
>> a straightforward list of commands, well, as others have explained,
there
>> is no guaranteed
>> script or method.
>> If instead you have enough familiarity with the system to work around
the
>> obstacles,
>> "impossible" things can often be done: for example, years ago
I've managed
>> to upgrade
>> a Fedora 16 from i386 to x86_64, and everybody was swearing it was
>> impossible to do.
>
> I can confirm that because I also migrated a server from i386 to x86_64 in
> place. That was with an old RHEL release.
>
> I don't remember exactly how I did it but I think I only used rpm for
it,
> no yum.
>
> Unfortunately upgrading complex systems is still a lot of work these days,
> no matter what all the cloud experts try to tell you :-)
>
> Simon
There is no reason to do an in-place upgrade. It is just too risky.
When you are going to do a major OS upgrade, one huge major issue is
your actual data may not be usable as is on the new system and will
require changes.
This quite frequently happens with databases, either mysqlmMariadb or
postgresql. It happens with php based scripts. It happens iwth major
apache configurations.
It happens to a lesser extent with many other executable program
configurations (samba configurations, for example).
So, while you MIGHT be able to find a proper binary rpm to replace the
actual running programs, the configuration files for all these binaries
from the old system are not going to work and each one most likely will
require individual changes.
If you do an in-place upgrade, none of your services are likely going to
start. That is why in every major upgrade I have ever conducted, I did
so on newer installs while still running the previous version until I
could duplicate everything working on new machine. Once everything is
working and on the new machine and I know HOW and have developed steps
to convert the data and configurations, THEN I convert anything newer
than what i have already running .. and move that over to working system.
This is by far the safest and cleanest way to migrate. It is the only
way I would ever do it with my own data / systems and how I did do it
for many many years as a system administrator.