Sensors not available? [Solved]

[debianix]

Ah I see, so how do you see if a kernel is LTS or not? Would be cool to see that in MXPI..
Also, when you talk about "line of kernels", does that count for liquorix AND Debian AND Debian backports?
The most sensible conclusion for my use case would be to switch exclusively from one kernel version that is declared as LTS to the next kernel version that is declared as LTS?

[debianix]

Have you run the "sensors-detect" script in the terminal? I've had to do this on every machine I've ever installed Linux on, for some reason only a few sensors are detected on installation.

I like to use Psensor for hardware monitoring, you can set alarms for each sensor if you want to. It doesn't let you set fan speeds or anything though.

I did it and this is the outcome:

Code: Select all

# sensors-detect version 3.6.0
# System: Gigabyte Technology Co., Ltd. B560M DS3H V2 [Default string]
# Kernel: 6.1.0-21-amd64 x86_64
# Processor: 11th Gen Intel(R) Core(TM) i7-11700 @ 2.50GHz (6/167/1)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): 
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 17h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Hygon Family 18h thermal sensors...                         No
Intel digital thermal sensor...                             Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): 
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      Yes
Found unknown chip with ID 0x8689
Probing for Super-I/O at 0x4e/0x4f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               No
Trying family `ITE'...                                      No

Some systems (mainly servers) implement IPMI, a set of common interfaces
through which system health data may be retrieved, amongst other things.
We first try to get the information from SMBIOS. If we don't find it
there, we have to read from arbitrary I/O ports to probe for such
interfaces. This is normally safe. Do you want to scan for IPMI
interfaces? (YES/no): 
Probing for `IPMI BMC KCS' at 0xca0...                      No
Probing for `IPMI BMC SMIC' at 0xca8...                     No

Some hardware monitoring chips are accessible through the ISA I/O ports.
We have to write to arbitrary I/O ports to probe them. This is usually
safe though. Yes, you do have ISA I/O ports even if you do not have any
ISA slots! Do you want to scan the ISA I/O ports? (YES/no): 
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM79' at 0x290...       No
Probing for `Winbond W83781D' at 0x290...                   No
Probing for `Winbond W83782D' at 0x290...                   No

Lastly, we can probe the I2C/SMBus adapters for connected hardware
monitoring devices. This is the most risky part, and while it works
reasonably well on most systems, it has been reported to cause trouble
on some systems.
Do you want to probe the I2C/SMBus adapters now? (YES/no): no

Now follows a summary of the probes I have just done.
Just press ENTER to continue: 

Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

To load everything that is needed, add this to /etc/modules:
#----cut here----
# Chip drivers
coretemp
#----cut here----
If you have some drivers built into your kernel, the list above will
contain too many modules. Skip the appropriate ones!

Do you want to add these lines automatically to /etc/modules? (yes/NO)NO

Unloading cpuid... OK

[siamhie]

Ah I see, so how do you see if a kernel is LTS or not? Would be cool to see that in MXPI..

I follow the kernel archives page. (https://www.kernel.org/category/releases.html)
It describes the various stages the kernel goes through. (Prepatch/Mainline, Stable, Longterm...https://www.kernel.org/)

Also, when you talk about "line of kernels", does that count for liquorix AND Debian AND Debian backports?

That is entirely up to the maintainer of said kernels. Be it Distro or Other (Liquorix, Xanmod, etc.) which is mentioned in my second link.

The most sensible conclusion for my use case would be to switch exclusively from one kernel version that is declared as LTS to the next kernel version that is declared as LTS?

No (in most use cases). If you install a new device -that may require a newer kernel to function- you would then try the newer kernel. It could be a WiFi card, Sound card, etc.


Here's an example using my computer I built two years ago. I have a PCI-e WiFi card installed that requires the 5.11+ kernel to work.
If I install MX-21.3 fluxbox (my preferred desktop), it comes with the 5.10 kernel and it's kernel doesn't work. With MX-23 fluxbox it does work because it comes with the newer kernel.



Bottom line is this....If it works, don't break it. Stick with whats works.

[debianix]

FYI...The 6.7.x and 6.8.x line of kernels have reached end of life. Stick with the 6.6.x series as that one is an LTS (or long term supported until 2026) kernel.

After giving a lot of thought to what would be the simplest solution for me, I realized the following:

https://mxlinux.org/download-links/

I've just noticed that the kernels in the "ahs" iso's are on version 6.6 (i.e. the LTS kernel you mentioned). The KDE version is only available as a "basic" version, but with the ahs-repos enabled, so that everyone can then decide for themselves whether they need ahs or not (that's how I understand it).

For me as a user who doesn't want to deal with kernels in depth, but uses relatively "recent" hardware, it would actually be easiest if I simply go directly to MXPI after each installation of MX Linux KDE and install the kernel that is currently being used as the "ahs" kernel for the Xfce flagship version. Because with this procedure I can surely assume that the kernels used for ahs are always LTS kernels, right?

Then I would simply install the "Debian 6.6.11 64-bit (AHS)" entry in MXPI for my MX23.3 KDE installation, test whether everything still works as desired.
And if so, I could check off the kernel issue for now.

Because the way I have gotten to know the MX Linux team and philosophy so far, I assume that the kernel for the official stable releases of MX Linux (normal and ahs) is always chosen in such a way that an inexperienced user can work with it without major security concerns until the next major release is published. I just hope that this is the case :-)

[CharlesV]

Not quite the way it works, but your pretty close.

AHS stands for Advanced Hardware Support and I believe it is geared more for KDE and users with machines that are newer. However, it does provide some of the latest linux-firmware too. You can install XFCE bring it all up to date, then turn on the AHS repo and get more installs, so there are some additional things there.

Kenerls however, are delivered to machines in the regular repos. (Just install the kernel meta package and your on it.) I dont *believe* there is a difference in later kernels in AHS, but honestly I have never checked that as I run AHS to get to the liquorix and other firmware.

[siamhie]

I've just noticed that the kernels in the "ahs" iso's are on version 6.6 (i.e. the LTS kernel you mentioned). The KDE version is only available as a "basic" version, but with the ahs-repos enabled, so that everyone can then decide for themselves whether they need ahs or not (that's how I understand it).

MX-23 users are all on the LTS kernel be it the 6.1.x series or the 6.6.x series. I believe the MX-21 users are on either the 5.10.x (fluxbox) or the 5.15.x (XFCE, KDE) series.

kernel.jpg

[debianix]

MX-23 users are all on the LTS kernel be it the 6.1.x series or the 6.6.x series.

As long as those users dont change anything with the kernels after the fresh installation… thats what u mean, right?

Alright guys I will do it as mentioned in the last post, always enable the ahs LTS kernel version that comes with xfce ahs version in my KDE installation (so right now the debian 6.6 ahs)

Will stick with that behaviour until I face problems with the ahs kernel as my hardware becomes older and the kernels become newer, and one day my hardware will be „old enough“ to use it with the normal debian stable kernel (now 6.1)…. Then one day get new hardware and start from the beginning with ahs kernels :-)
Lets see how this plan works out in reality :-)
Thank u so much for ur support!!!

[siamhie]

MX-23 users are all on the LTS kernel be it the 6.1.x series or the 6.6.x series.

As long as those users dont change anything with the kernels after the fresh installation… thats what u mean, right?

Yes. The kernels will get updates as needed (security, bug fixes, etc).

[Stevo]

6.6 Debian or Liquorix kernels are not getting LTS updates, since it's not the default kernel for a Debian release like 5.10 or 6.1. Liquorix doesn't do LTS period--it's the bleeding edge or nuthin', baby!

I'm backporting the new 6.1.94 Bookworm LTS kernel for MX 21 ahs right now...

We keep the last version of a particular Liquorix kernel in the AHS repos for each major verision, like 6.6's 6.6.12.

[debianix]

Kernels really seem to be a science in themselves.

6.6 Debian or Liquorix kernels are not getting LTS updates, since it's not the default kernel for a Debian release like 5.10 or 6.1.

MX-23 users are all on the LTS kernel be it the 6.1.x series or the 6.6.x series.

As long as those users dont change anything with the kernels after the fresh installation… thats what u mean, right?

Yes. The kernels will get updates as needed (security, bug fixes, etc).

I have read all your contributions multiple times and googled a lot.

I interpret it, that LTS kernels can only be called those that are also used in the official major Debian stable releases, i.e. Debian bookworm: 6.1, Debian bullseye 5.1, Debian buster 4.19... they get really really long support. At some point only with security patches, but at least they will be supported or in any way maintained.

For the 6.6 kernel, which is shipped with "MX-23.3_x64 ahs (Xfce)", the MX team grabbed the 6.6 kernel (maybe because they thought it was a good compromise between 6.1 Debian bookworm and 6.7 Debian testing/trixie) and agreed to provide this 6.6 kernel with updates at least until the next MX major release in order to provide better support for users with newer hardware. In addition to the newer kernel, some of the latest linux-firmware will also be provided as part of the AHS repo?


Let's assume the following practical situation for a moment, in order to express which kind of question is remaining in my head:

I install "MX-23.3_x64 KDE", then I boot the machine, open MXPI , and select "Debian 6.6.11 64bit (AHS)" under "Popular"-->Kernel--> and install it from there directly with MXPI. From then on I always boot from this kernel, and if everything runs smoothly I remove the 6.1 one day so that only the 6.6 remains.

final and most important question for me:
Will this 6.6 kernel version then be equal to the one that comes pre-installed with "MX-23.3_x64 ahs" (Xfce)?
And will this therefore also automatically receive updates (security patches, bugfixes) via apt at least until the new major release appears?
Is this kernel version usable without critical security concerns until the next major release?

here a picture to visualize my question:


If so, and ich that kernel works without problems, I will give it a try and stick with it until MX 23.4 or MX 24 will be released.

If not, I have to rethink if its not better to stick with 6.1 or to read further written elaborations about the whole kernel topic.