Debian Lüftersteuerung und weiteres .. Thinkpad T430
- Ersteller DD95F
- Erstellt am
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:
Ist jetzt nicht so, dass ein riesen Aufwand damit verbunden wäre.
-acpi-call-dkms- mit apt downoaden > patchen > signieren > dkms_autoinstaller, fertig. Kein fremdes Paket und es läuft.
Man kann es auch ganz gut automatisieren wenn man es möchte.
https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/
-acpi-call-dkms- mit apt downoaden > patchen > signieren > dkms_autoinstaller, fertig. Kein fremdes Paket und es läuft.
Man kann es auch ganz gut automatisieren wenn man es möchte.
https://www.cyberciti.biz/faq/debian-ubuntu-linux-hook-a-script-command-to-apt-get-upgrade-command/
linrunner
Ubuntuversteher
- Registriert
- 22 Juni 2007
- Beiträge
- 13.074
@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!
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.
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!
Du kannst statt händischem Download auch einfach die 1.1.0-6 aus den Buster Backports nehmen.
Zuletzt bearbeitet:
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
linrunner
Ubuntuversteher
- Registriert
- 22 Juni 2007
- Beiträge
- 13.074
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.
- Registriert
- 20 Apr. 2007
- Beiträge
- 71.952
So, und jetzt bitte wieder einen Gang runterschalten.
Secureboot oder Apparmor sind ein Teil des Puzzles, um ein System besser abzuhärten, die vorhandene Sicherheit zu wahren, Kompromittierungen gar nicht erst zu ermöglichen.
Ich lese mich bezüglich secureboot ein wenig besser ein. Schließlich möchte man die Funktion von secureboot noch besser verstehen
http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
- Registriert
- 20 Apr. 2007
- Beiträge
- 71.952
+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.
Deshalb schrieb ich ja, dass saubere Abhängigkeiten in deiner, bzw. in der Verantwortung deines Maintainers liegen.
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 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.
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
@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:
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/
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.tpacpi-bat [1] schrieb:
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:
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:
Mist ich habe das nach der Anleitung gemacht und es geht nicht :-(
- MOK Key erstellt
- MOK Key ins UEFI (?)
Soweit o.k.
- nur das Modul bekomme ich nicht signiert bzw. gestartet ...
Poste nachher die Befehle bin grade unterwegs.
- - - Beitrag zusammengeführt - - -
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!
:thumbsup:
Damit man es nicht jedesmal manuell signieren und installieren muss, kann man es wunderbar mit DPkg:
ost-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:
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.
Zum Glück ist es nur ein Module - aber ich gebe auf ... Raketenwissenschaft.
Hast Du es versucht ?
Ich verstehe die Anleitung nicht, bzw. ich kann sie nicht umsetzen. Da fehlt mir zu viel Können.
