Beiträge von Hidalgo

    Seit dem neuesten Update für Yast läuft Audio nun wie es soll. Nach Einspielen des dreiteiligen

    Updates habe ich in /etc/modprobe.d/ die 50-sound.conf und die 50-sound.conf.Yast2save

    gelöscht und Audio neu konfiguriert (es gab auch ein sysconfig-update, was ja nach Konfigurationen

    durchlaufen muss). Alles ok!


    Freude!!!!

    Man müsste wohl pipewire-alsa und pipewire-pulseaudio zusätzlich installieren.

    Ja - sehe ich auch so, bzw. habe ich das bei mir auf Leap 15.3 durchgeführt um komplett auf pipewire umzustellen.

    Schließlich ist pipewire in Teilen bereits vorhanden. Führte dann aber zu keinem Erfolg und leider kann ich nicht

    herausfinden, inwieweit die Audio-Systemvoraussetzungen für eine "pipewire-Komplett-Übernahme des Audio-Systems"

    überhaupt gegeben sind. Jedenfalls führte das dazu, das KDE-Plasma nicht mehr startete und die fvwm-Alternative

    auch keinen Sound brachte (Komplettausfall!). Mit btrfs-Snapshot somit wieder zurück und altes Problem: Sound ist

    gemutet beim Systemstart. Hat aber gedauert, bis ich das herausfand. Das Sound-Subsystem läuft - ist aber immer

    mutet. Fehlermeldungen zeigen die logs deshalb nicht - oder ich bin zu blöde! Wenn ich mich nicht täusche, ist auch hier:


    https://forums.opensuse.org/sh…-Leap-15-3-from-Leap-15-2


    genau das gleiche Problem vorhanden (internes Audio und unter Linux seit langem bekannter und gebräuchlicher Intel-HD Treiber)

    Deshalb wurde auf Bugzilla ein entsprechender Thread dazu geöffnet, der aber bis jetzt nicht fortgeführt wird. Zu den Antworten

    des Experten äußere ich mich lieber nicht (bzw. habe ich mich dort ja schon geäußert). Jedenfalls äußert sich nun niemand zu dem

    Problem mehr dort?


    Mit Yast kann man das Audio-System konfigurieren - aber wie im o.a. Thread versucht eben nicht testen (obwohl das so

    suggeriert wird). Yast hat keine Systemweiten Befugnisse für Audio. Deshalb! Unter KDE-Plasma muss man den Test machen

    und stößt dann auf den Umstand: Alles funktioniert, wenn man den Mute-Zustand dort aufhebt, was auf Dauer nervt.


    Ist also alles gut lt. Soundsystem - funktioniert nur nicht wie es soll.

    Meines Wissens nicht.

    Mit Leap 15.3 - als Upgrade von Leap 15.2 - arbeite ich seit einigen Tagen wieder. Es gibt auf meinem System nach wie vor Probleme mit dem Sound

    und damit bin ich nicht alleine - siehe Bugzilla OpenSuSE. Für weitere Einzelheiten ist das hier nicht der richtige Thread und deshalb nur dieser

    Hinweis. Merkwürdig finde ich nur, dass pipewire (der pulse-Audio Nachfolger) zwar installiert wird, dieser aber nicht aktiviert ist und zusätzlich pulse-audio

    in diesem LTS-System installiert ist. Auf Bugzilla scheint man jedenfalls auch nicht weiter zu kommen, angeforderte logs wurden/werden geliefert. Weil Fedora konsequent auf pipewire umstellte, habe ich es mal installiert. Dort ist alles ok - keine Probleme festgestellt. Was für mich wichtig ist, läuft so wie es soll. By the way ... ich frage mich, was macht eigentlich Herr Sebastian Siebert. Er unterstützte OpenSuSE mal sehr stark und kompetent. Seit geraumer Zeit ist Funkstille - hoffentlich geht es ihm gut!

    Werde wohl wieder zu Leap 15.2 zurückgehen und so lange damit arbeiten, bis der Umstieg sein muss. Ob das dann Leap 15.3 sein wird oder ein kompletter

    Distri-Wechsel weiß ich noch nicht. Der Umstieg von Leap auf Enterprise Repos war ja auch etwas problematisch.

    Moin Gerhard


    vor längerer Zeit hatte ich auch das Problem und löste es,

    indem ich in Yast bei den Netzwerkeinstellungen vom

    "Network-Manager" auf den "wicked-Dienst"

    umstellte (danach Neustart).


    Letzterer ist bereits standardmäßig installiert.


    Der Fehler lag damals eindeutig am Networkmanager!

    Warum? Keine Ahnung.

    Ich beließ das System auf wicked und seit dem vorletzten

    Upgrade (Leap 15.2) läuft nun wieder der Networkmanager bei mir.

    Auf Bugzilla werden für Leap 15.3 aktuell Soundprobleme dokumentiert. Deshalb warte ich mit dem Upgrade noch, da die Lösung dort auch noch offen ist. Die Umstellung der Repos auf Enterprise scheint für die Software-Aktualisierungen nicht trivial zu sein, weshalb immer noch ein Zypper-up auf den betroffenen Maschinen vonnöten ist. Auf meiner z.B. (Sound + Aktualisierungen). Bei Unterversionssprüngen (Leap 15.1 auf Leap 15.2 ... z.B.) machte ich bisher immer ein Upgrade der bestehenden Version auf die jeweilige aktuelle. Bei neuen Versionen (Leap 42.3 auf Leap 15.1 z.B.) bevorzugte ich eine Neuinstallation. Mit dem btrfs-Filsystem und dem enthaltenen snapper werde ich jedoch grundsätzlich das Upgrade ohne Neuinstallation durchführen. Da bei einem solchen Upgrade der jeweilige Snapshot sehr groß ist, kann man mit dem Space für die root-Partition (ich habe eine SSD von 256 GB alleine für /root bereitgestellt, da das einst parallel installierte Windows komplett herausflog - und eine normale Disc für /home) an die Grenze stoßen. Deshalb sind hier: "https://en.opensuse.org/SDB:System_upgrade" entsprechende Hinweise enthalten, damit das nicht geschieht. Hat man aber sehr viel Platz - z.B. 256 GB wie ich - dann kann man diese Hinweise getrost links liegen lassen.

    Moin!

    Vor zehn Tagen hatte ich ein Upgrade von Leap 15.2 auf Leap 15.3 durchgeführt. Mit den Aktualisierungen der nun neu hinzugekommenen Enterprise Repos gab es Probleme, so dass ich einige Tage - solange ich Leap 15.3 nutzte - nur ein Zypper-up durchführte. Fast alles lief zwar ansonsten reibungslos, nur bei fast jedem Booten war der Ton auf Null. Mal ja, mal nein. In den Plasma-Systemeinstellungen war es dann immer nötig, einmal auf die Soundeinstellungen für die Lautstärke zu klicken - dann lief es. Scheinbar wird die Einstellung der Lautstärke nicht immer übernommen, sondern auf Null gesetzt - was nervte. Nach umfangreicher Recherche und dem beherzigen von vielen Tricks zu diesem Problem mit dem Sound gab ich schließlich auf. Nun bleibe ich erst einmal bei Leap 15.2.

    Unter Windows kann ich es nachvollziehen, die Festplatte

    wegen der installierten Programme einfach in die neue

    Hardware-Umgebung einzubauen.


    Unter Linux ist die ganze Angelegenheit jedoch so User-freundlich,

    dass man da auch nach einer neuen Installation die Konfigurationsdateien

    im /home Verzeichnis beibehält, weshalb es anzuraten ist /home auf

    einer separaten Platte oder auf einer eigenen Partition zu haben. Bei

    der neuen Installation werden die meisten Programme dann sowieso

    installiert und deren Einstellungen ändern sich i.d.R. auch nicht -

    sie werden ja aus dem /home Verzeichnis übernommen. Was noch fehlt,

    installiert man nach - was ja nun wirklich kein Hexenwerk ist.


    Damals machte ich den Festplattentausch in eine neue Hardware-Umgebung

    eben auch nur wegen Windows - denn ich hatte ein Dualboot-System.

    Linux störte sich so gut wie nicht - aber Windows streikte dann. Erst durch das

    Nachinstallieren der Chipsatz-Treiber unter der Reparaturkonsole konnte ich

    auch Windows nutzen.


    Seit langem habe ich aber einen "Pure-SuSE" Rechner. Schon Nerven ...

    ich habe es immer eilig, habe keine Geduld und der Rechner muss machen

    was ich will!


    Was Du da vorhast - Sieglinde 389 - mit dem Pflegen eines Linux-Systems

    in einer virtuellen Maschine und das dann per gparted auf eine neue

    Hardware-Umgebung übertragen ... nööö! Das wird nicht funktionieren,

    denn VBox erstellt ja eine virtuelle Festplatte und diese unterliegt einem

    ganz anderen Management: Einem, das den Anforderungen in der jeweiligen

    gewählten virtuellen Maschine entspricht, weil das Ziel eines solchen virtuellen

    Rechners auch ein ganz anderes ist.


    Aber vielleicht habe ich Dich auch verkehrt verstanden.

    Wie ich es verstehe, hast Du auf Deiner Platte eine komplette

    SuSE-Installation, die Du nun in eine neue Hardware-Umgebung

    einbauen willst.

    Sofern die neue Hardware - also z.B. Chipsätze des neuen Mainboards -

    vom Linux-Kernel unterstützt werden, sollte das System auch hochfahren.

    Das habe ich vor einigen Jahren durchgeführt, allerdings auf einem

    "MBR-System" - nicht auf einem "UEFI-System".

    Damals war das Mainboard und auch die GraKa sowie der Prozessor

    neu - also fast alles, auch der Chipsatz fürs Netzwerk!

    Ich wunderte mich, wie reibungslos das lief (Windows streikte dagegen).


    Damals hatte ich allerdings einen Proprietären Treiber für die Grafikkarte

    und der passte natürlich nicht für die neue! Bevor ich wechselte habe

    ich daher diesen Treiber deinstalliert und fuhr das alte System mit einer

    Vesa-Ansteuerung hoch (die wird dann automatisch gewählt). Auf dem

    neuen System installierte ich dann den Open-Source Treiber "radeonsi"

    für die AMD 7750HD Karte. Ist also schon etliche Jährchen her das Ganze.


    Der Linux Kernel auf dem alten System und auf dem neuen ist identisch

    und sollte vor Wechsel der Platte mit dem installierten Linux-Betriebssystem

    auf den neuesten Stand gebracht werden, falls man relativ neue Hardware

    in der neuen Rechner Umgebung hat.

    Eine Unterscheidung zwischen Fimware Kernel und anderen braucht es nicht,

    die Hardware-Erkennung nutzt die korrekten Treiber und bei der neuen

    Hardware-Umgebung sind das halt andere.


    Ich würde das Ding einfach einbauen und dann sehen - vielleicht müsste

    in der UEFI-Firmware "Secure-Boot" abgeschaltet werden.


    Gruß ...

    Du darfst schon Deine Meinung haben, wir sind hier im freien Land :)

    Was ich aber nicht verstehe? Wenn der neue Kernel nicht geht dann kannst Du noch immer mit dem alten Kernel booten.

    Ja - habe ich ja auch gemacht.

    Inzwischen läuft ja auch der ***60er Kernel mit dem AMD Treiber,

    siehe Thread: "Nach Sicherheitsupdate Leap 15.2 startet Grafik nicht mehr".


    Trotzdem ist es ein gravierender Fehler, der nun zweimal auftrat.

    Beim ersten Mal als das auftrat, wurde allerdings - sicher durch meinen Fehler auch

    wenn ich Anweisungen befolgte - der vorherige Kernel wegen eines Korrekturversuchs überschrieben

    und nun lief nichts mehr.


    Über ssh installierte ich über yast damals dann zwar den alten Kernel, aber die Grafik wurde

    wegen inkompatibler Grafikeinstellungen nur im Vesa-Modus angezeigt. Da war einiges kaputt

    gegangen.

    Über das BTRFS-Filesystem machte ich ein "Rolling Back" und schon war alles wieder klar -

    natürlich mit altem Kernel.


    Dann kam einen Monat später der korrigierte Kernel bis nun das Spiel wieder von vorn losging.


    Nun habe ich die "wasweissich.conf" - war es zypp.conf (?) so geändert, dass die letzten fünf Kernel

    behalten werden - sicher ist sicher und auf der SSD ist genug Platz.


    Ja - man lernt dazu, aber man macht das ja nicht jeden Tag :)



    Ganz hervorragend! Danke - das werde ich bei mir gleich ändern.


    Gruß ...