On Sat, Dec 29, 2018 at 02:40:41PM -0500, Roberto C. Sánchez wrote: > On the other hand, I have done in-place upgrades of Debian on every > occasion
Ditto. Worked better than they tell on this list to the newcomers. This particular installation I'm writing from began its life as etch back before it was testing. > save one: when I moved my main personal file server from 32-bit > to 64-bit after a hardware swap. Did that one too. > Debian's upgrade process is rather robust. So much so, that people > complaining to Red Hat that Debian managed to provide robust in-place > upgrades since forever For the sake of the completeness, Red Hat provides a way. It involves booting from an install CD/DVD with an "upgrade" option. It's unsupported though. I did it multiple times, end result can be described as 'salvageable'. > while people paying $$$ for RHEL support > contracts were always told, "wipe and reinstall" was at least part of > what moved Red Hat to start providing support for in-place upgrades (at > least as of RHEL7, if I understand correctly). Please do not blame support for that. Those poor (literally) overseas guys and gals have two options then it comes to such things. Option A - do it official Red Hat way (i.e. - reinstall). Option B - suggest a customer to do an unsupported upgrade, and get blamed/fired for all kinds of inevitable trouble afterwards. > The problem that people tend to encounter is when they either don't read > and follow the instructions in the release notes for the new release or > have packages installed from low quality third party sources. Or, in this particular case, follow "good old" configure-make-make_install pattern. > There have been some problematic transitions (e.g., the one involving > udev was a good example) That's a *very* x86-centric POV. For instance, whoever came up with the idea of disabling CONFIG_COMPACTION on armel/kirkwood between jessie and stretch rendered armel ununsable on stretch. And let's do not mention kfreebsd. Reco
