Ist meine Festplatte defekt oder kann es daran liegen, daß ich vorher beim Neustart noch eine externe Festplatte über USB angeschlossen hatte.
Letzteres kann schon sein, falls Du die Partitions über die Device-Bezeichnungen wie /dev/sda1 referenzierst und nicht wie empfohlen über UUIDs.
Dann kann es nämlich sein, dass die USB-Festplatte plötzlich zu /dev/sda wird und die interne Festplatte zu /dev/sdb und schon wird die Root-Partition nicht mehr gefunden...
NAME="openSUSE Leap"
VERSION="15.2 Beta"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.2"
PRETTY_NAME="openSUSE Leap 15.2 Beta"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"gelöscht
gelöscht
Nein, ich setze die 15.2 nicht als Produktionssystem ein, sondern habe eine Test-VM, die meiner Arbeits-VM sehr ähnlich ist und die mich durch die ganze Alpha-, Beta-, und RC-Phase begeleitet. Hat den Vorteil, dass ich alle Nickeligkeiten, die durch die neue Version entstehen, früh und vor allen Dingen nach und nach finde und meine Anpassungs-Kapazitäten nicht überlastet werden.
Und ja, natürlich mache ich während der Alpha-, Beta- und RC-Phase ein "zypper dup" und kein "zypper update".
Trotzdem ist meine 15.2 immer noch als Beta tituliert (übrigens auch noch nach einem grub2-mkconfig) und ich frage mich, was beim Originalposter anders ist...
Und irgendwas mach ich falsch, hab grade auch den letzten Update gemacht, mein 15.2 meldet sich aber immer noch als "Beta", sowohl im grub wie auch beim Boot-Vorgang wie auch auf der Text-Console... Auch ein "dracut --force" ändert nichts daran...
Wird denn an dem beabsichtigten Termin im Mai festgehalten oder gibt es Verzögerungen aufgrund der Corona-Krise?
Die Fehlermeldung sagt mir, dass die Applikation fehlerhaft arbeitet.
Die Applikation nutzt offensichtlich Funktionen der MIT-SHM-Extension, ohne sich vorher davon versichert zu haben, dass diese auch wirklich nutzbar ist, was bei einem Remote-Display aber nicht gehen KANN (genaue Erklärung weiter unten).
Es dürfte einen Workaround geben: Starte auf Deinem Linux-Rechner auf der Arbeit Xephyr. Das ist ein "zwischengeschalteter" X11-Server, der diese Extension beherrscht. Also in etwa so:
/usr/bin/xinit /usr/bin/xterm -- /usr/bin/Xephyr :1(evtl. sind weitere Switches bei Xephyr nötig, u.a. um die Größe des Fensters anzugeben).
In dem xterm dann die Applikation starten.
Zur genauen Erklärung:
X11 schickt sämtliche Daten eigentlich über einen Socket - bei lokaler Darstellung über einen Unix-Socket und bei Remote-Darstellung über einen Netzwerk-Socket. Da das bei lokaler Darstellung bei großen Datenmengen und/oder langsamen CPUs ein Performance-Bottleneck sein kann, hat man irgendwann die MIT-SHM-Extension erfunden. Damit können Grafik-Daten per Shared Memory übertragen werden, was effizienter ist. Allerdings muss das mit entsprechenden Funktions-Aufrufen, die in der Extension enthalten sind, implementiert werden.
Im Netz funktioniert das logischerweise nicht, da es kein Shared Memory zwischen mehreren Rechnern geben kann.
Eine "saubere" Applikation probiert zunächst mal, ob die Extension nutzbar ist und wenn nein, werden die Daten halt doch per Socket übertragen. Es gibt aber Applikationen, die sich das Leben einfach machen und die Fehler halt einfach ignorieren. Die funktionieren dann halt nicht mit Remote-Darstellung. Und wenn es eine kommerzielle Applikation ist, ist halt die Remote-Darstellung nicht supported und man kriegt erzählt, dass das sowieso schlecht funktioniert, langsam ist und mit Wayland sowieso demnächst verschwindet...
Aber mit Xephyr sollte es eigentlich trotzdem gehen...