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.