Beiträge von Hidalgo

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.

Die Guest Additions bzw. Guest Extensions werden zwar mit

installiert, aber nicht automatisch im System der jeweiligen VM

(bei dir Linux Tumbleweed) eingepflegt.

Das muss erst noch geschehen, ansonsten kann der Grafikspeicher

u.a. nicht erweitert werden.

Das VBox Manage Tool - welches ja in der Konsole ausgeführt wird -

greift auf dieselben Voraussetzungen zurück, wie die Einstellmöglichkeiten

im User Interface von Virtual-Box. Sind diese Voraussetzungen aber nicht

erfüllt, weil die Extensions fehlen, dann gibt es nur Standarteinstellungen.

Da nutzt es natürlich nichts, wenn man in die Konsole wechselt.

Die Extensions werden mit einem virtuellen Datenträger simuliert.

Dieser Datenträger ist nach der Installation der Extensions im Menü von

VirtualBox zu finden und dessen zusätzliche Installation muss dann auch

erst darüber angestoßen werden.

Ist man dann im laufenden virtuellen Betriebssystem, dann ist mit

diesem Betriebssystem ebenfalls das Extension-Paket, also die entsprechende

virtuelle CD-ROM anzuwählen und zu installieren. Dann erst entfalten

die Extensions ihre Funktionalität auch dort (und nicht nur in den Voreinstellungen

vor dem Start des Gastsystems)

Der Fehler

"Could not launch the VM process for the machine 'Windows' (VERR_ACCESS_DENIED)"

erscheint dann, wenn das für VirtualBox zuständige

Kernelmodul nicht zum verwendeten Kernel passt.

Auch ohne die "extensions" würde VirtualBox übrigens laufen.

Diese erzeugen auch nicht den Fehler, wenn diese nicht installiert werden.

Es fehlen dann halt' nur das Tuning, z.B. die USB 3 Unterstützung sowie Grafikbeschleunigung.

Ich habe damals (vor einigen Jahren) immer die VBox Pakete direkt von

Oracle prädestiniert. Im Gegensatz zu den SuSE Paketen wird dort das

o.a. Kernelmodul nicht mitgeliefert, sondern aus den Kernel-Sourcen

bei der Installation generiert. Deshalb müssen bei diesem Weg außer dem

Kernel die dazu passenden Sourcen installiert werden.

Zwar entfällt das bei der SuSE-Installation von VBox, aber bei einem

neuen Kernel erhält man meist auch wieder eine Fehlermeldung. Bei

SuSE kann es dann ein wenig dauern, bis das jeweilige Kernelmodul zu

dem aktuellen Kernel nachgeliefert wird und VBox bleibt solange tot.

Mit den zu einem neuen Kernel auch neu installierten Kernelquellen

(den Sourcen) wird dann aber bei einem erneuten Anstoß der Oracle

Pakete von VBox das passende Modul gleich wieder generiert und - voila!

Bei Tumbleweed wechselt der Kernel öfter auf eine aktuellere Version,

so dass dort diese Fehlermeldung auch öfter auftauchen dürfte. Dann

steht man evtl. auf dem Schlauch, weil die angepasste Version für VBox

von SuSE noch nicht geliefert wird. Ist diese dann da, kommt wieder ein

neuerer Kernel usw.

Aber auch bei Tumbleweed sollte mit den Kernel-Quellen und dem VBox

Paket von Oracle direkt bei neuer Installation das passende Modul generiert

werden.

Wie gesagt, die Extensions sind zwar wichtig, diese verbessern aber nur die

Funktionalität und erzeugen nicht den Fehler.

Übrigens:

Seit Jahren nutze ich VBox nicht mehr, aber wenn sich irgendwelche

Abläufe bzgl. VBox nicht grundlegend geändert haben, gilt meine Erfahrung

nach wie vor.

Es gibt auch noch das Paket dkms, womit fehlende Kernel-Module auch in

VBox schneller zur Verfügung gestellt werden sollen (ohne dass diese aus den

Kernel-Quellen generiert werden müssen, betrifft auch Grafikkartentreiber o.ä).

Hat bei mit aber nicht überzeugend funktioniert - mehr kann ich dazu nicht sagen.

Zitat von Sandy

Deswegen Hidalgo bemerkte ich ja primär, dass dieses Aktualisierungsproblem auch bei 15.3 nicht mehr vorlag.

Und sagte, dass sich meine Frage damit erledigt hätte. (#6)

Klagst Du mich dafür an, dass ich trotzdem eine interessante Antwort bekam?

Woher das Gefühl eine Anklage bei Dir kommt weiß

ich nicht, dafür bist Du verantwortlich.

Beim anfangs gestellten Thema/Problem in einem Thread zu bleiben ist praktisch

und dient der Übersichtlichkeit, weil man bei ähnlichen Problemen hier im Forum

entsprechend recherchieren kann.

Das klappt umso besser, wenn das jeweilige Thema beibehalten wird.

Hier wurde das Thema geändert und dein Verhalten ändert da ja nichts dran.

Alles rein sachlich!

Der Thread dreht sich um

"Fehler bei Aktualisierung"

Deine Frage, Sandy, behandelt aber ein anderes Thema und

wurde inzwischen dahingehend beantwortet, dass man

die Notwendigkeit von Software bzw Softwarekomponenten

nur für sich selbst beantworten kann. Ist man unsicher,

muss man eben recherchieren.