:: Re: [DNG] Er, Not that way ? .Re: …
Inizio della pagina
Delete this message
Reply to this message
Autore: Steve Litt
Data:  
To: dng
Oggetto: Re: [DNG] Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
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.

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.

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.

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.

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.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques