The officially official Devuan Forum!

Altoid

Member

Registered: 2017-05-07

Posts: 1,437  

Daedalus 5.0.0 desktop-live shutdown problem

Hello:

I have come across a problem with the Daedalus 5.0 desktop-live *.iso which I expect (have not had time to confirm) would also be present in a regular HDD installation.

Background

Back in 12/2015 I purchased a second hand Sun Ultra 24 in excellent condition to run Linux on.
As it was sort of bare bones, in a few months I was able to fill it up with all the necessary hardware upgrades.
It has served me well.

As I recall, the first distribution I installed on it was Debian 9 and from the very start it exhibited a very annoying start up/shutdown problem which I won't go into to save space.

The gist of it can be seen here in a a 12/2018 contribution to a bug report at bugzilla.kernel.org.

Early on I was convinced that it was a due to a badly written BIOS as it was completely distribution agnostic.
eg: a bare bones TinyCore as well as a full blown Ubuntu suffered it

But the main problem was that it had proven impossible to both trace and reliably reproduce.
Eventually I became used to it and life went on.

Then, after ~ five years silence I received notification of a post at the bugzilla thread.
It seems that it could (?) shed some light on the bug and what was causing it.

TL;DR

Apparently the cause of the problem would reside in how the TPM 1.1/1.2 feature is written into the Ultra 24 BIOS.
I have always had TPM disabled and had no reason to enable it.

Enabling/or disabling it did not make any difference in the short time I tested doing so with my present Beowulf / backported kernel installation.

As I was testing the Daedalus-live *.iso, I discovered that if TPM was enabled, a shutdown failure would occurr every single time.
Disabling it would make the problem go away.

So now, with the Daedalus kernel, this bug can be reliably reproduced.

My Sun Ultra 24 is ca.2007 hardware and the last available BIOS (1.56) is from 01/2011 so I expect that the on-board 1.1/1.2 TPM thing it carries is probably as much a POS as the board's BIOS itself. 

I have the idea (?) that whatever bug within my mainboard's BIOS causes the shutdown failure *may* have been partly worked around in the Devuan Daedalus (kernel v. 6.1.38).

ie: the shutdown problem seems to be solved by disabling TPM in the BIOS.

So that is about it.
This is a rather obscure bug thas was not happening in a lot of hardware out there which is why has gone practically unreported for many years.
Maybe its time has come?  8^°

Unfortunately I won't be upgrading to Daedalus for some time so won't be able to report further till I do.

But feel free to ask for details.

Best,

A.

Last edited by Altoid (2024-03-02 10:12:37)

aluma

Member

Registered: 2022-10-26

Posts: 533  

Re: Daedalus 5.0.0 desktop-live shutdown problem

ie: the shutdown problem seems to be solved by disabling TPM in the BIOS.

Turning off the TPM causes this (Daedalus 5.0 + computer with TPM in the BIOS)
https://dev1galaxy.org/viewtopic.php?pid=45906#p45906
Maybe you should try it on a live image?

P.S. If TPM were in the way, I would, out of pure curiosity, build the kernel without its support.

Last edited by aluma (2024-03-01 17:42:35)

Altoid

Member

Registered: 2017-05-07

Posts: 1,437  

Re: Daedalus 5.0.0 desktop-live shutdown problem

Hello:

Turning off the TPM causes ...

Why am I not at all surprised?

... try it on a live image?

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 ...

If TPM were ...

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:

... build the kernel without its support.

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.

Last edited by Altoid (2024-03-02 09:11:56)

Altoid

Member

Registered: 2017-05-07

Posts: 1,437  

Re: Daedalus 5.0.0 desktop-live shutdown problem

Hello:

... a way to bypass (kernel cmd line?) TPM, enabled or not in the BIOS.

For my box which runs a non-UEFI BIOS boot system, it would seem that (besides disabling TPM in BIOS) blacklisting the TPM modules could be a suitable solution.

I have decided to keep TPM enabled in my box's BIOS to see if the shutdown problem I have had for years goes away and at the same time blacklisted all TPM instances appearing when I look for them with dmesg and lsmod:

~$ sudo dmesg | grep -i tpm
[   23.105655] tpm_tis 00:07: 1.2 TPM (device-id 0xB, rev-id 16)
[   23.123842] tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 750->750000us B 2000->2000000us C 750->750000us D 750->750000us
[   23.156422] tpm tpm0: Operation Timed out
[   23.176797] tpm tpm0: Operation Timed out
[   23.192567] tpm tpm0: Adjusting TPM timeout parameters.
~$ 

~$ lsmod | grep -i tpm
tpm_infineon           16384  0
tpm_tis                16384  0
tpm_tis_core           28672  1 tpm_tis
tpm                    73728  3 tpm_tis,tpm_infineon,tpm_tis_core
rng_core               16384  1 tpm
~$ 

Blacklisting TPM:

~$ cat /etc/modprobe.d/blacklist-tpm.conf
# added 20240302
blacklist tpm_infineon
blacklist tpm
blacklist tpm_tis
blacklist tpm_tis_core
~$ 

A terminal printput of ~$ lsmod | grep tpm will give you a list of the TPM modules loaded at boot time in your machine, if any.

Obviously, the list of modules loaded in your box will depend in its specific hardware but the kernel version running in my box (5.10.127-2~bpo10+1) lists these:

~$ ls -R /lib/modules/5.10.0-0.deb10.16-amd64/kernel/drivers/char/tpm | grep tpm_
tpm_atmel.ko
tpm_crb.ko
tpm_i2c_atmel.ko
tpm_i2c_infineon.ko
tpm_i2c_nuvoton.ko
tpm_infineon.ko
tpm_nsc.ko
tpm_tis.ko
tpm_tis_core.ko
tpm_tis_spi.ko
tpm_vtpm_proxy.ko
tpm_st33zp24.ko
tpm_st33zp24_i2c.ko
~$ 

The result is that I have no TPM modules loaded or bitching about not being able to TPM anything:

~$ lsmod | grep tpm
groucho@devuan:~$ 

~$ sudo dmesg | grep tpm
~$ 

I have not noticed any problems with this but it may be too early to say for sure.

Best,

A.

Last edited by Altoid (2024-03-02 11:06:31)

aluma

Member

Registered: 2022-10-26

Posts: 533  

Re: Daedalus 5.0.0 desktop-live shutdown problem

There is usually a file in the /boot folder, for example, like mine, config-6.1.0-16-amd64.
This is the kernel configuration file when compiled. If you open it and look for TPM, we will find the line “CONFIG_TCG_TPM=y”. Here's an explanation for it
https://www.kernelconfig.io/config_tcg_tpm

Whether the blacklist completely disables it, I don’t know.

steve_v

Member

Registered: 2018-01-11

Posts: 343  

Re: Daedalus 5.0.0 desktop-live shutdown problem

Whether the blacklist completely disables it, I don’t know.

I doubt it.

“CONFIG_TCG_TPM=y”

Indicates TPM support is compiled in, so blacklisting modules will not disable it unless an additional driver (compiled as a module) is also required for this hardware.
Easy enought to test though, just recompile the kernel with that option unset.

Last edited by steve_v (2024-03-02 12:24:13)

---

Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.

Altoid

Member

Registered: 2017-05-07

Posts: 1,437  

Re: Daedalus 5.0.0 desktop-live shutdown problem

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.

Altoid

Member

Registered: 2017-05-07

Posts: 1,437  

Re: Daedalus 5.0.0 desktop-live shutdown problem

Hello:

... TPM support is compiled in ...

It would seem that compiled TPM support was already a thing at least as far back as 2018.

See here.

A chap files a bug because he cannot disable TPM with the tried and true method of blacklisting the relevant modules, which are not only the hardware related ones, only to find out it was not a bug but a feature.

... this is intentional. We changed TPM to be built in because we eventually want to turn on IMA which relies on the TPM.

Had to look up IMA.

The goals of the kernel integrity subsystem are to detect if files have been accidentally or maliciously altered ...
... appraise a file's measurement against a "good" value stored as an extended attribute ...
These goals are complementary to Mandatory Access Control(MAC) protections provided by LSM modules, such as SElinux and Smack ...
... depending on policy, can attempt to protect file integrity.

Depending on policy.
Right.  8^°

You know that the thing about policies is that, just like ...
Nah, let's skip that.  8^°

To get an idea as to what is going on, check and see what happens when I enable TPM in my box and boot Devuan 12 live:

user@debian:~$ sudo dmesg | grep -i tpm
--- snip ---
[    1.388737] tpm_tis 00:07: 1.2 TPM (device-id 0xB, rev-id 16)
[    1.392850] tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 750->750000us B 2000->2000000us C 750->750000us D 750->750000us
[    1.403036] tpm tpm0: Adjusting TPM timeout parameters.
[   25.759688] systemd[1]: systemd 252.22-1~deb12u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)
--- snip ---
user@debian:~$ 

I also looked up TPM2.
It seems that the TPM-2.0 standard does not require that TPM be in a separate chip.
Now it can be baked into the chipset or the processor itself. 

Worse yet, it seems that there are five different types of TPM 2.0 implementations: discrete, integrated, firmware, virtual and software.

See here if you want to enlighten yourself further.
I didn't bother.

Thanks for your input.

Best,

A.

aluma

Member

Registered: 2022-10-26

Posts: 533  

Re: Daedalus 5.0.0 desktop-live shutdown problem

Of course you can be enlightened.

But we, the users, can only adapt to survive.
I turned on the TPM and haven't noticed any obvious effects yet.

Your case is more complicated; no one can fix BIOS errors.
I looked at the service manual for your workstation, at least there is always a radical method - replacing the motherboard, taking into account the current cost of used boards with 775 socket.

Last edited by aluma (2024-03-03 08:26:20)

Altoid

Member

Registered: 2017-05-07

Posts: 1,437  

Re: Daedalus 5.0.0 desktop-live shutdown problem

Hello:

... turned on the TPM and haven't noticed ...

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. 

... no one can fix BIOS errors.

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.

... radical method - replacing the motherboard ...

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.

Of course, ACPI is damn complicated. So vendors tend to skimp. To be "Microsoft ACPI Compliant", a BIOS merely has to support the subset of ACPI which Windows uses. It may not support S2 at all, for example. So earlier machines would not support ACPI well under Linux (though Linux now holds a known "bad-BIOS" list) or BSD.

Sun-Intel systems had legendarily bad firmware. They worked just as much as you needed to get Solaris 10 working, during the time when Solaris was in rapid decline. My experience from Oracle (which had bought Sun at the time) was "The Ultra 24 series is qualified to run Solaris 10 and Windows XP/Vista only" despite me linking them to Sun's pre-Oracle site telling us how the Ultra 24 is "the ideal Linux workstation".

Thanks for your input.

Best,

A.

Last edited by Altoid (2024-03-03 13:03:27)