Beiträge von Hidalgo

Habe noch einmal bei mir geschaut. Habe überhaupt kein "jack Audio Connection Kit" installiert, um den Audioserver und das Zusammenspiel mit diverser Audio-Software zu managen. Ich experimentierte damals damit, kam aber zu keinem brauchbaren Ergebnis. Vielleicht hängt es damit zusammen, dass seitens SuSE auf "Pipewire" Architektur umgestellt wurde. Bin kein Experte - vermute es nur!

Mit dem "Jack Audio Connection Kit" kam ich damals (vor etlichen Jahren, so sechs etwa) nicht weiter bzw. habe immer wieder daran "herumgefummelt". Mal lief Midi dann mit der einen Software und mit der anderen nicht. Habe es dann rigoros gelöscht, also alles was mit "jack" zusammenhing. Seitdem ist nur noch "libjack0" (die Audio Connection Kit Library) installiert.

Warum? Keine Ahnung! Weil aber alles bei mir so läuft wie es soll, lasse ich das so... es ist das einzige was noch mit "jack zu tun hat. Ist halt drauf.

Nach der Deinstallation von dem ganzen "Jack Krimskrams" gab es dann folgenden Effekt, DER VORHER NICHT FUNKTIONIERTE:

Es reichen die in der jeweiligen von mir benutzten Software dortigen Einstellungsmöglichkeiten (Input ... Output) aus, um MIDI (über Musescore), Aufnahmen mit Audacity, den Sequencer "Rosegarden" sowie den Drum Sequencer "Hydrogen" zu betreiben.

Der Vollständigkeit halber erwähne ich noch, dass ich manchmal den Eingang für Aufnahmen bei Audacity wechseln muss, obwohl nicht umgestöpselt wurde. Damit kann ich leben.

Rechner ist mindestens zwölf Jahre alt (Intel i3220T).

Hier

kann man über die Änderungen durch die pipewire Implementierung in Linux nachlesen.

Gruß vom Althippie - äh Hidalgo.

Zitat von Sauerland

Funktioniert alles, wenn man sich einliest....

Hab ich mal vor jahren gemacht.

Bestätigung. Bin selbst Hobbymusiker und war vor Jahren eigentlich erstaunt, dass alles so problemlos unter Leap funktioniert. Mein semiprofessionelles E-Piano (das auch zusätzliche Klänge beinhaltet) harmoniert wunderbar mit z.B. Musescore 3.6 (die neuere Version hat 'ne Macke). Noten kann ich einspielen, abspielen, begleiten. Vielleicht hatte ich auch einfach nur Glück mit meinem Instrumentarium. Alles was ich brauche lief auch immer nach jedem System-Upgrade problemlos.

Leider hilft das "Dark Trinity" nicht aber weckt vielleicht den Ehrgeiz? Ferndiagnose schwierig.

Da ich ein stabiles produktives System bevorzuge habe ich mich für Leap entschieden. Die Distributions Upgrades liefen immer und ausnahmslos problemlos ab, bzw. nehme ich diese in Kauf.

Tumbleweed ist demgegenüber nach meinen Erfahrungen nicht ganz so stabil. Weil hier die Prämisse auf aktuellste Software liegt, ist das zwangsläufig hinzunehmen. Probleme treten /traten aber auch hier eher selten auf und werden dann sehr schnell behoben - meist spätestens mit den Updates am nächsten Tag.

Wenn Probleme auftraten, dann nervten die auch. Kosten Zeit und man sucht ja erst einmal. Aktuellste Software benötige ich nicht, kommt früh genug für mich und Änderungen sind meist marginal bzw. bringen mir bei meiner Arbeit nichts; ist ja alles sehr ausgereift.

Probiere ansonsten beides aus. Viel Freude mit Deiner Entscheidung - mit welchem System auch immer.

Wenn der Rechner noch nicht so alt ist, muss oft nur der TPM-Chip im UEFI aktiviert werden, denn seit ca. 2010 werden diese Chips von namhaften Mainboard Herstellern verbaut. Dann kann man problemlos Windows 11 installieren. Viele wissen das gar nicht und kaufen sich einen neuen Rechner. Wie man den TPM CHIP - sofern vorhanden - aktivieren kann unterscheidet sich zwischen AMD und Intel Boards. Anleitungen dazu gibt es im Netz zur Genüge. "TPM aktivieren" eingeben.

Hallo,

Dein Problem hatte ein Nachbar von mir vor vielen Jahren auch!

Habe dann das Anschlusskabel von seinem Router zur Telefondose gewechselt, danach tauchte das Problem nie wieder bei ihm auf.

Habe sein Kabel mitgenommen und dann einfach bei mir mal mit dem vorhandenen ausgewechselt.

Dann hatte ich das Problem. Internet ging mal ein paar Tage, dann wieder nicht, sporadisch.

Kabel ohmsch durchgemessen - konnte nichts feststellen, d.h. Kabel hatte einwandfreien Durchgang. Somit sind wohl die HF (Hochfrequenz)-Eigenschaften betroffen gewesen die man mit einem normalen Messgerät nicht verifizieren kann. Aber das nur nebenbei. Auch Kontaktspray half nicht.

P.S.: Habe hier nicht alles Bisherige gelesen - falls also das Kabel schon gewechselt wurde ... schmeiß mich weg

Gruß

black_boot: Du hast Recht! In einem efi-System sind die Loader für die jeweilig installierten BS entkoppelt. Solche Probleme wie ich sie in #20 beschrieb sollten somit gar nicht mehr auftauchen. Der Fragesteller bzw. Hilfesuchende hat außerdem ein efi-System wie man unschwer erkennen kann; jedoch verknüpfte ich diese mit einem CSM-System, nicht zuletzt deshalb, weil bisher nichts half und ich selbst immer noch mit dem alten Bios unterwegs bin. Sorry!

matbhm: Glaube ich Dir! Siehe oben und danke für Deinen Hinweis. Die von mir beschriebenen Probleme sollten bei den (schon wieder recht lange) UEFI-Rechnern nicht mehr auftauchen.

Gruß ...

Vom Dualboot Windows / Linux kann ich nur abraten, da Grub2 durch jedes Windows Update i.d.R. zerschossen wird und Linux dann nur noch z.B. durch Rescutux oder Supergrub zu starten ist, also von einem USB Stick. Mann muss sich beim Dualboot darüber im Klaren sein, dass das Problem immer wieder auftaucht. Lösen konnte ich dieses Problem fast IMMER, indem ich ein Live-Linux (Rescutux oder Supergrub) zum Starten des Linux-Systems auf dem Rechner verwendete und dann in Yast den Bootloader neu generierte. Dort kann man durchaus vergessen, die korrekte Bootloader Position auszuwählen, was eine erste Fehlerquelle wäre.

ZUVOR ist wichtig, in Windows die Schnellstart Option zu deaktivieren. Ansonsten funzt die Wiederherstellung des Loaders mit Yast ebenso nicht.

Diesen ganzen Mist - und weil der praktisch mit jedem Windows Update auftrat - habe ich mir dann vereinfacht, indem ich den Bootloader sicherte und einfach wieder zurückspielte wenn der nicht mehr funktionierte:

So sichern Sie den Linux-Bootloader ➡️ ➡️ IK4 ▷ ➡️

So sichern Sie den Linux-Bootloader ➡️ So sichern Sie den Linux-Bootloader Obwohl es sich im Vergleich zu anderen Linux-Bootloadern um ein zuverlässiges Tool…

ik4.es

Das ist eine Quelle, wie man das bewerkstelligen kann.

Eine weitere Möglichkeit, den Bootloader wieder herzustellen besteht mit dem mächtigen Chroot Kommando in der Konsole:

https://www.thinkretro.de/blog/2016/03/06/grub-bootloader-in-einer-chroot-umgebung-wiederherstellen/

Besonders die letzten beiden Tipps kosten aber etwas Zeit und man muss wissen was man tut, d.h. man sollte die einzelnen Schritte verstehen und nachvollziehen können. Das verschafft einem "Sicherheit durch Wissen" (man wird zum echten Linuxer). Wichtig ist ja, dass man externe Tipps auf sein eigenes System konvertieren muss. Einfaches Kopieren von Anleitungen hat schnell seine Grenzen - solche Leute sollten besser bei Windows oder einem Mac bleiben und das meine ich NICHT abwertend! Von einem Dualboot rate ich aus genannten Gründen ab. Ich habe einen reinen Linux Rechner und einen nur für Windows.

Seit vielen Jahren macht Linux bei mir Null Probleme seitdem, bzw. werden unnötige Probleme beim Dualboot durch Microsofts Verhalten generiert!

Noch etwas (leider!): Erfahrungsgemäß verweigert Microsoft gerne das Aufspielen von Updates, wenn die Diagnose ein Linux-System auf der Platte findet bzw. den entsprechenden Loader (Grub). In so einem Fall bleibt der Loader unangetastet, aber Windows wird eben nicht geupdatet. Das ist alles Schikane und ansonsten durch nichts gerechtfertigt.

Gruß...

Wenn du den proprietären Treiber von AMD für deine RX 550 nutzen solltest, so würde ich den deinstallieren und die Karte mal mit dem Radeon betreiben. Die Karte wird meines Wissens ja direkt vom Kernel unterstützt.

Sound wird durch suboptimale Grafiktreiber (geht nicht um maximale Leistung, sondern um den einwandfreien Betrieb) gerne gestört (eigene Erfahrung).

Zitat von Feli

Ich hab das mal nachgestellt - erst Kubuntu 22.04 installiert, danach dann Suse-Leap 15.4

Code

Model: ATA HITACHI HTS72323 (scsi)
Disk /dev/sda: 320GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name            Flags
 1      1049kB  106MB   105MB   fat32        Efi             boot, esp
 2      106MB   26.3GB  26.2GB  ext4         Kubuntu-System
 3      26.3GB  78.7GB  52.4GB  ext4         Kubuntu-Home


Model: ATA INTEL SSDSA2BW16 (scsi)
Disk /dev/sdb: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name         Flags
 1      1049kB  26.2GB  26.2GB  ext4         Suse-System
 2      26.2GB  78.6GB  52.4GB  ext4         Suse-Home

Alles anzeigen

Leap steht an erster Stelle im UEFI-Menü

Das Kubuntu lässt sich völlig problemlos über das Grubmenü von Leap starten,

Das sollte der Normalfall sein.

Zwei Systeme auf verschiedenen Platten, Starten über UEFI-Auswahl

oder auch grub kein Problem.

Danke für die Mühe!

Wie Du schon anmerktest, können mit UEFI die Betriebssysteme problemlos

auf mehreren Festplatten verteilt werden, wobei dann nur eine EFI-Partition

(auf nur einer Festplatte) ausreicht, um alle Systeme starten zu können. In

diesem Punkt war ich mir auch nicht ganz sicher, weshalb ich ja um den Versuch

bat, mal die beiden Linux-Systeme auf nur eine Festplatte "zu nageln".

Es gibt bei UEFI zwei Wege, alle eingetragenen BS zu starten:

Entweder der über das UEFI-Bootmenü,

oder

derjenige über den Grub-Bootmanager.

Beides sollte problemlos funktionieren, es sei denn Grub arbeitet in

einem UEFI-System fehlerhaft.

Ich würde - falls ich Dualboot unter UEFI benötige - immer den

Weg über das UEFI-Bootmenü gehen, weil:

Es ist dann nicht mehr notwendig, einige Sekunden den Grub-Bootmanager

das Auswahlmenü anzeigen zu lassen. Dann hat man den schnellsten Start

und der Zugriff auf das jeweils andere System ist bei Notwendigkeit auch

gegeben. Das Detektieren eines anderen Betriebssystems und die Eintragung

in das grub-Bootmenü erübrigt sich ebenfalls.

Hintergrund: Ob unter herkömmlichem MBR-System oder unter UEFI,

bei beiden Methoden wird immer der Loader des Kernels gestartet,

bei Linux macht das Grub. Es ist im Prinzip kein Problem, den in grub

integrierten Bootmanager ebenfalls wie gewohnt funktionieren zu lassen.

Im letzten Fall sieht der User dann allerdings keinen Unterschied zwischen

MBR-Bootsystemen und UEFI-Systemen.

-----------------------------------

Nebenbei:

Mit Dualboot gab es immer mal wieder "Problemchen" auch bei mir. Das

war noch unter den veralteten Bios (MBR) Systemen so.

Darum hatte ich zwei Festplatten eingebaut und jede einzelne für sich

mit Betriebssystem ausgestattet. Das jeweilige OS habe ich dann

(zugegebenermaßen umständlich) über das Bios ausgewählt, d.h.

entweder von sda oder sdb gebootet.

Somit hatte ich eigentlich auch im alten System eine Entkoppelung.

Auch beim MBR-System konnte ich dann allerdings auch den Bootmanager von

der "sda-Platte" bemühen, um das Betriebssystem von der zweiten sdb

Platte zu starten. Umgekehrt lief das auch so mit dem Bootmanager auf

sdb, um das OS auf sda zu starten.

Genau deshalb wäre es ein Unding, wenn das Starten eines weiteres OS auf

einer weiteren Platte nicht auch unter UEFI möglich wäre.

In diesem Thread liegt wohl ein Fehler in grub vor, was der Vielzahl an

möglichen Festplatten-Konstellationen (z.B. mit NVME oder nicht) geschuldet

sein mag. Das wird sicher auch noch behoben werden - irgendwann.