staging.inyokaproject.org

ok dann bin ich wohl wieder mit gefählichem halbwissen unterwegs...
was ist denn der unterschied zwischen thinkpad-acpi und smapi?

EDIT:

ich hab das ganze jetzt mal ausprobiert (7.10 kernel 2.6.22).
kernel patchen kompilieren installieren hat alles gut geklappt.
nur leider läd der neue kernel manche module nicht. z.b. das für mein WLAN.

ich vermute ich hab irgendwas mit den links verbockt.
obwohl ich mich genau ans wiki gehalten hab.

diese stelle hier:

Schliesslich müssen mit folgenden vier Befehlen einige Links angepasst werden, die sich noch auf alte Orte beziehen:

sudo rm /lib/modules/<NEUVERSION>/source                                        # Löschen des alten source-Links
sudo rm /lib/modules/<NEUVERSION>/build                                         # Löschen des alten build-Links
sudo ln -s /usr/src/linux-source-<NEUVERSION> /lib/modules/<NEUVERSION>/source  # Erstellen des neuen source-Links
sudo ln -s /usr/src/linux-headers-<NEUVERSION> /lib/modules/<NEUVERSION>/build  # Erstellen des neuen build-Links

Der Kernel ist nun installiert und kann nach einem Neustart gebootet werden.

ist mir vom verständnis auch noch nicht ganz klar.
warum bezieht sich "/lib/modules/<NEUVERSION>/source bzw. build" auf den "alten source-Link bzw. build link"?

könntest du an der stelle vielleicht noch die ein oder andere erläuterung einfügen um was für links es sich da handelt, uzahnd?

Das Problem ist, daß der selbstkompilierte Kernel keine restricted-module lädt. Also auch nicht den Atheros Treiber fürs wLAN. Ich wüsste auch gern, wie man die Module lädt...

Hallo,

ist der Artikel fertig oder besteht noch Klärungsbedarf?

Gruß
noisefloor

Kleine Anmerkung: Das Kompilieren eines Kernels ist eigentlich in einem anderen Artikel bereits erklärt. Sollte man nicht darauf verweisen? So ist jedenfalls einiges doppelt.

ich denke genau bei diesem thema ist es von vorteil wenn der kompilier-vorgang direkt im artikel beschrieben ist, dieses ganze hin und her zwischen wiki-artikel bringt nur verwirrung und ist mMn eine fehlerquelle wenn man das projekt hdaps angeht...

just my 2 cents

Ich denke wir sollten unser Konzept beibehalten. Es gibt kein hin und her zwischen Artikeln, nur Grundlagen und Hintergründe, die man nunmal braucht, wenn man in komplexere Themengebiete vorstoßen will. Ist man dahin einmal gekommen, ist eine doppelte Aufführung von Grundlagen einfach nur nervtötend.

okay, bin wieder da:

- zu den Doppelungen "Kernel kompilieren": Die sind tatsächlich vorhanden, und wenn euch das lieber ist, kürz ich dort ab. Ich find halt Kernel#Kernel-bauen ziemlich anspruchsvoll, v.a. weil dort immer mehrere Eventualitäten mitbedacht werden. Hab in meinem Artikel versucht, den simpelsten Weg aufzuzeigen, damit sich auch weniger Wagemutige an die Sache trauen. Aber eben: ich will euch damit nicht in die Quere kommen. Allerdings hab ich cornix's Votum nicht ganz verstanden: Findest Du nun, ich soll kürzen, weil's sonst nervtötend ist, oder findest Du, ich soll's drin lassen, um ein hin und her zu vermeiden?

- zu den manuell abzuändernden Links (@moron): Ich hab einfach festgestellt, dass die Links falsch waren und dass drum einiges zuerst nicht funktionierte. Frag mich nicht warum; beim nochmaligen Lesen hab ich allerdings festgestellt, dass ich nach dem Auspacken der Kernelquellen nirgendwo angegeben habe, den Sym-Link /usr/src/linux auf die neuen Kernel-Quellen umzustellen. Vielleicht hängts damit zusammen, aber das erübrigt sich ohnehin, falls ich nun noch die ganze Kompilierung mit Verweis auf Kernel#Kernel-bauen rauswerfe.

- zu den restricted modules (@Chinakoch): Ich sag ja im Artikel, dass hier nur die simpelste Variante vorgestellt wird, die von einem unveränderten Ubuntu-Kernel ausgeht. Willst Du restricted modules verwenden, so musst Du sie manuell installieren, wie das in den jeweiligen Artikeln auch beschrieben ist.

Gruss U

Unser Weg ist es in einem Artikel ein Thema ausführlich zu beleuchten, auch wenn es, wie im Fall von "Kernel bauen" dadurch etwas anspruchsvoller wird. Wenn man nun an anderer Stelle ein solches Thema anschneidet, gibts zwei Fälle: einmal der Geek, der "Kernel bauen" schon blind im Schlaf erledigt (für den ist es dann unnütz oder gar nervig es nochmal verknappt zu lesen) und den einfachen Nutzer, der mit der verkürzten Anleitung auch nicht schlauer wird und prompt nach restricted Modules fragt.

Wenn Du meinst, "Kernel patchen" innerhalb des Kernel-Artikels könnte verbessert (vereinfacht oder ergänzt) werden, stimme ich zu.

Hallo,

@uzahnd: ok, dann kürz' den Artikel wo es sinnvoll möglich ist bitte mit Verweis auf "Kernel kompilieren". Das wollte cornix wohl auch sagen... glaube ich.

Wie du vielleicht weißt kann man alte Revisionen eines Artikels wiederherstellen - es geht also nichts verloren, wenn die neue Revision suboptimal sein sollte. ☺

Gruß
noisefloor

also ich finde dass der artikel was das kernel kompilieren angeht definitiv nicht gekürz werden sollte.
es ist eine gute ergänzung zu dem kernel-wiki, was ich im übrigen sehr oberflächlich finde.

wie uzahnd schon sagte haben seine ausführungen gerade für diesen spezialfall allemal ihre daseinsberechtigung.

ich finde es ehrlich gesagt etwas anmassend, sollte sich tatsächlich jemand darüber ärgern, in diesem wiki mit "kleinigkeiten des kernel kompilierens" gelangweilt zu werden.

das aktivieren des HDPS hat nunmal seinen schwerpunkt in patchen und kompilieren des kernels.

cornix wollte nicht anmaßend sein, sondern nur verdeutlichen, warum wir uns hier im Wiki darauf geeinigt haben, das Wissen möglichst modular strukturieren. Deshalb klingeln bei den Wiki-Mods immer die Alarmglocken bei Wiederholungen 😉 siehe Wiki/Referenz. Falls der Grundlagenartikel Kernel kompilieren noch nicht die gewohnte Qualität besitzt, kann dieser gerne überarbeitet werden. Gerade bei komplexeren Themen ist es schwierig sich eine gute allgemeingültige Struktur auszudenken und Hilfe ist dann immer sehr willkommen.

ich hab nun mal eine verkürzte Version erstellt. Vor allem, weil sich an verschiedenen Orten Fragen gerade zu den restricted modules ergeben haben, ist es wohl wirklich sinnvoll, von allen zu erwarten, den Kernel-Artikel durchgearbeitet zu haben. Zudem hab ich einen Tipp dringelassen, den Kernel bloss via oldconfig zu konfigurieren; was die Unschärfen im Patch-Abschnitt des Kernel-Artikels angeht, hab ich auch einfach den hier zu verwendenden Befehl drin gelassen.

Des weiteren mein ich eine brauchbare Formulierung gefunden zu haben, was das Überspringen des tp_smapi-Teils betrifft: weder bevormundend noch allzu ermutigend, die Sache wirklich zu überspringen...

Insofern ist das bisher Angemahnte eingearbeitet und der Artikel bis zu den nächsten Verbesserungsvorschlägen fertig...

Gruss U

Hallo,

@uzahnd: Ist IMHO ok so. ☺

Gruß
noisefloor

uzahnd hat geschrieben:

Insofern ist das bisher Angemahnte eingearbeitet und der Artikel bis zu den nächsten Verbesserungsvorschlägen fertig...

Das Angemerkte ist eingearbeitet, danke.

Gruß,
cornix

cornix hat geschrieben:

Das Angemerkte ist eingearbeitet, danke.

Es fehlt halt einfach eine [ironie]Umgebung[/ironie] 😛

lgU