Debian Lüftersteuerung und weiteres .. Thinkpad T430

DD95F

New member
Themenstarter
Registriert
21 Sep. 2020
Beiträge
20
Hallo zusammen,

zu meinem Lifebook E736 Notebook das ohne weiteres mit Debian läuft, habe ich mir für kleines Geld ein T430 für unterwegs gekauft.
Allerdings macht mir das Notebook einige Schwierigkeiten. Ich zähl mal die Dinge auf, die mir bisher aufgefallen sind.

- Lüfter dreht ständig über 35xx upm (thinkfan installiert) Was genau muss noch konfiguriert werden ? Die thinkfan.conf habe ich nach /etc kopiert.

- Akku springt von 40% auf 6% (Akku ist neu und auch kalibriert) Defekt oder ein Bug ?

- Turboboost mit TLP deaktiviert, geht trotzdem ständig über 2600 Mhz (3100 Mhz)

- Bios (2.82) lässt keine Legacy/Bios Installation zu. Verstehe ich nicht.

- Hohe Temperatur unter Last (~78°C) - WLP erneuern ?


Sollte mir noch weiteres auffallen, dann frage ich nochmal.

Debian 10 Buster- Thinkpad T430 - Intel i5 3320m
 
Zuletzt bearbeitet:
Wozu bitte patchen? In meinem oben geposteten FAQ-Link steht bereits, welches -dkms Paket aus den Debian Repos benötigt wird. Händisch herunterladen und installieren. Fertig.
 
Wozu bitte patchen? In meinem oben geposteten FAQ-Link steht bereits, welches -dkms Paket aus den Debian Repos benötigt wird. Händisch herunterladen und installieren. Fertig.
Händisch herunterladen und installieren ist Käse!
Der Sinn einer Paketverwaltung mit Abhängigkeitsauflösung ist es, dass jedes Paket die von ihm benötigten Abhängigkeiten selbstständig definiert.

Wenn dein Paket ein bestimmtes anderes Paket als Abhängigkeit voraussetzt um ordentlich zu funktionieren, dann definiere im debian/control deines Pakets diese Abhängigkeit, falls nötig mit Versionsnummer!
Momentan ist "acpi-call-dkms" nicht mal eine Abhängigkeit (Depends) von "tlp", sondern lediglich ein Vorschlag (Suggests). Sowas macht man, wenn es um unwesentliche Rand-Features geht, aber nicht wenn es um essenzielle Funktionen geht oder davon die Lauffähigkeit des Pakets abhängt.
Und selbst wenn es nur ein Vorschlag sein soll, dann muss der trotzdem die passende Version enthalten, falls das eine Rolle spielt.

Sauberer Paketbau liegt in deiner Verantwortung (bzw. in der deines Paketbetreuers)! Sich passende Versionsnummern zusammenzusuchen ist nicht Aufgabe des Endnutzers. Wenn du dir das nicht aufladen willst, dann bleib bei deinem PPA, aber kipp deine kaputten Pakete nicht ins offizielle Debian-Repo!
 
Zuletzt bearbeitet:
@hikaru: offensichtlich hast Dir nicht die Mühe gemacht, deine Behauptungen zu prüfen:

1. Bin ich nicht der Maintainer der Pakete tlp und acpi-call in Debian (oder irgendeiner anderen Distri)
2. Wird acpi-call-dkms nicht auf jedem Laptop benötigt, daher ist eine stärkere Abhängigkeit als "suggests:" nicht sinnvoll
3. Wird das hier vorliegende Problem nicht durch das Paket tlp erzeugt, sondern der Backports Kernel benötigt ein neueres acpi-call-dkms (das nicht in Debian stable enthalten ist)
4. Ich empfehle normalerweise nicht den Download einzelner Pakete, bei acpi-call-dkms ist das aber aufgrund der tatsächlichen Abhängigkeiten völlig unproblematisch

Ich kann im übrigen keinerlei substanzielle Open Source Beiträge von dir erkennen, die deine Arroganz irgendwie rechtfertigen könnten.

Daher: halt einfach mal deine unverschämte Klappe, wenn Du keine Ahnung vom Thema hast!

Man kann es auch ganz gut automatisieren wenn man es möchte.
https://www.cyberciti.biz/faq/debian...grade-command/
Das ist keine Lösung für die vorliegende Aufgabenstellung.

Du kannst statt händischem Download auch einfach die 1.1.0-6 aus den Buster Backports nehmen.
 
Zuletzt bearbeitet:
Du kannst statt händischem Download auch einfach die 1.1.0-6 aus den Buster Backports nehmen.
Ja, acpi-call-dkms aus den Backports nehmen, signieren und neu installieren. Mit modprobe kann man das Modul auch sofort laden.

So, bin jetzt mit dem Thinkpad soweit zufrieden. Vielen Dank für eure Hilfe :)
 
a, acpi-call-dkms aus den Backports nehmen, signieren und neu installieren.
Ah, ok. Jetzt hab ich erst verstanden, was Du mit automatisieren meintest. Es muss ja bei jedem Kernelupdate neu signiert werden.

Ich meine, dass z.B. Ubuntu das von Haus aus macht, bei Debian und Secure Boot bin ich aber nicht auf Ballhöhe. Secure Boot ist bei mir aus.
 
Apparmor sind ein Teil des Puzzles, um ein System besser abzuhärten, die vorhandene Sicherheit zu wahren, Kompromittierungen gar nicht erst zu ermöglichen.
+1
Man muss sich aber Zeit nehmen, um Apparmor ggf. in einzelnen Einschränkungen anzupassen, damit die essentielle Funktionen nicht blockiert werden.
 
+1
Man muss sich aber Zeit nehmen, um Apparmor ggf. in einzelnen Einschränkungen anzupassen, damit die essentielle Funktionen nicht blockiert werden.

Oh ja, kann ich ein Lied von singen.
Einige Wochen habe ich mich damit beschäftigt, Fehlermeldungen zu beseitigen indem ich AA-Profile geändert bzw. neue angelegt habe. Und ja, soviel Live-Schutz wie nur möglich wollte ich ebenfalls gerne am laufen haben. Es läuft zwar zu meiner Zufriedenheit gut, meldet bzw. blockiert zuverlässig z.B. das Netz wenn Änderungen am laufenden System aufgetreten sind, aber sicherlich war das ganze nur die Basis, was man eigentlich mit Apparmor noch so alles realisieren könnte. Wie Du schon sagtest, man braucht dazu sehr viel Zeit und vor allem Lust und Verständnis.

 
@hikaru: offensichtlich hast Dir nicht die Mühe gemacht, deine Behauptungen zu prüfen:

1. Bin ich nicht der Maintainer der Pakete tlp und acpi-call in Debian (oder irgendeiner anderen Distri)
Deshalb schrieb ich ja, dass saubere Abhängigkeiten in deiner, bzw. in der Verantwortung deines Maintainers liegen.

2. Wird acpi-call-dkms nicht auf jedem Laptop benötigt, daher ist eine stärkere Abhängigkeit als "suggests:" nicht sinnvoll
3. Wird das hier vorliegende Problem nicht durch das Paket tlp erzeugt, sondern der Backports Kernel benötigt ein neueres acpi-call-dkms (das nicht in Debian stable enthalten ist)
Das mag sein, aber auch ein Suggests sollte sauber definiert sein. Das ist hier offensichtlich nicht der Fall, wenn bei tlp aus bpo die Versionsnummer von acpi-call-dkms nicht egal ist. Ob dann der Kernel das eigentliche Paket ist, welches ein neueres acpi-call-dkms braucht oder tlp ist unerheblich, denn tlp ist der Installationsgrund und tlp aus bpo sollte dann auch das bpo-Paket empfehlen.

