Beiträge von Hidalgo

Das Problem hatte ich gestern auch.

Habe einfach eine Online-Aktualisierung mit Yast durchgeführt

was ja dasselbe ist wie ein "zypper - up" in der root Konsole

und siehe da: "Ihr System ist auf dem neuesten Stand" erschien.

Ich will mal versuchen etwas Licht ins Dunkel für Deine Frage

zu bringen:

Diese "SLE-Patches kommen von der kommerziellen Schiene

SuSE-Linux-Enterprise. Letzteres hat i.d.R. volle Kompatibilität zu

OpenSuSE Leap für den Privatanwender und dessen Sicherheitspatches

können demzufolge auch für Privatanwender angeboten werden.

Professionelles Enterprise färbt sozusagen auf die Leap-Schiene ab

(was ich durchaus begrüße).

Das SLE-System wird bezahlt und professionell unterstützt

(wie bei Windows) und das Leap-System für den Privatanwender

obliegt der eigenen Verantwortung des Users.

Gegenüber Software aus dem Packman-Repo, das ja Leap Anwender

(und auch Tumbleweed-User) nutzen,

sind die SLE-Patches nicht vollumfänglich getestet und so kommt es manchmal

zu solchen Fehlermeldungen. Die zwei anderen SLE-Patches 2970-1 und

2971-1 liefen demgegenüber einwandfrei durch.

Dass das System meckert, wenn diesem die Software eines

ganzen Repos "weggerissen wird", ist nicht zu vermeiden

und das sollte nicht verunsichern, bzw. da muss man durch.

Man kann sich vorstellen, dass ja Abhängigkeiten zwischen den

Dateien aus diesem Repo bestehen. Nehme ich z.B. nur eine Datei

"A" weg und es besteht eine Abhängigkeit mit einer Datei "B",

dann meckert natürlich Datei "B". Umgekehrt dasselbe.

Nehme ich nun aber beide Dateien weg, dann ist Ruhe und

auch das "Rest-System" ist ok. Abhängigkeiten bestehen nun nicht

mehr, bzw. lösen sich auf.

Bei solchen tiefgreifenden Änderungen des Systems ist die

Überprüfung auf Abhängigkeitskonflikte überfordert und der

User wird sich dann auch nicht verunsichern lassen müssen wenn

er weiß woran das liegt.

So gibt es immer Ausnahmen zur Regel - immer und überall.

Um bei mir etwaige Unsicherheiten trotzdem zu beseitigen und

sicher zu gehen, ob mein System nun konfliktfrei läuft, würde

ich im Terminal einfach mal ein

zypper update

durchführen - oder in Yast eine Online Aktualisierung durchführen.

Kommen dann keine Fehlermeldungen würde ich spätestens dann

davon ausgehen dass das System fehlerfrei ist. Ansonsten

Du hast keine 5GHz fähige Fritzbox, wenn ich das richtig sehe.

Auf 2,4Ghz ist die Bandbreite relativ begrenzt und wenn sich da

mehrere Kanäle zeitabhängig tummeln / benutzt werden, dann

beeinflusst das die WLAN Qualität in dem Bereich und Verbindungen

können dann sporadisch zusammenbrechen.

Deshalb erweiterte man auf 5 GHz.

Wenn Du aber in einer eigenen Burg wohnst mit weit und breit

keinen Nachbarn in der Nähe, dann liege ich falsch!

Dann reichen 2,4 GHz

In Yast kann man die ignorierten Abhängigkeitskonflikte in Menü "Extras" zurücksetzen

und dann diese neu prüfen. Manchmal ist da etwas im Verlaufsspeicher und wenn man

den nicht zurücksetzt, werden die eigentlichen Fehler ignoriert.

Das würde ich nochmal machen und falls das die erneute Prüfung dann einwandfrei

ist, ist Dein System auch in Ordnung in Bezug auf Abhängigkeiten.

Zu den Repos in Tumbleweed kann ich wegen des Leap-Systems

bei mir schlecht etwas sagen, aber

so wie ich das sehe - falls ich das richtig sehe - würde ich das

/mingw:/win32

Repo zumindest deaktivieren und nur das 64er nutzen.

Im Hinterkopf habe ich, dass gleiche Dateiversionen in unterschiedlicher

Bit-Architektur sich ins Gehege kommen können.

Das da:

zypper remove /usr/i686-w64-mingw32/sys-root/mingw/bin/iconv.dll

zypper remove /usr/i686-w64-mingw32/sys-root/mingw/bin/libiconv.dll

würde ich machen, wenn nach Abschalten des o.a Repos der Fehler

noch auftritt.

Vorher kannst Du diese beiden .dll-Dateien ja händisch ion Dein /home

sichern falls diese noch gebraucht werden sollten.

Wenn man seine Repositories (Software-Quellen) nicht auf das unbedingt Notwendige

beschränkt, dann können beim Aktualisieren unterschiedliche Pakete abgerufen werden

die die selbe Datei dem Namen nach enthalten und sich deshalb dem Aktualisierungsprozess

aufdrängen. Diese Dateien haben zwar den selben Namen, aber einen unterschiedlichen

Entwicklungsstand und nun entsteht der Konflikt und die entsprechende Nachfrage.

(dieser Prozess kann schließlich nicht wissen was der User braucht und mit seinem System will)

So etwas ist nicht gewollt, nicht schön, aber Linux-Typisch, da Entwicklungen an diesem

System weltumspannend stattfinden und ein 100%iger Abgleich nicht immer gewährleistet sein

kann.

Demgegenüber arbeitet an Windows nur Microsoft bzw. hält die Hand vor Veröffentlichungen

von "Zu-Entwicklern".

Soweit zum Verständnis.

Damit so etwas gar nicht auftritt, gibt "auch" die OpenSuSE-Distri Empfehlungen, welche

Repositories man verwenden sollte, denn ein "zuviel" ist schädlich (aus genannten Gründen).

So ist nämlich gewährleistet, das jedes Paket / jede Datei nur einmal vorkommt.

Soviel zur Auflösung des Problems generell.

Akut hast Du es ja schon durchgeführt, d.h.

unterschiedliche Dateien wurden nun ersetzt

durch die aktuellste, die in deinen Repos enthalten ist.

Falls Du Dir nicht sicher bist, ob Dein System nun konfliktfrei funktioniert, kannst Du

z.B. in Yast gehen, dort in Software installieren oder löschen gehen und dann dein komplettes

System auf Abhängigkeitskonflikte überprüfen lassen. Geht Ruckzuck.

Das geht auch in der Konsole ohne Yast. Bitte selbst 'raussuchen.

Generell versucht ein Linux-System Redundanzen zu vermeiden, was

durch ein inkonsequentes Repo-Überangebot leider unterlaufen werden kann.

Auch welche Repos Du brauchst und welche überflüssig sind, auch das ist für

OpenSuSE im Netz zu finden.

WLAN-Verbindungen können bei einem ungünstigen Standort zum

Router / Access-Point schon mal ausfallen. Das kann auch sporadisch

auftreten. Störungen können z.B. durch Funktastaturen / Mäuse ausgelöst

werden, da diese im WLAN Frequenzbereich kommunizieren.

Auch die WLAN-Versorgung ist in den Räumen niemals homogen und

kann durch Abschattungen behindert sein.

Mein SP (Smartphone) hat in unmittelbarer Entfernung zum Router

ebenfalls kein WLAN-Empfang - also pauschal zu sagen

"Je näher an der Quelle = umso besser" stimmt so nicht.

Jede Antenne hat Stärken und Schwächen.

Nur Kabelverbindungen sind wirklich perfekt. WLAN funktioniert

demgegenüber meistens, braucht aber zusätzliche Energie.

Auch Teilreflexionen können zu Interferenzen und somit Auslöschungen

der elektromagnetischen Wellen führen.

Die eingebauten Empfangsantennen haben auch unterschiedliche

Qualitäten. Dazu kommen noch 2,4 GHz Netze und 5 GHz Netze

und auch Beeinflussungen durch liebe Nachbarn sind da und können

sich auch ändern.

WLAN eben! Ist kein Linux Problem.

So müsste es klappen, Dein installiertes System entsprechend umzustellen.

Falls etwas schief geht: Ohne Gewähr und auf eigene Verantwortung!

Ich würde es so machen wenn es mein System wäre:

In Yast den Partitionierer starten

/dev/nvme0nlp1 unter /boot/efi aushängen

/dev/ nvme1n1p1 mit dem Mountpoint /boot/efi einhängen

(damit ist nun der richtige efi-Ort gewählt)

Das ganze ausführen lassen und

dann kann man auch gleich in Yast den Bootloader neu einrichten lassen,

dabei "anderes OS Testen" in den Bootloader Optionen anwählen,

damit der Kubuntu-Eintrag nicht überschrieben wird.

Letzteres ist vielleicht gar nicht nötig unter UEFI-Systemen

was ich mir vorstellen kann - aber ich weiß es nicht!

Ich hoffe es geht nichts schief!

Das Du Deine Daten sichern solltest im Falle eines Falles

weißt Du selbst.

Du siehst das richtig: SuSE sollte keine eigene EFI-Partition anlegen.

Das ist das Problem.

Ob Windows, Ubuntu oder SuSE-Linux, alle diese Betriebssysteme

sind ja UEFI konform und schreiben somit während ihrer

Installation eine entsprechende Kennung in eine EFI-Partition.

Das Bootmenü wird dann von der UEFI-Firmware des Rechners

geregelt. Diese fungiert auch als Bootmanager wenn mehrere Systeme

installiert sind.

Der grub Bootmanager tritt nur bei alten MBR-Systemen in Aktion

und wird bei UEFI nicht benötigt. Das darf nicht mit dem grub-Loader

