# Wechsel von stable auf unstable

## Erdie

Aufgrund von scheinbar unlösbaren Sound Problemen auf meinem Lenvov T60 (x86) möchte ich das  gesamte System auf ~x86 migrieren und hoffen, dass sich  mein Fehler dadurch von selbst löst. 

Hintergrund:

Das Gerät  ist seit unbestimmter Zeit nicht mehr brauchbar. Es dient ausschließlich dem  Zweck des Audio Recordings mit einer RME HDSP Soundkarte. Obwohl ich inzwischen einen Reatime Kernel habe, kommt es  unweigerlich zu Verzerrungen und Knackgeräuschen, sofern man die Maus bewegt und z. B: nur den  Fokus von einem Fenster zum andern wechselt. Es  werde dabei seitens der Soundarchitektur keinerlei Fehler (Dropouts, xruns) angezeigt. Der Datenstrom scheint ungestört zu sein. Dieses Verhalten hat sich unbemerkt vermutlich mit einem World Update eingeschlichen. Da ich nur zwischenzeitlich  aufnehme, habe ich es erst später entdeckt, so dass ich die Ursache nicht mehr zurückverfolgen kann. Ich habe schon sämtliche xorg und Grafiktreiber Bestandteile up- und downgegraded - ohne Erfolg. Das System wurde mehrmals komplett mit verschiedenen gcc Versionen neu kompiliert. Ein Hardwaredefekt ist ausgschlossen, weil ich 2 identsiche Gentoo basierte Geräte habe und beide haben das Problem zur gleichen Zeit "bekommen".

Falls noch jemand einen Lösungsversuch hat, immer willkommen.

Ansonsten möchte ich auf ~x86 gehen und schauen, was passiert. Wenn das nicht hilft, muß ich sowas wie Ubuntustudio versuchen zu installieren, was ich äußerst ungern täte. Aber ich brauche ein lauffähiges System. Im Moment kann ich keine  Recording Aufträge mehr annehmen und ich stehe somit komplett auf dem Schlauch.

Reicht es die make.conf zu modifizieren und ein world update zu machen oder braucht es dafür noch  mehr?

----------

## Randy Andy

Hi Erdie.

Ja das reicht. Brauchst also im günstigsten Fall nur eine Tilde hinzufügen, falls sich dieser Eintrag schon in deiner make.conf befindet:

ACCEPT_KEYWORDS="~x86" 

und dann wie gewohnt dein world update anstoßen.

Empfehlenswert ist sicher zuerst nach dem sync dein Portage upzudaten, dein Profil zu kontrollieren ggf. aktualisieren und dann geht's los.

Ob deine Probleme damit aber weniger werden bleibt abzuwarten, trotzdem wünsche ich, Happy Compiling.

----------

## Erdie

 *Randy Andy wrote:*   

> 
> 
> Ob deine Probleme damit aber weniger werden bleibt abzuwarten, trotzdem wünsche ich, Happy Compiling.

 

Schlimmer kann es nicht mehr  werden   :Wink: 

Momentan bin ich bei 473 von 790. Ich kompiliere gerade alles nochmal mit dem neuen gcc. Morgen läuft dann der Test.

----------

## Erdie

Jetzt ist es fertig und der Desktop kommt nicht mehr hoch. Ursache: consolekit crashed. 

Ich suche momentan nach dem root cause ..

----------

## cryptosteve

Das ist aber ärgerlich. Habe ich so auch noch nicht gesehen. Bei mir kam der Desktop eher nicht hoch, weil consolekit nicht gestartet war.  :Smile: 

Findest Du irgendwelche Hinweise in irgendwelchen Logfiles?

Falls alle Stricke reißen, wäre es vielleicht ein geeigneter Moment, um auf systemd umzustellen. Das braucht kein consolekit mehr. Ich habe die Umstellung gerade hinter mir. Und obwohl es sich für mich anfänglich als etwas steinig erwiesen hat, läuft es jetzt total zufriedenstellend.

Aber vielleicht findet Du den Absturzgrund für/von consolekit ja auch.

----------

## Erdie

 *cryptosteve wrote:*   

> Das ist aber ärgerlich. Habe ich so auch noch nicht gesehen. Bei mir kam der Desktop eher nicht hoch, weil consolekit nicht gestartet war.  

 

Ist das nicht das gleiche? Consolekit ist nicht gestartet weil er beim start crasht. Dannach ist er dann nicht gestartet.

Wo kann man denn nach der Ursache suchen. Kann das an der "alten" Konfiguration liegen?

Wie kommt das denn, dass ich den Desktop mit "startx" starten kann? Wir consolekit dann nicht benötigt?

----------

## mv

 *Erdie wrote:*   

> Verzerrungen und Knackgeräuschen, sofern man die Maus bewegt und z. B: nur den  Fokus von einem Fenster zum andern wechselt.

 

Das kann induzierte Spannung sein. Da kannst Du vermutlich wenig gegen machen, außer versuchen, die Karte besser zu isolieren (hat bei mir bei ähnlichen Problemen aber auch nie geholfen).

Die Software kann so etwas indirekt auslösen, indem irgendwelche Update-Frequenzen geändert wurden, die nun zufälligerweise im hörbaren Bereich liegen.

Als Kandidate würde ich da ausschließlich den Kernel vermuten: Probier mal, ob ein (deutliches) Downgraden des Kernels hilft.

Es ist unwahrscheinlich, dass das Problem mit einem neueren Kernel so schnell wieder verschwinden wird, da das Verhalten vermutlich kein Bug der Software im eigentlichen Sinne ist, sondern nur eine unerwünschte Nebenwirkung bei "fehlerhafter" (nicht genügend isolierter) Hardware.

----------

## Erdie

 *mv wrote:*   

>  *Erdie wrote:*   Verzerrungen und Knackgeräuschen, sofern man die Maus bewegt und z. B: nur den  Fokus von einem Fenster zum andern wechselt. 
> 
> Das kann induzierte Spannung sein. Da kannst Du vermutlich wenig gegen machen.
> 
> Die Software kann so etwas indirekt auslösen, indem irgendwelche Update-Frequenzen geändert wurden, die nun zufälligerweise im hörbaren Bereich liegen.
> ...

 

Das kann leider  nicht sein, weil das Notebook ca. 3-4 Jahre perfekt funktioniert hat, mit exakt derselben Hardware. Ausserdem sind die Thinkpads dafür bekannt, für den Zweck sehr gut geeignet zu sein. Die Soundkarte kostet das mehrfache des  Notebooks und wird über den PCMCIA Slot an den PCI Bus verbunden. Alle analogen Komponenten sind 2 Meter vom Rechner entfernt. Der Fehler hat sich hinterhältig über ein Update eingeschlichen.

----------

## mv

 *Erdie wrote:*   

> Wie kommt das denn, dass ich den Desktop mit "startx" starten kann? Wir consolekit dann nicht benötigt?

 

Kommt auf Deinen Windowsmanager an. Mit einem "schlanken" Windowsmanager [wie fvwm-crystal, falls Du es nicht es nicht ganz so schlank willst] brauchst Du consolekit (oder das systemd-Äquivalent) nicht. Wenn Du slim mit entsprechenden USE-flags kompilierst, brauchst Du consolekit auch im Desktopmanager nicht.

----------

## mv

 *Erdie wrote:*   

> Das kann leider  nicht sein, weil das Notebook ca. 3-4 Jahre perfekt funktioniert hat, mit exakt derselben Hardware.

 

Wie gesagt: Irgendeine Frequenz kann jetzt im hörbaren Bereich sein, die vorher zu langsam oder zu schnell dafür war.

 *Quote:*   

> Alle analogen Komponenten sind 2 Meter vom Rechner entfernt.

 

Wenn Stromschwankungen auf dem Bus stattfinden, ist die Entfernung egal.

----------

## Erdie

 *mv wrote:*   

>  *Erdie wrote:*   Wie kommt das denn, dass ich den Desktop mit "startx" starten kann? Wir consolekit dann nicht benötigt? 
> 
> Kommt auf Deinen Windowsmanager an. Mit einem "schlanken" Windowsmanager [wie fvwm-crystal, falls Du es nicht es nicht ganz so schlank willst] brauchst Du consolekit (oder das systemd-Äquivalent) nicht. Wenn Du slim mit entsprechenden USE-flags kompilierst, brauchst Du consolekit auch im Desktopmanager nicht.

 

ich habe xfce mit  slim. Dann kann ich das ja machen  :Wink: 

----------

## Randy Andy

Erdie,

sollten tatsächlich irgendwelche Frequenzeinstellungen des kernels dafür verantwortlich sein können, dann würde ich mal hiermit beginnend experimentieren und verschiedenen der angebotenen Frequenzen ausprobieren.

Deine aktuelle Einstellung kannst Du auf die schnelle ja z.B. mit

```

zgrep CONFIG_HZ /proc/config.gz
```

auslesen.

 *Quote:*   

> 
> 
> CONFIG_HZ_300:                                                 │                                │
> 
>  │                               │                                                                │                                │
> ...

 

Zu dem leidigen Consolekit Problem:

Äußert sich das so, dann bin auch davon betroffen und du findest hier vielleicht Rat: https://forums.gentoo.org/viewtopic-t-982964-highlight-.html

Mir hat's leider noch nicht geholfen und womöglich mach ich bald meinen eigenen Thread auf.

@Cryptosteve

systemd als Lösung zu empfehlen finde ich ehrlich gesagt etwas heikel, nicht zuletzt wegen der politischen Brisanz diese Themas.

Und da viele ja gerade mit der Art und Weise wie die LP-Software in den "Markt" gedrückt wird, unzufrieden sind, frage auch ich mich in meiner Paranoia, ob das mit den frisch aufgekommenen Consolekit Problemen der neueste Schachzug ist, die Leute zum Wechsel auf systemd zu bewegen, also nach dem Motto: Ein Schelm wer dabei böses denkt.

Und die Strategie scheint ja bereits aufzugehen. In dem oben verlinkten Thread zu dem Consolekit Problem empfiehlt es auch schon Jemand als Lösung und jetzt auch noch Du hier.  :Crying or Very sad: 

Lasst uns doch lieber mal, wie unter Gentoo eigentlich üblich, nach der wahren Ursache fahnden, um diese dann abzustellen. Alles andere bedeutet doch letztlich, den Weg des geringsten Widerstandes gehen, was nach meinem Dafürhalten nicht dem Gentoo-Way entspricht und daher nicht die Lösung sein sollte.  :Wink: 

Davon Abgesehen darf natürlich gern Jeder das init-System verwenden das er möchte und ich will jetzt auch nicht näher auf weitere Details zu meiner Einstellung dazu eingehen. 

Es gibt ja bereits genug rant Threads zu dem Thema, weshalb ich das nicht unbedingt weiter aufbauschen möchte.

Besten Gruß, Andy.

----------

## cryptosteve

 *Randy Andy wrote:*   

> systemd als Lösung zu empfehlen finde ich ehrlich gesagt etwas heikel, nicht zuletzt wegen der politischen Brisanz diese Themas.

 

Bevor wir das Thema systemd hier krepieren lassen, möchte ich zu meiner Verteidigung nochmal anmerken, dass ich "systemd" als letzten Ausweg gesehen habe, falls alle anderen Lösungen versagen.  :Smile:  Ich empfehle es also nicht, sondern ziehe es nur als Notnagel zu einem überhaupt funktionsfähigen System in Betracht.

Was die Funktion selbst angeht, befinde ich mich selbst noch in der Testphase.  :Smile: 

Aber zurück zum Thema und meiner Frage, ob denn die Logfiles irgendwas zum consolekit-crash hergeben?!

----------

## Erdie

Der Upgrade auf  ~x86 hat überhaupt nichts gebracht, ich habe auch verschiedene Kernel ausprobiert. Jetzt möchte  wieder auf stable zurück und habe das Problem, dass eine glibc downgrade  anscheinend nicht erlaubt ist. Wie bekomme ich wieder meine alte glibc wieder zurück bzw. wie schaffe ich es, weider auf x86 zu kommen?

systemd  ist für mich keine Option.

----------

## Christian99

Bemüh mal die Forumssuche, da gibts irgendwo eine Anleitung zum glbc downgrade. du könntest aber auch einfach die glibc auf der neuen version lassen und nur den rest downgraden, wäre wahrscheinlich einfacher.

----------

## Randy Andy

Ein alter Bookmark den ich mal dazu hatte ist leider tot, fand dafür aber das:

https://forums.gentoo.org/viewtopic-t-845000.html

http://gentoo-en.vfose.ru/wiki/Downgrade_Glibc

----------

## bell

Hattest Du vor der Aktion ein Backup gemacht? Dann solltest Du dieses jetzt einspielen. Ein Downgrade ist nicht so einfach und könnte neue Probleme verursachen, wenn zB. aktualisierte Konfigurationsdateien neuer Versionen mit alten Programm-Versionen laufen sollen. 

Die übliche Vorgehensweise zum Wechsel von ~ auf Stable ist in der make.conf auf Stable zu stellen und alle installierten Testing-Pakete in die package.keywords mit Version einzutragen. Dann warten bis diese Versionen von Stable eingeholt werden.

----------

## franzf

 *mv wrote:*   

>  *Erdie wrote:*   Das kann leider  nicht sein, weil das Notebook ca. 3-4 Jahre perfekt funktioniert hat, mit exakt derselben Hardware. 
> 
> Wie gesagt: Irgendeine Frequenz kann jetzt im hörbaren Bereich sein, die vorher zu langsam oder zu schnell dafür war.

 

Dazu folgende Idee:

Wenn ich mich an meine Physikzeit richtig erinnere, hängt die Eigenfrequenz u.A. von der Masse ab. Diese kann sich womöglich verändert haben, indem sich hartnäckig Staub/Dreck festgesetzt hat - z.B. zwischen irgenwelche Lamellen eines Külkörpers. Hast du den Laptop schonmal aufgemacht und ordentlich ausgeputzt? (wobei es eher unwahrscheinlich ist, dass so etwas bei mehreren Rechnern gleichzeitig auftritt - außer du hast irgendwelche abartigen Staubmilben, die durch diese speziellen Frequenzen beim Balztrieb stimuliert werden, und sich die Geräte "zurechtbiegen"... Dann brauchst du eher einen Exorzisten  :Razz: )

----------

## Erdie

Nein, die Verzerrungen sind definitiv digital und sie nehmen zu wenn Objekte auf dem Desktop verschoben werden. Das habe ich mal simuliert und dabei etwas mit einem Studiomikrofon aus dem Lautsprecher aufgenommen. Das hört  sich dann so an:

http://www.erdie.de/test.mp3

Mit dem gleichen Rechner und dem gleichen Mikrofon (nur etwa 10 mehr davon) klingt das dann so, zu der Zeit, als der Bug noch nicht da war:

http://www.erdie.de/orchesterbeispiel1.mp3

Mein jetzt immernoch jemand, das hätte mit Staub oder  ähnlichem zu tun?

Grüße

Erdie

----------

## cryptosteve

Ich habe jetzt so gar keine Ahnung von Audio, aber wäre es nicht möglich, mal eben fix mit einer LiveCD zu testen, ob das unter anderen Distributionen / anderen Softwareversionen nicht auftritt? Vielleicht lässt sich das Problem auf eine Software-/Treiberversion eingrenzen?

----------

## Erdie

 *cryptosteve wrote:*   

> Ich habe jetzt so gar keine Ahnung von Audio, aber wäre es nicht möglich, mal eben fix mit einer LiveCD zu testen, ob das unter anderen Distributionen / anderen Softwareversionen nicht auftritt? Vielleicht lässt sich das Problem auf eine Software-/Treiberversion eingrenzen?

 

Das wäre eine Möglichkeit, allerdings aufwendig. Ich  müßte der LiveCD die Treiber für das hdsp  Interface  und die Realtime 

Fähigkeit beibringen. Out of the box funktioniert es nicht. Ich hatte das, glaube ich, vor einiger Zeit mal probiert. Einfacher wäre es  den Rechner  komplette plattzumachen und sowas wie Ubuntustudio zu installieren. Ich könnte dann ein Backup des Zweitrechners einspielen um wieder auf Gentoo zu kommen.

Der 2. Rechner ist da, falls der 1. mal ausfällt. Wenn ich update, prüfe ich erst, ob alles funktioniert. Dannach mach ich das Update auf dem Backuprechner. Leider habe ich  dieses Problem nicht sofort erkannt, weil es  unter bestimmten Umständen beim Aufnehme nur  wenig und im Normalbetrieb gar nicht auffällt. Deshalb habe ich beide Rechner upgedated und die Misere war komplett.

Eine Möglichkeit wäre alle  Pakete anzufassen, die irgendetwas mit xorg und Grafik zu tun haben. Vielleicht kann mir mal jemand eine Liste nennen. Versucht habe ich es bisher mit xorg, xorg-ati-driver.

----------

## mv

Es wäre auch noch denkbar, dass sich irgendwelche IRQ-Locking/Scheduling-Mechanismen verändert haben, die nun für Sekundenbruchteile die Soundkarte blockieren könnten.

Ich würde mich bei der Suche nach dem Sound-Problem i.W. auf den Kernel konzentrieren (zu dem Du ja, soweit ich das richtig verstanden habe, Patches eingespielt hast). Es kann sein dass ein (deutlicher) Downgrade des Kernels das Soundproblem löst - was natürlich nicht bedeutet, dass Du Dir damit nicht neue Probleme einhandeln kannst, aber zur Analyse des Problems solltest Du das versuchen.

glibc zu downgraden ist nicht möglich, denn Du müsstest danach alle Pakete neu kompilieren, die Du mit der neuen Version kompiliert hast, damit sie wieder gehen, was bei Basispaketen zum Henne-und-Ei-Problem führen kann. Ich würde einfach das ACCEPT_KEYWORDS="~..." entfernen und dann ein directory /etc/portage/package.accept_keywords anlegen, das Du mit 

```
equery list --installed | sed -e 's/^/~/' -e 's/-r[0-9][0-9]*$//' >/etc/portage/package.accept_keywords/experiment
```

 mit allen derzeitigen Paketen füllst. Danach (und regelmäßig nach world updates) schaust Du einfach mit eix-test-obsolete nach, welche Einträge davon redundant sind und entfernst diese, bis die Liste (vermutlich in mehreren Monaten) leer ist. So vermeidest Du Neukompilierung ganz.

(Der Nachteil ist, dass Du dann ein gemischtes System fährst und daher u.U. auf einige Bugs stoßen kannst.)

----------

## Randy Andy

Erdie,

das sind ja recht anspruchsvolle Aufnahmen die Du da machst - Respekt.

Da Du das Probleme sowohl mit stable als auch mit testing hast, ist es doch eigentlich einerlei womit Du weiter machst, denn der Fehler wird wohl eher mit Settings oder so neuen Paketen zu tun haben, die das Problem offensichtlich in beiden Varianten tragen.

Also lass uns doch mal konkreter nach der Ursache suchen, da Du offensichtlich kein altes Backup hast auf das du zurück gehen könntest, um es auszumerzen.

Poste doch mal bitte deine emerge --info und lade deine kernel.conf irgendwohin hoch.

Vielleicht können wir dann etwas konkretere Vorschläge unterbreiten...

Gruß, Andy.

----------

## Erdie

Also jetzt habe ich mir doch mal die aktuellst Ubuntustudio DVD runtergeladen und gebootet. Und siehe da, nachdem ich die Firmware der  Soundkarte selbst gebaut habe (warum ist sowas bei Gentoo in Portage und eine auf Audio spezialisierte DAU distri erwartet, dass man das  selbst baut - muß man das verstehen??)

Tja, es funktioniert soweit ich erkennen kann einwandfrei. Es fällt mir schwer als treuer  Gentoo Anhänger jetzt auf sowas zu wechseln. Aber ich weiß jetzt, dass es die Software ist (Wie ich vermutet habe)

Der Versuch auf stable zurück zugehen ist, wie von Euch vorhergesagt, schiefgegangen. Der Desktop ist schrott, kein Panel mehr und einige Pakete kompilieren nicht mehr. vorher hatte ich noch eine emerge -e world gemacht und es  lief alles durch.

Ein Backup kann ich von dem 2. Rechner ziehen, der  ist auf einem etwas älteren Gentoo - Stand. Versuchen könnte man es schon noch aber ich bin nach wochenlanger Suche, ehrlich gesagt, etwas  müde geworden und meine Zeit ist knapp. Ich werde  jetzt erstmal darüber schlafen und dann entscheiden. Auf der anderen Seite kann ich ja die Gentoo Experimente auf dem 2. Rechner fahren und dann quasi Rechner 1 Ubuntustudio und Rechner 2 auf Gentoo. Mein Deskop ist eh Gentoo und da läuft das Audio Zeugs perfekt drauf. Mein Workflow ist immer: Ich nehm mit dem Laptop auf, kopiere auf den Desktop und  mixe dort weiter. Aber ich will euch nicht vollquasseln  :Wink: 

@mv, ich habe nicht selbst gepatched sondern sys-kernel/rt-sources installiert. Vorher ging es allerdings  einwandfrei mit den gentoo-sources, also ohne Realtime Patches. Das war nur ein Versuch. Ältere Kernelstände sind leider nicht mehr in Portage und 3.0.irgendetwas hatte schon probiert. Da ich schon sehr viele Kernel Versionen probiert hatte, bin ich mir nicht mehr so sicher, ob es wirklch am Kernel liegt, obwohl das i. d.R. wahrscheinlich ist.

Grüße

Erdie

----------

## Randy Andy

Es wäre ja jetzt relativ einfach, mal die Ubuntu Kernel Konfiguration zu extrahieren und Dir den Gleichen unter Gentoo zu bauen, um mal auf die schnelle zu testen ob damit schon alles gefixt ist.

Alternativ könnest Du auch den kernel nebst zugehörigem modul-Verzeichnis auf den Gentoo kopieren. Ich würde aber erstere Variante bevorzugen.

Gruß, Andy.

----------

## Erdie

 *Randy Andy wrote:*   

> Es wäre ja jetzt relativ einfach, mal die Ubuntu Kernel Konfiguration zu extrahieren und Dir den Gleichen unter Gentoo zu bauen, um mal auf die schnelle zu testen ob damit schon alles gefixt ist.
> 
> Alternativ könnest Du auch den kernel nebst zugehörigem modul-Verzeichnis auf den Gentoo kopieren. Ich würde aber erstere Variante bevorzugen.
> 
> Gruß, Andy.

 

Ich  habe mich erstmal entschlossen, zumindest Laptop1 auf Ubuntustudio laufen zu lassen weil es problemlos funktioniert. Ich werde das  Gerät auch nicht updaten oder patchen. Das ist kein Arbeitsrechner, der ständig im Netz hängt, was soll ich den  kaputtpatchen wenn er jetzt genau tut, was ich brauche.

Aber Laptop2 werde ich auf Gentoo belassen und versuchen, das Problem zu lösen. Dazu meine Frage: Das sind doch alles Genkernel, wie soll ich da erkennen, was relevant ist? Den Kernel kopieren ist keine schlechte Idee, da dieser Optimierungen enthält, als nicht standard ist. Das wird schwer nachzubauen sein.

----------

## AmonAmarth

 *Erdie wrote:*   

> Nein, die Verzerrungen sind definitiv digital und sie nehmen zu wenn Objekte auf dem Desktop verschoben werden. Das habe ich mal simuliert und dabei etwas mit einem Studiomikrofon aus dem Lautsprecher aufgenommen. Das hört  sich dann so an:
> 
> http://www.erdie.de/test.mp3
> 
> Mit dem gleichen Rechner und dem gleichen Mikrofon (nur etwa 10 mehr davon) klingt das dann so, zu der Zeit, als der Bug noch nicht da war:
> ...

 

Akkustisch hat mich deine Queen-Aufnahme schwer an eine Macke von dem VLC Phonon backend erinnert. Ich weiß nicht genauz wieso, aber immer wenn ich dieses anstatt GStreamer aktiviere hören sich meine MP3s genauso an. Ich habe den Thread nur überflogen, deswegen ist die Frage vielleicht redundant: ALSA/OSS? Audioserver a la Pulseaudio/JACK? Phonon?

----------

## Randy Andy

 *Erdie wrote:*   

>  Dazu meine Frage: Das sind doch alles Genkernel, wie soll ich da erkennen, was relevant ist? Den Kernel kopieren ist keine schlechte Idee, da dieser Optimierungen enthält, als nicht standard ist. Das wird schwer nachzubauen sein.

 

Solltest Du den kernel kopieren wollen, dann auch an das zugehörige /lib/modules/KernelversionsNr. Verzeichnis denken und auf eventuell separat eingebundene Firmware achten.

Außerdem kannst Du doch entweder aus dem laufenden kernel dessen Konfiguration extrahieren, sofern er dafür per Konfiguration via

<*> Kernel .config support.

[ ] Enable access to .config through /proc/config.gz

freigegeben wurde.

Dann eben per dazu passender Dkompressionsmethode die config an deinen gewünschten Ort kopieren und schon kannst Du sie an genkernel übergeben um Dir den gleichen kernel unter Gentoo erstellen zu lassen.

Bei zip Kompression also z.B. mittels:

```
zcat /proc/config.gz > /usr/src/linux/.config
```

 bzw. auf den andern PC kopieren.

Wenn der funktionierende (ubuntu) kernel nicht läuft aber irgendwo rumliegt, aber nicht läuft, dann kannst Du dessen Konfiguration auch mit dem

extract-ikconfig script extrahieren, z.B. so:

```
usr/src/linux/scripts/extract-ikconfig /boot/Dein Ubuntu-kernel > /usr/src/linux/.config
```

und analog zu oben verfahren.

Wenn Du dagegen deinen laufenden, funktionierenden kernel auf die relevanden Bestandteile eindampfen möchtest, dann geht das mit dem make target: localmodconfig.

Als Ausgangsbasis dient die Konfigurationsdatei des gerade laufenden Kernels; jedoch werden alle Module deaktiviert, die zu diesem Zeitpunkt nicht geladen sind.

Daher fehlen möglicherweise Treiber für Geräte, die beim Aufruf von Make nicht angeschlossen sind – etwa USB-Hardware. 

Ergo:  Mit Generischem Kernel der alles unterstützt starten, sämtliche beabsichtigten  Module zur temporären Hardwareunterstützung laden bzw. Hardware verbinden damit diese geladen werden. Eventuell vorher zu ladende Firmware berücksichtigen, damit diese Hardware überhaupt gefunden wird!

Kernel-Make Zeile den Parameter localmodconfig  übergeben.

Bei Nicht-Verwendung einer Initrd, oder darin fehlender Unterstützung, anschließend noch den Status von Modulen in Yes ändern, die zum booten benötigt werden, wie z.B. Dateisystemunterstützung zum Zugriff auf die root-Partition, von wo aus dann erst weitere Module nachgeladen werden können;-)

Viel Erfolg dabei. 

Hoffe die Syntax passt in etwa, da alles aus'm Kopft getippt.  :Wink: 

Gruß, Andy.

----------

## Erdie

 *AmonAmarth wrote:*   

>  *Erdie wrote:*   Nein, die Verzerrungen sind definitiv digital und sie nehmen zu wenn Objekte auf dem Desktop verschoben werden. Das habe ich mal simuliert und dabei etwas mit einem Studiomikrofon aus dem Lautsprecher aufgenommen. Das hört  sich dann so an:
> 
> http://www.erdie.de/test.mp3
> 
> Mit dem gleichen Rechner und dem gleichen Mikrofon (nur etwa 10 mehr davon) klingt das dann so, zu der Zeit, als der Bug noch nicht da war:
> ...

 

jack-audio-connection-kit im Realtime Modus. Keine "Xruns". Das Knistern entsteht, wenn ich mit der  Maus das Ardour Mixerfenster hin  und herschiebe.

----------

## Erdie

 *Randy Andy wrote:*   

>  *Erdie wrote:*    Dazu meine Frage: Das sind doch alles Genkernel, wie soll ich da erkennen, was relevant ist? Den Kernel kopieren ist keine schlechte Idee, da dieser Optimierungen enthält, als nicht standard ist. Das wird schwer nachzubauen sein. 
> 
> Solltest Du den kernel kopieren wollen, dann auch an das zugehörige /lib/modules/KernelversionsNr. Verzeichnis denken und auf eventuell separat eingebundene Firmware achten.
> 
> Außerdem kannst Du doch entweder aus dem laufenden kernel dessen Konfiguration extrahieren, sofern er dafür per Konfiguration via
> ...

 

Hi Andy,

vielen Dank, das ist eine super Beschreibung. Ubuntu bieten doch sicher auch  die  kernel sourcen an, die kann ich doch gleich komplett mit rüberziehen.

Trotzdalledem habe ich noch Zweifel, ob es wirklich nur der  Kernel  ist, weil ich schon so viele Kernel Varianten probiert habe. Wenn der  Fehler  beim Ubuntu Kernel noch auftritt, kann ich aber sicher sein, dass es nicht am Kernel liegt. Ich werde mich  an das Projekt mache.

Wenn ich die .config des Ubuntu Rechners verwenden möchte, werde ich auch die Sourcen brauchen, weil es kein Standard Kernel ist. 

Grüße

Martin

----------

## Randy Andy

 *Erdie wrote:*   

>  Ubuntu bieten doch sicher auch  die  kernel sourcen an, die kann ich doch gleich komplett mit rüberziehen.
> 
> Trotzdalledem habe ich noch Zweifel, ob es wirklich nur der  Kernel  ist, weil ich schon so viele Kernel Varianten probiert habe. Wenn der  Fehler  beim Ubuntu Kernel noch auftritt, kann ich aber sicher sein, dass es nicht am Kernel liegt. Ich werde mich  an das Projekt mache.
> 
> Wenn ich die .config des Ubuntu Rechners verwenden möchte, werde ich auch die Sourcen brauchen, weil es kein Standard Kernel ist. 
> ...

 

Hi Martin,

auch ich habe meine Zweifel das es am kernel liegt, doch genau werden wir es erst nach dem Ausschlussverfahren wissen, doch habe ich mit so einer Vermutung schon einmal falsch gelegen.   :Wink: 

Meines Wissens nach solltest Du Ubuntus kernel-sourcen nicht benötigen. Besonders dann nicht, wenn Du vorhast damit einen neuen kernel unter Gentoo zu backen könnte es wegen unangepasster Skripte Probleme geben.

Falls die proprietäre Firmware mitliefern, dann bekommst du vermutlich mit (je nach Kompresionsmethode) mit:

```
zgrep FIRMWARE /proc/config.gz
```

 heraus, wo diese liegt und wie sie heißen.

Früher lagen diese in /lib/firmware aber neuerdings aber wohl im kernel source tree oder so...  :Confused: 

Wir werden sehen...

----------

## Josef.95

Na, ich denke für den Test ist es am einfachsten dein System kurz mit dem funktionierenden Kernel-Image, mitsamt /lib/modules/Verzeichnis und der initrd zu booten.

Mit einem nachträglich gebauten Kernel ist der Test ja nicht mehr wirklich aussagekräftig.

----------

## mv

 *Josef.95 wrote:*   

> Na, ich denke für den Test ist es am einfachsten dein System kurz mit dem funktionierenden Kernel-Image, mitsamt /lib/modules/Verzeichnis und der initrd zu booten.
> 
> Mit einem nachträglich gebauten Kernel ist der Test ja nicht mehr wirklich aussagekräftig.

 

++

Wenn die initrd nicht extrem ungünstig gebaut ist, sollte der Ubuntu-Kernel auch auf Gentoo laufen: Zusätzliche Features "stören" ja nicht. Umgekehrt (Gentoo-Kernel unter Ubuntu benutzen) könnte es schwieriger werden.

----------

## Erdie

Zur Info: 

Wegen Urheberrechtstrallala habe die  beiden Links mal ungültig gemacht. Wer sie noch hören möchte, kann sich bei mir melden.

Grüße

Erdie

----------