Ich kann im übrigen keinerlei substanzielle Open Source Beiträge von dir erkennen, die deine Arroganz irgendwie rechtfertigen könnten.
Ich habe auch keine substanziellen OS-Beiträge und die unsubstanziellen Beiträge die ich habe, hänge ich nicht an die große Glocke.
Ohne dir zu nahe treten zu wollen, halte ich aber auch tlp nicht für einen substanziellen Beitrag. Ich sehe es als nette Spielerei und als solche durchaus respektwürdig, aber ich würde mich deshalb nicht über andere erheben.

Daher: halt einfach mal deine unverschämte Klappe, wenn Du keine Ahnung vom Thema hast!
Trägst du mir noch unsere Diskussion von vor ein paar Jahren nach, oder warum reagierst du so allergisch? Rückblickend hätte ich mir den Abschlusssatz meines letzten Beitrags sicher sparen können. Insofern bitte ich um Verzeihung, falls ich dir damit zu nahe getreten sein sollte, aber die händische Installation eines Pakets aus einem anderen Release-Zweig ist ein gutes Rezept, eine Debian-Installation kaputt zu machen [1] und sollte daher nicht leichtfertig empfohlen werden - insbesondere wenn es mit dem sauberen Verwenden der Backports vermieden werden kann. Ich traue dir zu das zu wissen, daher hielt ich deutliche Kritik an deiner Empfehlung für gerechtfertigt.


[1] https://wiki.debian.org/DontBreakDebian
 
@hikaru:

der Backport Kernel braucht das neue acpi-call-dkms, tlp dagegen nicht.
 
@mcb:
Der Backports-Kerrnel braucht acpi-call-dkms nicht. Der läuft hier problemlos auf diversen Rechnern ohne das Paket. tlp braucht allerdings acpi-call-dkms für bestimmte Funktionalitäten:
tpacpi-bat [1] schrieb:
# Makes ACPI calls using the acpi_call kernel module, which is REQUIRED.
Diese Funktionaliäten sind für tlp nicht essenziell, deshalb ist acpi-call-dkms nur ein "Suggests" von tlp.

acpi-call-dkms aus Buster (ohne Backports) funktioniert offenbar nicht mit dem Backports-Kernel. Die Gründe sind mir nicht bekannt.
Der springende Punkt ist, dass tlp der Installationsgrund für acpi-call-dkms ist. Daher hat sich tlp darum zu kümmern, dass die passende Version von acpi-call-dkms installiert wird. Die einfachste Möglichkeit wäre, dass tlp aus den Backports auch explizit acpi-call-dkms aus den Backports anfordert, indem es eine minimale Version anfordert, die höher als die in Buster ist.


[1] https://sources.debian.org/src/tlp/1.3.1-2~bpo10+1/tpacpi-bat/
 
@mcb:
Der Backports-Kerrnel braucht acpi-call-dkms nicht. Der läuft hier problemlos auf diversen Rechnern ohne das Paket. tlp braucht allerdings acpi-call-dkms für bestimmte Funktionalitäten:

Diese Funktionaliäten sind für tlp nicht essenziell, deshalb ist acpi-call-dkms nur ein "Suggests" von tlp.

acpi-call-dkms aus Buster (ohne Backports) funktioniert offenbar nicht mit dem Backports-Kernel. Die Gründe sind mir nicht bekannt.
Der springende Punkt ist, dass tlp der Installationsgrund für acpi-call-dkms ist. Daher hat sich tlp darum zu kümmern, dass die passende Version von acpi-call-dkms installiert wird. Die einfachste Möglichkeit wäre, dass tlp aus den Backports auch explizit acpi-call-dkms aus den Backports anfordert, indem es eine minimale Version anfordert, die höher als die in Buster ist.


[1] https://sources.debian.org/src/tlp/1.3.1-2~bpo10+1/tpacpi-bat/


Ja das stimmt - bin ja auch schon selbst drauf reingefallen (minor problem) ...

// Edit: Die ältere tlp Version mit backport kernel braucht wohl auch das neue Modul aus den backports <-> also hängt es letztlich am Kernel ...
 
