Knoppix & Debian Standardkernel ?

[rahab]

Hi Forum,

hab hier ein kleines Problem und bräuchte mal ein paar Infos um die Zusammenhänge zu begreifen.
Situation: Habe Knoppix 3.6 per HD-Install auf meinen Acer Aspire 2023 Laptop gepackt. Läuft auch soweit ganz gut, aber es gibt natürlich ein paar Wermutstropfen...
1. ACPI funktioniert nicht, beim Booten bekomme ich eine Fehlermeldung dass kein ACPI-Bios gefunden wird.
2. Um das Treibermodul für mein Centrino Wlan zu kompilieren (ipw2200) brauche ich die Kernel-Header. Da diese scheibar für den mit Knoppix geliefernten Kernel nicht über apt-get zu erhalten sind, dachte ich, ich wechsel direkt auf Version 2.6.8 oder 2.6.9.

Nun hab ich zwar schon ein paar mal einen Custom-Kernel gebacken aber noch nie ein deb-paket daraus erzeugt oder mir gar ein Debian-Standardkernelpaket installiert, daher ein paar Fragen dazu:

1. Was passiert wenn ich ein apt-get install <kernel-x.y.z> durchführe? Überschreibt der den Alten? Was für ein Kernel ist das dann? Vanilla? Pflanzt der sich direkt in meine Lilo-Konfig? Worauf muss ich achten um mir nix zu zerschiessen?

2. Was hat es mit der initrd auf sich ? Wie sinnvoll ist sie und wie kontrolliere ich ob ich eine brauche oder nicht?

3. Funktioniert ein anderer Kernel auch mit der Knoppix-Hardwareerkennung, etc. ? Laut Readme-Datei benutzt Knoppix auch nur einen Standard-Kernel 2.6.7 der via Patch lediglich die Kommandozeilen-Optionen beim Booten um die Knoppix-Cheatcodes erweitert...

Wäre toll wenn mir jemand zu dem Thema ein paar Infos/Links geben könnte...

Danke im Voraus !

[gms]

1. Was passiert wenn ich ein apt-get install <kernel-x.y.z> durchführe? Überschreibt der den Alten? Was für ein Kernel ist das dann? Vanilla? Pflanzt der sich direkt in meine Lilo-Konfig? Worauf muss ich achten um mir nix zu zerschiessen?

Lilo sollte zwar automatisch konfiguriert werden. Verlassen würde ich mich jedoch nie darauf. Ich kontrolliere immer nachher die lilo.conf und rufe auch nochmals lilo auf. Hätte sonst sicher schon mehrmals ein nicht bootfähiges System erhalten.

2. Was hat es mit der initrd auf sich ? Wie sinnvoll ist sie und wie kontrolliere ich ob ich eine brauche oder nicht?

Die initrd ist hauptsächlich für Standardkernel sinnvoll, die auf möglichst vielen Systemen bootbar sein müssen. Ohne die initrd müßen all Treiber, die für den Zugriff auf die Root-Partition notwendig sind, statisch in den Kernel reincompiliert werden.

3. Funktioniert ein anderer Kernel auch mit der Knoppix-Hardwareerkennung, etc. ? Laut Readme-Datei benutzt Knoppix auch nur einen Standard-Kernel 2.6.7 der via Patch lediglich die Kommandozeilen-Optionen beim Booten um die Knoppix-Cheatcodes erweitert...

Dein System ist jetzt nicht mehr Knoppix sondern Debian. Ein großer Teil der Hardwareerkennung wird aber bei beiden durch diverse Pakete wie z.B. Hotplug erledigt.

ACPI funktioniert nicht, beim Booten bekomme ich eine Fehlermeldung dass kein ACPI-Bios gefunden wird.

Überprüfe bitte einmal wie alt dein Bios ist und spiele eventuell ein neues ein.


Und hier noch ein HowTo für die Kernelkompilierung unter Debian:
http://www.falkotimme.com/howtos/debian ... /index.php

[rahab]

Hey gms !

Vielen Dank für die schnelle Antowrt. Hat mich auf jeden Fall weitergebracht.
Den Kernel hab ich erfolgreich kompiliert. Nur leider hab ich ein seltsames Problem:

Der Bootvorgang läuft glatt bis die Hotplugsachen geladen werden. Sobald OHCI1394 geladen ist werden Ein- und Ausgaben völlig Sprunghaft. D.h: Der Cursor blinkt nicht mehr regelmäßig sondern verschwindet für ca. 3-4 Sekunden und in der Zeit kann ich auch keine Tastatureingabe machen. Dann ist er wieder für 1-2 Sekunden da und ich kann kurz was tippen. Dann ist er wieder weg. Das Gleiche gilt für den Mauscursor, etc.

Meiner meinung nach muss es ein Problm mit dem 2.6.9er Kernel sein, denn ich habe zum kompilierne erst mal die Konfig des alten 2.6.7er genommen, bei dem ich solch ein Verhalten nicht hatte. Testweise hab ich dann noch alle Hotplugsachen abgeschaltet und neu kompiliert. Ergebnis ist dasselbe... Hast du da ne Idee ?

