Hi Steve,

Steve Litt writes:

> Hendrik Boom said on Sun, 17 Oct 2021 11:55:56 -0400
>
>>On Sun, Oct 17, 2021 at 07:56:47AM -0400, . via Dng wrote:
>>> On 10/17/21 07:48, terryc wrote:
>
> [snip]
>
>>> Well, it can't hurt to try another update/upgrade cycle; I had a
>>> konsole open during the last reboot and it was restored, so I can do
>>> command-line things (and what else could I possibly need :-) If that
>>> doesn't fix things up then it's nuke-and-repave time.
>>
>>I've learned it's useful to repeat upgrades and dist-upgrandes and an
>>occasinoal aptitude until nothing happens AND there are no errors
>>reported.
>
> When dealing with non-rolling releases, and maybe even rolling releases
> in certain circumstances, I'm a fan of nuke-and-repave for major
> versions. This is because I'm an elder in the Church of the Known State,
> and a brand new install is an opportunity to achieve a known state. This
> tends to limit the ghosts of versions past.

Catharsis has its place ;-)
Major distro releases are a good time to consider them although I tend
to skip one (or two) because of the work involved starting from scratch
(even with backups to refer back to).

> Obviously, at least one complete, known good and known restorable
> backup must be taken before this. In addition, before this, the results
> of mount, lshw (as root), and whatever package management command gives
> you the packages installed manually, as opposed to those installed only
> as dependencies. If possible, also print the output of mount and lshw.

The stuff I typically back up is everything below /etc, /usr/local,
/home, /opt and /srv. I also check there's nothing left in
/var/spool/*, especially /var/spool/mail (symlinks to /var/mail, btw).
Then I collect the output of

apt-mark showmanual # for the stuff I explicitly installed

and one of

dpkg --get-selections # for what I intended to have installed
apt list --installed # for everything that's installed

As for capturing the output of mount, that should be covered by
/etc/fstab. If none of the hardware changes, then lshw might not
be needed and besides the installer will log a lot more below
/var/log/installer/.

> Then install the new major version, then install all your backed up
> *data*, as opposed to OS or package supplied *programs*, then install
> all the packages on the list of manually installed packages. What I
> generally do is copy the list of packages to a shellscript, convert it
> to package install commands, comment them all out, and then uncomment
> ten at a time to install them. Why ten at a time? So if something goes
> wrong you can find it, and so it doesn't take hours.

My list of manually installed packages is typically not all that long.
On my Xfce4 laptop (which pulls in Recommends:) there are only 120 and
quite a few of them are there to keep packages installed that were
installed by the installer already.

# BTW, I normally just install a console system with the installer and
# add the rest later on an as needed basis. That is, I don't select a
# desktop environment or any "standard" packages in the installer.

After installation, I typically run

apt-mark auto $(dpkg-query -W -f '${Package} ')

to mark *everything* automatically installed and then iterate over the
list of packages that

apt --auto-remove purge

would nuke to arrive at a list of packages I really need/want.

> After that, take a backup of the new system including /etc and
> $HOME, then restore *strategic* config files from /etc/ and ~ and
> ~/.config. By strategic, I mean configs that you hand-crafted.
> Sometimes it's better to copy your hand-crafting into current
> package-installed config files. I find this especially true of Dovecot.

I keep track of /etc with etckeeper which puts that directory under git
version control. That means I can always track back changes to package
updates or me mucking around there and see exactly what changed. That
can be very helpful if an `apt upgrade` broke stuff, more so because I
track "testing" ;-)

> On more thing. When *I* write a program, I never put it in /usr/bin or
> /usr/local/bin or /opt. I have my own directory, called /d/bats (last
> century it was called D:\BATS when I used Windows), to contain all
> executables (including shellscripts and perl/python/ruby/lua/ and the
> like) written by me. You can certainly name that directory differently,
> but it's a directory containing your executables and only your
> executables, so it restores with your personal data, and is not
> molested by anything in the upgrade. Obviously, this directory is on
> the system's executable path.In DOS, Windows, and Linux this segregation
> of executables written by me has served me extremely well. I'd suggest
> you do it too.

Might I suggest $HOME/bin :-)
It's been 20+ years since "last century" ...

If you need these scripts to be usable by other users on your system,
I'd go with /usr/local/bin (which I would backup).

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join