On Tue, 1 Oct 2019 at 14:00, MAILIST <mailist at toolz.com> wrote: > > > Your answer has nothing to do with the original question which is related > > to upgrade method and not condition for reinstalling without loosing > > data. > > After 40 years of upgrading many different operating systems, > Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, > AT&T Unix, VAX VMS; I have never observed an upgrade from one major > version to the next to work. The last one I tried using their "upgrade > process" was Ubuntu 18 to 19. Didn't work. > I would mostly agree with the added caveat.. it can be made to work, but you need to do a LOT of work continually to make it happen. Upgrade programs are usually tested for each Unix and Linux in the following manner: For A in Arch; do For B in Hardware-Type; do For X in Oldest_Supported_Major to Youngest_Supported_Major; do For Y from Oldest_Support_Minor to Youngest_Supported_Minor; do Install the OS-X.Y from original media. (maybe) Make changes as listed in manual (if you are lucky) Make known changes which broke major customer last time Run upgrade to OS-N.0 Reboot. If system boots; Pass else Fail; fi Done; Done; Done; Done; Fix all the Fails that you can.. or document that they can't be fixed in tech support. That still probably takes several QA people days of work to go through for an upgrade. Most systems that are lived in quickly fall outside of the scope of what the upgrade tests can find OR what the upgrade program can determine what to do. This is the main reason why you should do a rollout of a new operating system with a plan beyond yum --upgrade-system --YOLO So to make it work, what you normally have to do is continually treat your system like it could be nuked at any moment and you need to rebuild it from whatever is latest. That takes a lot of controls and work which most of us don't have time for. I have seen someone who has incredibly strict rules on their CM upgrade a box from Red Hat Linux 5 to Red Hat Enterprise Linux 5 to show it can be done..[this was a box with databases, website tools, etc etc.. the CM was larger than the database dump] > When a new major version of any o/s is released, I have found it best > to save what application data I can, delete all partitions on the target > boot disk, and then install from scratch. > > I learned years ago to keep application data out of system directories, > ideally on a separate drive that can be mounted on the new installation. > Yes, you do loose your settings, but that's why it would be wise to stick > with the defaults, if possible. Yes, the database is always in a system > directory by default, so that's why you do a dump before the upgrade. > My "cheat-sheet" of things to do during an upgrade is about 10 pages long. > > If you do have to restore from a backup, be sure you do not restore any > system directories (like /etc/fstab). I made this mistake, once! > > System admins must learn to bite the bullet on this part of their job. > > Todd Merriman > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos -- Stephen J Smoogen.