verwechselt werden; der wird weiterhin zum Starten des Linux-Systems

benötigt.

Was mich stutzig mach, ist dieser Schritt bei der Partitionierung:

Partition /dev/nvme0nlp1 (512.00 MiB) unter /boot/efi einhängen

Denn das ist ja wieder eine weitere efi-Partition, die man aber gar nicht haben will.

Somit ist mMn. etwas bei der efi-Partitionierung falsch vorgegeben.

Die efi-Partition, die eingehängt werden soll, ist diese hier:

nvme1n1p1 0.50 GiB EFI-System-Partition Partition

Nämlich die von der SSD /dev/nvme1n1

Das ist die vom Ubuntu, bzw. Kubuntu-System. Die soll SuSE benutzen und

keine andere. Bei der Installation des Systems muss man das doch auch einstellen

können?

Dieser Hinweis:

Partition /dev/nvme0nlp1 (512.00 MiB) unter /boot/efi einhängen

sagt aus, dass wieder die vorhandene efi-Partition, die man aber gar nicht haben will

bzw. gar nicht braucht weil sie stört, genutzt wird.

Die kann eigentlich gelöscht werden.

Was Du also machst ist nichts Anderes als zwei eigenständige UEFI-konforme

Datenträger zu erstellen, die gar nichts anderes machen können als nur das

zu starten was sie in ihrer EFI-Partition eingetragen haben.

Du willst etwas Anderes:

Zwei verschiedene Systeme auf unterschiedlichen Platten von

einer EFI-Partition einer Platte starten können.

Dann müsste dazu meines Wissens nur die efi-Partition des Kubuntu-Systems

eingehängt werden unter /Boot/efi (siehe oben).

Das sollte man bei der Installation von SuSE auch so einstellen können.

Dazu dient der Experten-Modus oder schon der erweiterte Modus ...

das weiß ich jetzt nicht genau, so oft mache ich Installationen nicht

und weiß deshalb nicht wie die SuSE-Menüführung aktuell aussieht.

Ansonsten frage nach - hier gibt's viele kluge Leute wo die Praxis einer

kompletten SuSE-Installation sicher frischer ist als in meinem alten Gedächtnis!

Zitat von Feli

[snip]

Viele Möglichkeiten es gibt - finden wir müssen die richtige. 🍻

Ja.

Was mich auch noch beschäftigt:

Wenn die 2. Platte, die als erste Bootplatte im UEFI Menü des

Rechners eingestellt wird, problemlos Kubuntu startet, dann

muss diese m.E. so eingerichtet sein, dass auch dort sich

eine EFI - Startpartition befindet aus der heraus dann Kubuntu

gestartet werden kann (und wird).

Normalerweise hat man bei einem UEFI System doch nur eine

EFI-Partition auf nur einer Bootplatte, aus der heraus dann alle

Betriebssysteme gestartet werden können - egal auf welchen

Platten diese sich befinden.

Es geht mir darum:

Ohne EFI - Startpartition startet nichts. Dieselbe wird bei der

Installation festgelegt. Das ist dann das Bootmedium. In dessen

EFI Partition tragen die startbaren Systeme sich ein.

Wechsele ich nun einfach das Bootmedium (hier auf die zweite Platte),

dann befindet sich dort keine EFI-Partition und es startet: Nichts!

Es startet aber Kubuntu im vorliegenden Fall.

Darum vermute ich, dass die Installation vom User nicht konsequent

so durchgeführt wurde, dass sich auch Kubuntu in der ersten Boot-SSD

eingetragen hat. Darum findet das SuSE Grub auch den Kernel für Kubuntu

nicht (auch wenn startbare Betriebssysteme entdeckt werden - sie starten dann

trotzdem nicht, sind halt' nur im Bootmenü eingetragen).

Falls meine Logik Fehler hat, bitte ich um Aufklärung.

Falls nachvollziehbar, helfen diese Gedankengänge evtl. linuxchaot ?

Ich wüsste für Dein Problem nur ein Workaround,

ohne jetzt in die Details zu gehen.

Jedenfalls nutzt du zwei M.2 NVME SSD mit 1 TB und

Grub findet den Kernel des Kubuntu-Systems auf der

zweiten Platte nicht (die "Bad Signature" des shim ist

erst mal unwichtig).

Ursache ist: Der Kernel des Kubuntu-Systems wird nicht

gefunden, welches in der efi Startpartition eingetragen ist.

Behebung:

Beide root-Systeme auf die erste SSD legen, also für Leap und

Kubuntu und die User Filesysteme entsprechend des Bedarfs

auf den verbliebenen Plätzen anlegen.

Du schreibst, dass Du bei früheren Versionen das Problem nicht

hattest und erwähnst dabei Win-XP.

Ich gehe davon aus, dass Du zu der Zeit da noch kein efi bzw. UEFI-System

genutzt hast. Insofern ist das nicht vergleichbar.