Hello:

I think grub-customizer probably uses it.
But I have not used that application in more a good long while, when I had another HDD with another version to test.

That said, when/if upgrading, the idea is to clone the system drive, set the box to boot from the clone and only then do any upgrade.
Then, if there are no issues, make an image of that drive to restore back to the system drive.

As this is a BIOS boot (no UEFI stuff) box, any other OS boot issues generated by the OS-prober can be easily fixed there.

If I decide to continue with attempting this upgrade, the system drive will be fully updated and cleaned of left over cruft/orphans before cloning it.

Thanks for reminding me.
Seems it was up to date because during the experiment (see part II, link below) there were no warnings in the terminal printout.

And I accepted all the default options when given the choice.
Not sure that was a good thing as I once had a severe problem with the default Devuan MTA, Exim4 by doing just that.
ie: accept default suggestions when updating/upgrading. 

TL;DR: I removed/purged it and in its place installed a lightweight and much better maintained one called procmail.
After all, I was only needing a local MTA, nothing too elaborate.

Just works and in three years' use it has never given me any grief, to the extent that I had to actually look up the package name.  8^°

Thanks for your input.

Best,

A.

Note: I will mark this as SOLVED to this thread will continue in part II here.

Hello:

Hmm ...
Not really.
Have a look here.

That is a WiCD package only by name.
It is a transitional package that works as a front end to install any one of its listed dependencies:
ie: network-manager-gnome | network-manager | connman-gtk | cmst | connman-ui

From the README.Devuan file:

* underline is mine.

Thanks for your input.

Best,

A.

Hello:

Thank you very much.
I'll have a look at all that.

Best,

A.

Hello:

I see.

FF 115.8.0esr (64-bit) on Devuan Beowulf here.

Don't think so.

My friendly local telco providing me with a landline since 1986 along with a pricey albeit low quality ADSL for the past five years decided manu militari to make good on their advertised improvements and deactivated it. With no previous notice.

I am now a 2.0 USB WiFi dongle, legitimately loaned by a neighbour two doors down the hallway so it is not that, the IP is always 192.168.1.29 and an old tin can antenna makes for a very decent 85/90% signal. A good temporary arrangement till the telco AHS deign themselves to come and see about a installing fibre connection.

But this also happened when my ADSL was working through a Pi-hole/Unbound rig running on a Chimaera VM inside my box, the IP also always 192.168.1.2 and the DNS 192.168.1.5. Worked quite well.

I think that the login credential is on a Dev1 cookie and probably has an expiration date.
eg: at this moment I have two Dev1 cookies in my browser but they show no expiration time/date which I recall could be seen in older browsers (long time ago).

Maybe if I change the setting from Allow for Session to Allow this will stop happening?
I always set any and all browsers I use to clear all history on shutdown.

Thanks for your input.

Best,

A.

Hello:

Always done that.
I started with Devuan Jesse in this box and from then on up to Beowulf (now with a backported kernel) was like that.
I opted out of Chimaera because of WiCD and SLiM, this last one having been revived.

But the 'Debian Way' ® is not what it was, between the bloat, the infamous usr/merge and who knows what else is lurking around there, I am rather wary.
Who knows what sending it may bring about.

I will probably clone my system 120Gb SSD drive to an empty 300Gb SAS I have in the slots.
Boot from there and see what happens when I send it and reboot.
Cannot wait to see my dmesg printout. 8^D

That said, I have noticed that what I see as the most important part of my screed has not gathered the much attention.
ie:

Thanks a lot for your input.

Best,

A.

Hello:

I assume you are using Nvidia drivers.
If so, RandR may/will not work along with Xinerama.

I use a pair of FX580 cards for three 19" monitors with the (now unsupported) Nvidia 340.108 drivers and an xorg.conf file I managed to put together after a very long trial and error process, obviously with Xinerama enabled.

At one point, on every boot my /var/log/Xorg.0.log file reads:

~$ cat /var/log/Xorg.0.log
--- snip ---
[    91.365] (WW) NVIDIA: The Composite and Xinerama extensions are both enabled, which
[    91.365] (WW) NVIDIA: is an unsupported configuration.  The driver will continue
[    91.365] (WW) NVIDIA: to load, but may behave strangely.
[    91.365] (WW) NVIDIA: Xinerama is enabled, so RandR has likely been disabled by the    # <----  !!!
[    91.365] (WW) NVIDIA: X server.
--- snip ---

I believe this is applicable to all Nvidia drivers (unsupported or not) but I am absolutely not sure about that.

That said, I have recently seen that the nouveau driver works quite well (daedalus-live desktop *.iso).

You may want to consider trying out the live daedalus *.iso and see for yourself.
I was quite surprised to see how well it worked and how easily I could make the monitors behave as I wanted.

Best,

A.

Hello:

Of course, you have not given me any reason to do so.

I can relate to that.
The coffee roasting software I use runs in my 32bit Asus 1000HE under Devuan Chimaera.
It is the last 32bit version (1.1 / ca. 2017) made available by the author works perfectly well with all the hardware involved.
All versions after that (v2.10) slowly acquired a huge amount of professional roasting machine bloat.

That same machine has an XPSP3 partiiton I use once in a blue moon.
It came in very handy when I needed to flash the last available OS on a Samsung G530M now unsupported by the local telco.
For whatever reason my local XP VM would not run the MS based software I needed to get the job done without screwing up half way through the process.

Yes, I can relate to that too.

Indeed ...
I foresee having bad dreams about that.
There's not really much to choose from if Devuan should fail.
A Devuan based Linux from Scratch may very well be waiting for us in our collective future.

Thanks a lot for your input.

Best,

A.

Hello:

I am afraid that I may not have explained myself properly, again.