Eine Frage hätte ich dann auch noch zum kompilieren:

1. Muss ich alles komplett neu kompilieren wenn ich eine einzige Option in der Kernel-Konfig ändere? Oder kann ich auch ohne ein 'make-kpkg clean' nochmals kompilieren und damit nur die geänderten Optionen einbringen ?

[gms]

ich denke das OHCI1394 module wird nicht vom kernel geladen, sondern vom hotplug package (den linux hotplug scripts).

Du kannst verhindern, daß dieses Module geladen wird, in dem du in /etc/hotplug/blacklist.d/ eine datei mit diesem Modulenamen als Inhalt abspeicherst.

Möglicherweise hast du aber auch discover oder discover1 installiert. Diese haben auch einen blacklist-Mechanismus

Eine Frage hätte ich dann auch noch zum kompilieren:

1. Muss ich alles komplett neu kompilieren wenn ich eine einzige Option in der Kernel-Konfig ändere? Oder kann ich auch ohne ein 'make-kpkg clean' nochmals kompilieren und damit nur die geänderten Optionen einbringen ?

Erfahrene Kernel-Entwickler werden sicherlich die Änderungen abschätzen können und vielleicht nur einzelne Module nachgenerieren. Uns Normal-Sterblichen ist das wahrscheinlich nicht zu empfehlen.

[rahab]

Danke nochmal für deine HIlfe gms !

Leider hab ich das Problem mit dem seltsamen Ein-/Ausgabeverhalten noch nicht gelöst bekommen.

Wie gesagt: Hab die Original-Konfig vom 2.6.7er Kernel verwendet, die in /boot lag. Wenn ich damit kompiliere gibts den genannten Ärger. Es kann aber auch sein dass es das Modul "tg3" ist. Der ohci1394 ist nämlich eigentlich schon vorher geladen und spuckt beim Laden durch die Hotplug-Scripts nur aus "ohci1394 already lodaded". Danach fängt er an zu spinnen und er meldet "tg3 lodaded succesfully". Also kann es auch sein, dass es garnicht ohci1394 ist sondern tg3.
Nun funktioniert das mit der Blacklist aber nicht so ganz, bzw. vielleicht hab ich es nicht ganz kapiert. Die Frage ist nu: Wie kann ich verhindern, dass er beim Booten über die Hotplug-Scripte ein bestimmtes Modul lädt bzw. zum Testen die HOtplug-Scripte generell weglässt ???

[KBDCALLS]

Die Blacklist des Hotplug steht in /etc/hotplug/blacklist, da trögts du dann die Module ein die du nicht haben willst

tg3 zum Beispiel.

Discover hat eine eigene Konfigurationsdatei /etc/discover.conf müßte es sein. Wenn man die den Blacklistmechnismus nutzen will , dann muß
man

Code: Alles auswählen

skip tg3

eintragen.

Aber der Blacklist Mechanismus nutzt nichts solange ein Modul geladen wird welches ein Blacklistet Modul voraussetzt.

[rahab]

Ok danke schonmal,

Ich versuche jetzt mal nach und nach die Module, die Hotplug lädt, zu deaktivieren.
Hab eben auch irgendwo gelesen, dass es eigentlich sinnvoller nud schneller ist die Module fest einzukompilieren und die Hotplug-Scripte beim Booten ganz wegzulassen. Klingt auch logisch, nur: Welche Module brauche ich denn, damit Standardsachen wie USB1.1, USB2.0, FireWIre, Bluetooth auch korrekt funktionieren.
Wenn ich meinen USB-Stick im laufenden Betrieb dranstecke, soll er ja auch erkannt und gemountet werden....
Wenn das auch geht mit fest kompilierten Modulen und ohne /etc/init.d/hotplug ausführen zu müssen wäre das natürlich ohnehin viel schöner.

[KBDCALLS]

Wobei das bei USB und Firewire nicht so viel Sinn macht meiner Meinung nach. Denn der SCSIbus muß ja gescant werden, wenn ein neues Gerät dazukommt. Versuch doch erst einmal alle Module wo du meinst die Probleme machen zu deaktivieren, und dann mal nach und nach mit modprobe zu laden , und sehen was passiert.

Für usb wird usbcore ohci-hcd oder uhci-hcd und für 2.0 noch ehci-hcd gebraucht. Und dann noch usb-storage für eine USB Stick.


ieee1394 und ohci394 für Firewire , sbp2 für ne Festpallte am Firewire und eth1394 für Netzwerk über Firewire.

[rahab]

Cool Danke,

hab den Bösewicht gefunden.
Es is tatsächlich der tg3, der Stress gemacht hat.
Jetzt ist der Kernel soweit ok.
Vielleicht kompilier ich ihn dann nochmal mit den Modulen die du genannt hast fest drin. Will so wenig wie möglich modular haben...