2

I recently have migrated from Scientific Linux (SL), a RHEL derivative distro, to Ubuntu LTS. This was necessitated by there being no SL 8, and I have been posting to the SL list (a much more freeform approach than used by Canonical for these lists) my observations on Ubuntu LTS versus SL (both "enterprise" or "stable production" distros -- not enthusiast semi-beta distros). One significant difference was an upgrade from 18.04 LTS to 20.04.1 LTS -- this was done in place, without any requirement to reformat the system drive (assuming that there was adequate storage space, and there was). For a similar major release upgrade on SL, one has to reformat -- thus, I would remove the drive containing SL major release N, install a new drive, install SL major release N+1, and then copy back from the removed disk any non-system directories, such as /opt, /usr/local, and much of /home . This procedure is not needed with an Ubuntu LTS major release upgrade. However, there was a claim made on the SL list that the "Debian philosophy" of upgrade-in-place leaves a system that contains SYSTEM (not non-system) executables that are not the same as would be from a fresh install of the "upgraded" Ubuntu system. That is, the system files of 20.04.1 LTS after upgrade would not be the same as if 20.04.1 were installed on a new drive. Is this correct? Does the Ubuntu (Debian) upgrade-in-place leave system "junk" about? I am not referring to configuration files in, say, /etc that have specific configurations for specific utilities -- I need these to be retained in so far as the functionality is available in the upgraded major release. I have read

Is a clean install better than upgrading?

I am not asking for an opinion -- I am asking for detailed information as to the specifics of the differences between a clean install of LTS major release N versus an upgrade-in-place of LTS major release N-1 to N. I assume that there will be an URL or other documentation to answer this question, in addition to the responses that (hopefully) will be posted.

3
  • I fear you'll only get opinion related, as most of us don't use a pure Ubuntu 18.04 LTS system when we upgrade; we add other packages to it, often from various sources, meaning we're outside of the QA-tested upgrade path. I release-upgraded my current box every 6 months, it has almost nothing outside of Ubuntu repositories installed (some test packages only which became official packages), yet know it contains junk prior prior releases that I won't see on clean QA-test installs of the same release.
    – guiverc
    Dec 25, 2020 at 5:58
  • I'm not aware of any URL/doco - but it won't relate to 3rd party packages which is key to the issue, and a HUGE reason why there is crud left. Testing involves only packages included on ISOs (ie. released packages), which isn't how most people use their machines.. crud from those packages gets noticed in QA-test release-upgrades, but 3rd party packages aren't looked for; they're the responsibility of the end-user & not Ubuntu packagers. This is however opinion.
    – guiverc
    Dec 25, 2020 at 5:59
  • The SL reference was NOT to non-SL-distro packages (NOTE: for SL, one uses supported non-SL repos such as ELrepo and EPEL -- but the contents from these that are needed for SL -- and RHEL for that matter for those who license the binary install for fee -- are incorporated into the LTS distro). For example, I use the Nvidia "proprietary" video/GPU driver that is not part of the base SL distro, but from these other supported addon repos; this proprietary driver -- if allowed as I do -- seems to be part of the base LTS distro (or LTS authorised other supported repo). Dec 25, 2020 at 6:16

1 Answer 1

5

The Debian (dist-upgrade) and Ubuntu (release-upgrade) methods of migrating-to-the-next-release-without-formatting should not leave extraneous files scattered about your filesystem.

Debian has spent 25 years ruthlessly improving package quality, and it's very good. The Debian Archive Admins will reject and delete packages that fail to meet standards or make systems unstable. The standard for deb packages is that the package manager should remove all traces of a package, returning the system to a state similar to before the package was originally installed.

Generally, if you discover "junk" files left behind, that's a bug -- please file a bug report!

Also, if you discover a package that leaves cruft behind, please file a bug report.

There are several exceptions to the expectation of clean removal:

  • Your data in /home, which the package manager will never, ever delete.
  • System configs and settings in /etc. (use --purge to delete these)
  • Temporary files created by running applications, like PID files in /run, lockfiles in /var, and temporary files (mostly) in /tmp. These should be cleaned up by the application upon exit. If not, please file a bug report.
  • Persistent files created or modified by applications, like logfiles or caches in /var. Some will be deleted upon uninstall (caches), others won't (logfiles). If you have manually modified or added your own customizations, the package manager might not remove your file(s).
  • Packages from somewhere that's not in the official Debian Archives or Ubuntu Repositories may-or-may-not meet the standards, and might indeed leave cruft laying about. You likely know better than to install random debs from the big, dirty internet already.
9
  • Thus, if I fully understand what user535733 has posted, the commentary concerning the philosophical differences between the EL and LTS approaches to major release deployments -- that DEB/LTS major release upgrades are not as satisfactory as a clean install (essentially required by SL) is fallacious. A LTS major release production upgrade (e.g., to 20.04.1 LTS, 20.04 not being an allowed production upgrade path from 18.04.x) is the same as a clean install plus "manual" editing of configuration files (e.g., re-deployment of such from an archived disk, as I did in SL major release upgrades). Dec 25, 2020 at 8:15
  • As for the safety of "unknown" packages (.deb in LTS, .rpm in SL), my understanding is that -- short of compromise of the site -- major add-ons, such as VMware Player, VirtualBox, Calibre (that specifically warns against distro versions as these often are obsolete compared to current production), Mozilla, Thunderbird, TeXstudio, and the like, generally are safe. Does LTS have a "warning list" of possibly dangerous .deb files? On the SL Users List, such questions were posed as to specific "packages" with answers from reliable, experienced users (not enthusiast amateurs). Dec 25, 2020 at 8:24
  • Sometimes there are fundamental changes, such as the move to systemd. Or ubuntu's introduction of the netplan.io system of network configuration. An in-place upgrade may maintain the old configuration if it is still supported.
    – Siep
    Dec 25, 2020 at 16:32
  • The same issue arose with systemd on SL. However, there is a "professional" users list on which the matter was discussed, and several correspondents established the morphism -- as possible -- between the previous "method" and systemd, although I do not recall an "automatic" translator. When this sort of thing happens because of "fundamental" changes in Linux, does this forum provide similar assistance, or are there "automatic" tools? In speaking with colleagues who used supported SuSE SLES, SuSE staff assisted with the transformation. Does Canonical -- for paid support -- do the same? Dec 25, 2020 at 19:10
  • "warning list": Don't confuse packages with the sources that provide those packages. All packages in the official Ubuntu Repositories are "safe" and properly built to Debian standards. We don't check (or warn) about any package from any other (non-Ubuntu) source or PPA. Upstreams can recommend using their builds for their own (valid) reasons, but that doesn't mean the Ubuntu builds are junk (they are not), nor does it mean that the upstream builds confirm to Debian standards (some do, some don't).
    – user535733
    Dec 25, 2020 at 20:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.