The only thing bothering me is the idea that, given the reasons I tried to explain in my OP, an upgrade from Beowulf (with a backported kernel) to Chimaera and eventually Daedalus may not be worth the trouble and may even be counterproductive.

Goes without saying. 8^°

I beg to differ, strongly.
As always, YMMV.

I am not looking for a decision to be made for me.
What I am looking for are opinions/insight to be able to make a better and more informed decision.

I learned a (very) long time ago that new, latest, shiny and full of bling do not necessarily make for a better product.
The IT world (OSs, software and hardware) is up to the brim with examples.

Thanks for your input.

Best,

A.

Hello:

Aye, it is.
None of that UEFI stuff in my box or in my netbook.

I am afraid that I may not have explained myself properly.

The system SDD is just fine, no problems with that.
My issues are with the move from Beowulf to Chimaera and then (eventually) Daedalus.

@aluma
@Andre4freedom
@rolfie

Independent of the method used to make a back-up image of my system drive and for the reasons stated in my OP, the question remains:

Seeing that my hardware has not changed significantly since I first installed Devuan Jesse ca. 2017 and will most probably not change in the coming years, is a dist-upgrade necessary?

All I see around me these days is bloat, bloat and more bloat.
To what benefit?

Thanks in advance.

Best,

A.

Hello:

Indeed ...
That is exactly what I am trying to avoid, as well as a clean install.

As I noted above, I run Beowulf with a backported kernel.

~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ 

I understand that I should not skip Chimaera before upgrading to Daedalus. 

Right.
Note taken.

Thanks for your input.

Best,

A.

Hello:

This is a buggy BIOS problem that crops up with Linux.
My guess is that, although Linux-able, most of these Sun x86 workstations were run Solaris or Windows.

When searching for a solution, I talked to/exchanged data with local ex-Sun employees.
This revealed to me that Sun putting out x86 workstations was seen by most employees at Sun as nothing short of blasphemy.
No one was happy about it, less still to work on the projects.
No wonder the BIOS is crap. 

Not so.
Some BIOS can be fixed/patched and with great success.
Some Apple OS enthusiasts have been doing it for years, unfortunately they have little sympathy for anything/anyone else.

At one time, you could easily load a custom DSDT file at boot time to fix most issues.
Then it became more complicated to load a custom DSDT file.

Even so and after a lot of work, I managed to get rid of all but one or two of the 10/12 warnings the MS based software used to analyse the validity of a DSDT revealed. But I was never able to rid myself of this specific problem.

Maybe, if the problem were only a hardware problem.

And even then, there is no guarantee the used OEM replacement does not suffer from the same glitch.
It will suffer from the same faulty BIOS as it is the latest available.

There is also the possibility of a modern MB but it is an expensive proposition.
It has been done and results seem to have been quite satisfactory but I'll pass on that one.

Everything indicates that the problem I have is the result of a BIOS file smacked together by an apprentice, a cut-and-paste of various snippets from other Award BIOS files.  ie: the type of rubbish that MS will approve for their OS as long as it boots but not something you would expect from Sun Microsystems.

I have yet to confirm that disabling TPM (for which I have no need) will actually solve it, it is just a question of time.

Edit:
Found these two tidbits between my notes from when I was still looking for the cause/pursuing a solution, both from a poster at the ArsTechnica site.

They clearly illustrate the problem.

Thanks for your input.

Best,

A.

Hello:

@aluma:
With my kernel version I get this:

:/boot$ cat config-5.10.0-0.deb10.16-amd64 | grep -i tpm
CONFIG_TCG_TPM=m        #   <-----------------------
CONFIG_HW_RANDOM_TPM=y
CONFIG_TCG_VTPM_PROXY=m
:/boot$ 

So, in 5.10.0-0.deb10.16-amd64 the deed is carried out via modules.
Yet another reason to stay with this version, maybe with chimaera and not beowulf with a backported kernel.

@steve_v
Quite so.

While TPM is compiled in via “CONFIG_TCG_TPM=y”, the TPM hardware listed in /kernel/drivers/char/tpm makes for a rather large laundry list to compile into the kernel but that does not really mean much: the Linux kernel grows larger by the minute.

Q: what does ~$ ls -R /lib/modules/5.10.0-0.deb10.16-amd64/kernel/drivers/char/tpm | grep tpm_ reveal in your box?

Unfortunately, my shutdown problem remains as elusive as ever.
Foolish of me to think I had finally nailed it down ...  8^/

Now, for whatever reason, booting the daedalus live version is not getting me the same results I was getting when I reported it.
Absolutely no idea as to why the failed shutdown happened three/four times in a row and not now.

Spent all morning with it and grew old by the minute, many bad memories from 2015 and all the grief it gave me.

Not running daedalus in my box for the time being so I will stay with my present kernel version with TPM fully disabled in BIOS and blacklisting all its modules as described above to see if the shutdown ever happens again. Eventually upgrade to chimaera which probably does not have the TMP crap compiled in.

If in the course of the next six months it does not rear its ugly head again, then I'll know that TPM was the cause or at least involved.   
Then the trick will be to see about how to deal with it in future kernel versions. 
ie. with the TPM modules compiled in.

It will be that or learn to compile my own kernel from source with just the hardware support needed for my Sun Ultra 24.
I'm sure it will be a great improvement in every respect but first I'll have to learn how to do it.
And then to keep it updated.

No small matter.  8^°

Looking forward, I do not expect to upgrade anything much hardware-wise save for maybe one or two larger capacity SAS drives and maybe a monitor as one of my two Samsung SyncMaster 940m is slowly getting dimmer.
The Dell P1914S is newish/good quality and probably has a few years' use before it starts to act up.

Thank you both for your input.

Best,

A.