PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : alsa nach hunters Anleitung unter Debian Sid - es funktioniert nicht



holgerw
28.08.03, 01:25
Hi,

wegen meinem Interesse, mal slackware9.0 zu testen, habe ich meine Festplatte neu partitioniert und dann erstmal Debian Woody neu aufgesetzt. Dabei habe ich dann überlegt, trotz damaliger Schwierigkeiten mit alsa unter Sid es nochmal mit einem Distupgrade auf Sid zu versuchen, um dann nach hunters Anleitung alsa zu kompilieren.

So, mit Debian Woody CD eine Minimalinstallation mit kernel-2.4.18-bf24, dann ein dist-upgrade. kde läuft, Grafikbeschleunigung läuft, aber:
alsa macht mir langsam Magenschmerzen, Stunden probiere ich herum, das nach hunters howto zu installieren.

Kernelheader und Kernel müssen übereinstimmen, daher habe ich zunächst die kernel-header-2.4.18-bf24 noch aus stable installiert.
Dann alles nach hunters Howto. Der Witz: Es läuft alles ohne Fehler durch.
driver, snddevices anlegen, dann lib, dann oss und zum Schluss utils.

Für /etc/init.d habe ich mir ein alsastartscript angelegt, das sieht so aus:
#!/bin/sh
modprobe snd-emu10k1
modprobe snd-pcm-oss
modprobe snd-seq-oss
amixer set Master 90% unmute
amixer set PCM 80% unmute
amixer set CD 100% unmute

Das funktioniert schon, solange ich mit Debian arbeite :)

Aber:
Es hängt und lässt sich nur noch mit einen reboot beenden. Auch ein manuelles
modprobe snd-emu10k1
bleibt hängen, das Modul ist aber da! Warum geht das nicht?

Gut, alles mit make uninstall und distclean wieder entfernt, dann die kernel-header-2.4.18-bf24 aus unstable genommen. Wieder alsa installiert. Wieder der gleiche Mist:
modprobe snd-emu10k1
bleibt hängen.

Dann mal versucht, kernel-2.4.21 selbst zu kompilieren, trotz Modul agpgart und mga kriecht damit meine Grafikkarte. Da noch diverse Male rumprobiert, zum Glück mit kpkg-make, so dass ich schlechte Kernel gleich mit dpkg -r wieder runterschmeißen kann, sonst hätte ich die Krise mit dem vermurksten Kernel bekommen.

Dann noch ein Versuch mit kernel-2.4.18-bf24 Image aus unstable, das lässt sich aber gar nicht installieren, Fehler wegen fehlender initrd - so ein Unfug, mit dem Standard kernel-2.4.18-bf24 stable brauche ich auch keine initrd :(

Dann ein letzter Versuch nochmal mit kernel-header-2.4.18-bf24 aus stable.

Natürlich geht es nicht, warum sollte es jetzt gehen ...

Warum geht es nicht? Langsam kommt richtig Ärger auf, denn ich sehe da keine Logik hinter. Header und Kernel stimmen überein, alsa lässt sich komplett korrekt kompilieren und installieren - und funktioniert dann nicht.

Bitte um Hilfe, sonst muss ich Sid runterschmeißen und wieder Woody nehmen. Dabei läuft der Rest so gut, für Sid ist einiges an Zeit vergangen, so eine Sch***e.

Weis jemand etwas dazu?

Grüße,
Holger

... der jetzt nach 3 !/2 Stunden - es ist fast 2.30 Uhr nachts - erstmal ins Bett geht.

jebe
28.08.03, 03:45
wenn du mir sagst was das mit slackware zu tun helf ich dir ;)

SCNR ;)

jebe

holgerw
28.08.03, 08:35
Hi,

wegen slackware habe ich meine Festplatte umpartioniert, das will ich nach wie vor aus Neugier testen. Debian Woody hätte natürlich drauf bleiben können, aber ich installier Debian nunmal gerne *g*.

Ernsthaft: Ich hatte gestern neben meiner Arbeit etwas Zeit und wollte einfach vor meinem slackware Test nochmal probieren, auf Debian unstable alsa zum Laufen zu bringen. In unstable ist einiges leichter für ein Desktopsystem und eh ich bei einem kompletten Desktop Woody mit diversen Backports von gnome2.2 und kde3.1.3 auf unstable umstelle und dabei Probleme auftreten können, habe ich in ner halben Stunde schneller ein Miniwoody neu installiert und dann auf unstable umgestellt, ohne mich mit inoffiziellen apt sourcen für Woodybackports rumärgern zu müssen - und inoffizielle apt sourcen können beim Upgrade gewaltig Ärger machen *g*

Bitte aber nun zu meinem alsa Problem: Ein Gedanke kam mir eben noch dazu:
Könnte es sein, dass das Problem am Standard gcc Kompiler 3.x in unstable liegt? Der Kernel ist ja nach wie vor der 2.4.18-bf24 aus stable, d.h., der wurde mit gcc 2.95 erstellt. Kann darin das Problem liegen, dass kernelnahe Komponenten mit der gleichen Kompilerversion wie der Kernel selbst erstellt werden müssen?

@jebe: Nach dieser "ausführlichen" Erklärung wegen slackware nehm ich Dich nun beim Wort - aber Hilfe von anderen ist natürlich genauso willkommen :D

Grüße,
Holger

Susu
28.08.03, 09:39
Original geschrieben von holgerw
Dann noch ein Versuch mit kernel-2.4.18-bf24 Image aus unstable, das lässt sich aber gar nicht installieren, Fehler wegen fehlender initrd - so ein Unfug, mit dem Standard kernel-2.4.18-bf24 stable brauche ich auch keine initrd :( Vorweg gefragt: Bootest Du mit Lilo? Wenn ja, wirst Du bei der Installation des kernel-images darauf hingewiesen, einen Eintrag in die lilo.conf hinzuzufügen, der irgendwas mit initrd enthält (weiß jetzt gerad nicht genau, wie das heißt, wird aber bei der Installation genau beschrieben). Letztendlich verweist der Eintrag dann (z. B.) auf /boot/initrd-undsoweiter.img. Danach musst Du - aber das weißt Du ja - lilo nochmal aufrufen... GRUB erkennt das automatisch und verweist auch dadrauf...

Der Standard-Kernel braucht (warum auch immer - ich schnall das eh nicht) keine initrd bzw. initrd.img...

Gruß, Susu

Susu
28.08.03, 19:58
Original geschrieben von holgerw
(...) habe ich in ner halben Stunde schneller ein Miniwoody neu installiert und dann auf unstable umgestellt, ohne mich mit inoffiziellen apt sourcen für Woodybackports rumärgern zu müssen - und inoffizielle apt sourcen können beim Upgrade gewaltig Ärger machen *g* Jepp, über Miniwoody (inzwischen Bonzai Linux) geht's wirklich am schnellsten zu SID, und einfach ist es auch noch... Backports sind ziemlich... äh... naja! Irgendwann passt das eine nicht mehr zum anderen. Ich weiß, wovon ich rede... *rolleyes*

Und SID ist wirklich klasse - wenn man es in Kauf nehmen kann, das ab und an mal 1-2 Tage irgendwas nicht richtig läuft... *grins* Jetzt gerade läuft bei mir alles super - bis auf oggenc, das verursacht schon seit Wochen Speicherzugriffsfehler... *grummel*

Grütze, Susu

holgerw
29.08.03, 08:22
Hallo,

ich habe es zum Laufen bekommen. Es liegt am Kompiler.
alsa muss mit der gleichen gcc Version kompiliert werden, wie der Kernel, den man benutzt.

Das bedeutet:
Kernel-2.4.18-bf24 von Debian Woody -> alsa muss mit gcc-2.95 gebaut werden
Kernel-2.4.x von Debian Sid -> alsa muss mit gcc-3.x gebaut werden

wickey
30.08.03, 00:06
> ich habe es zum Laufen bekommen. Es liegt am Kompiler.
> alsa muss mit der gleichen gcc Version kompiliert werden, wie der Kernel, den man benutzt.

Die Kernelmodule müssen wie der Kernel mit dem selben Kompiler kompiliert werden, nicht Alsa selbst.

grüße wickey

holgerw
30.08.03, 04:59
Hi wickey,

wenn Du mit den "Kernelmodulen" die alsa-driver meinst, wird es sicher stimmen.

Wie es sich dann mit den alsa libs, also oss und alsa utils verhält, kann ich nicht sagen. Aber es ist doch sehr unwahrscheinlich, dass ich bei manueller alsa Installation per ./configure && make && make install die driver mit einem anderen Kompilierer übersetze, als die alsa libs, die alsa utils und alsa oss.

Ich habe hunter schon eine Ergänzung zu seinem Howto per PN geschickt. Vielleicht kann diese genauere Differenzierung da noch mit reingenommen werden, mal sehen, ob hunter das als Ergänzung seinem Howto anfügen möchte.

Kann es übrigens sein, dass diese Anleitung von Dir ist:
http://members.aon.at/wickey/kernel_deb.html#unstable

Wenn ja, dann danke dafür - seitdem baue ich Kernel unter Debian nur noch mit kpkg-make. :)

Grüße,
Holger

wickey
30.08.03, 16:32
Ja ist meine Page :)

grüße wickey