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.

Hello:

Why am I not at all surprised?

Well ...
That is exactly how I found out where the origin of my eons old problem may be:

... a problem with the Daedalus 5.0 desktop-live *.iso ...

I think that TPM is a POS shoehorned/forced half-cooked on equipment to eventually control how and with which OS it is used.
Think systemd, zeitgeist, and the rest of all that crap.

I have the feeling that sooner than later we will all have to start learning how to roll out our everything, so to speak.
LFS have quire a long headstart on eveyone else.

Having to enable TPM to be able to boot is ourageous.
Who was the AH who came up with that idea?

More important: just who does the fucking PC/server/etc. belong to?

When I get a moment to do it I'll burn a Debian Bookworm-Live and see if it behaves the same way.
If so, it is definitely TPM problem.

I have read that TPM is not precisely a standardised feature.
More like every OEM has their screwed up version of it.
With MS being the only one they want to keep happy to get their approval and a nice shiny sticker for their products.

Hmm ...
Sorry, forgot to take mi pill.

Best,

A.

Edit:

I think there should be a way to bypass (kernel cmd line?) TPM, enabled or not in the BIOS.
Just like security=none, apparmor=0, nmi_watchdog=0, selinux=0  etc.

Hello:

You're welcome.

I see ...
Good to know.

Best,

A.

Hello:

Makes sense ...

chcpu -r
chcpu: This system does not support rescanning of CPUs

... it appears to be a system limitation.

But this ...

chcpu -e 2
chcpu: CPU 2 enable failed: Operation not permitted

... is a "no you cannot do that" reply.

The question is why the difference between live cd and local.

Please post your local and live cd system's printout for this:

~$ cat /proc/cmdline

and this:

~$ cat /sys/devices/system/cpu/cpu1/online 
~$ cat /sys/devices/system/cpu/cpu2/online
~$ cat /sys/devices/system/cpu/cpu3/online

Best,

A.

Hello:

At fist glance, it would seem (to me) that your local config is doing something (?) that the live cd is not doing.
Hence the difference in behaviour.

See here.

You may want to consider following the procedure outlined in the linked page and see what gives.

That said, consider that cpu0 will always be on-line.
Check this and see what you get:

~$ cat /sys/devices/system/cpu/cpu1/online # <- 0 means off-line | 1 means on-line 
~$ cat /sys/devices/system/cpu/cpu2/online
~$ cat /sys/devices/system/cpu/cpu3/online

HTH.

Best,

A.

Hello:

See here for the available libxalan-c packages in Devuan.

I'd be wary of installing packages from outside the official repositories but if all dependencies are properly met, you may not run into any issues.

Best,

A.