Zuletzt bearbeitet:
acpi-call-dkms aus Buster (ohne Backports) funktioniert offenbar nicht mit dem Backports-Kernel. Die Gründe sind mir nicht bekannt.

Der Unterschied zwischen Buster & Backport acpi-call-dkms ist minimal

Ab Kernel 5.6 haben sich nur einige Parameter geändert.

https://github.com/nix-community/acpi_call/commit/e34e3b82633bd94347b71fe6735041275ec97b8a

Ausserdem hat sich noch die Reihenfolge von #include (wichtig) und Datentyp/Pfad geändert.

#include asm/uaccess.h
#include asm/acpi.h

geändert in

#include linux/acpi.h
#include linux/uaccess.h
 
Zuletzt bearbeitet:
Ja klar. https://wiki.debian.org/SecureBoot
Ist recht easy das Ganze.

Solltest Du es doch aus den Quellen bauen müssen, dann muss acpi_call.c gepatcht werden. Patch kann ich dir auch zusenden.


ps .. Wenn ich was hier rein kopiere, dann gibt es nur ein großes durcheinander. Wie kann ich es verhindern ?


Mist ich habe das nach der Anleitung gemacht und es geht nicht :-(

- MOK Key erstellt
- MOK Key ins UEFI (?)

Soweit o.k. :cool:

- nur das Modul bekomme ich nicht signiert bzw. gestartet ...

Poste nachher die Befehle bin grade unterwegs.

- - - Beitrag zusammengeführt - - -

:eek: Ich habe es hinbekommen !!!

Top. Die Debian Anleitung ist gut. Also vielen Dank für den Hinweis.

Code:
root@mb:~# tlp-stat -b
--- TLP 1.3.1 --------------------------------------------

+++ Battery Features: Charge Thresholds and Recalibrate
natacpi    = active (data, thresholds)
tpacpi-bat = active (recalibrate)
tp-smapi   = inactive (ThinkPad not supported)

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer                   = SMP
/sys/class/power_supply/BAT0/model_name                     = 02DL014
/sys/class/power_supply/BAT0/cycle_count                    =     13
/sys/class/power_supply/BAT0/energy_full_design             =  57020 [mWh]
/sys/class/power_supply/BAT0/energy_full                    =  57020 [mWh]
/sys/class/power_supply/BAT0/energy_now                     =  43550 [mWh]
/sys/class/power_supply/BAT0/power_now                      =      0 [mW]
/sys/class/power_supply/BAT0/status                         = Unknown

/sys/class/power_supply/BAT0/charge_start_threshold         =     45 [%]
/sys/class/power_supply/BAT0/charge_stop_threshold          =    100 [%]
tpacpi-bat.BAT0.forceDischarge                              =      0

Charge                                                      =   76.4 [%]
Capacity                                                    =  100.0 [%]

root@mb:~# mokutil --sb-state
SecureBoot enabled
root@mb:~#

Vielen Dank!
 
:eek: Ich habe es hinbekommen !!!
:thumbsup:

Damit man es nicht jedesmal manuell signieren und installieren muss, kann man es wunderbar mit DPkg::Post-Invoke automatisieren.
Ein Script der eigentlich nur nach dem letzten Kernel schauen soll bzw. ob z.B. modul acpi-call schon signiert wurde. Schließlich will man ja nicht nach jedem Update
-alle Module wieder neu siginieren und installieren :)

Hier schon mal eine erste Anlaufstelle

https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/
 
:thumbsup:

Damit man es nicht jedesmal manuell signieren und installieren muss, kann man es wunderbar mit DPkg::Post-Invoke automatisieren.
Ein Script der eigentlich nur nach dem letzten Kernel schauen soll bzw. ob z.B. modul acpi-call schon signiert wurde. Schließlich will man ja nicht nach jedem Update
-alle Module wieder neu siginieren und installieren :)

Hier schon mal eine erste Anlaufstelle

https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/


Zum Glück ist es nur ein Module - aber ich gebe auf ... Raketenwissenschaft. :(
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben