Hallo,
nach dem heutigen Kernel-Update funktioniert meine VMWare-Workstation 14.1.3 nicht mehr. Das Programm möchte wie üblich seine Module neu bauen, schafft das aber nicht. Die version.h habe ich ihm schon “unterschieben” können (einen Link angelegt), aber die vmmon und vmnet lassen sich nicht bauen. Im Log steht nur lakonisch:
Ergänzung: ich habe VMWare 14.1.3 deinstalliert und die neue Workstation Pro 15.0.0 installiert - und das Problem ist geblieben. - Da ich der einzige zu sein scheine, der dieses Problem hat, frage ich mal in eine andere Richtung: Lässt sich ein OpenSuse Leap neu aufsetzen oder ändern ohne dass man seine ganzen Daten erst mal auslagern muss? Gibt’s so eine Art “repair”-Programm?
@Sauerland: Danke für Deine Hilfe - ich weiß zwar nicht so recht, was ich gemacht habe, aber es hat erst mal keinen Schaden angerichtet. (Ich ahne, dass ich ein falsches Update-Repository ohne Nebenwirkungen rausgeworfen habe. Und was das Wundern betrifft: Es wundert mich in der Tat, dass ich das ohne dringliche Warnung habe aufnehmen dürfen. Und glaube mich auch zu erinnern, wann und in welchem Zusammenhang das gewesen sein muss. Aber das ist ein anderer Thread…)
Nur: die zypper-Ausgaben, die ich zur ersten Nachfrage gepostet habe, haben sich nicht verändert - und die VMWare-Module lassen sich noch immer nicht bauen. Ich denke, dass ich meinen aktuellen Kernel aus dem tumbletweed-Repository habe und auch wieder irgendwie loswerden muss.
Nur wie? (Aber vielleicht sollte ich erst mal in den Foren suchen, ist ja im Prinzip eine Veränderung des Themas)
Warnung: Sie sind im Begriff, eine Distributionsaktualisierung mit allen aktivierten Repositorys durchzuführen. Vergewissern Sie sich, dass diese Repositorys kompatibel sind, bevor Sie fortfahren. Weitere Informationen zu diesem Kommando finden Sie unter 'man zypper'.
Metadaten von Repository 'openSUSE-Leap-42.3-Update' abrufen ...fertig]
Cache für Repository 'openSUSE-Leap-42.3-Update' erzeugen ....fertig]
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Distributions-Aktualisierungen werden verarbeitet...
Die folgenden 16 NEUEN Pakete werden installiert:
digikam-doc freeipmi kernel-default-4.4.155-68.1 kernel-default-devel-4.4.155-68.1 kernel-devel-4.4.155-68.1 kernel-source-4.4.155-68.1 kernel-syms-4.4.155-68.1 libapr1-devel libapr-util1-devel libpowerman0 libtxc_dxtn libupsclient1 nut nut-cgi perlref unrar
Die folgenden 8 Pakete werden GELÖSCHT:
apr-devel apr-util-devel gcc8 libasan5 libgd3 libopenssl-1_1-devel openssl-1_1 s2tc
Die folgenden 49 Pakete werden durch eine ältere Version ausgetauscht:
apache2 apache2-devel apache2-doc apache2-example-pages apache2-prefork apache2-utils gd glibc glibc-devel glibc-extra glibc-locale kernel-macros libapr1 libapr-util1 libatomic1 libdbus-1-3 libgcc_s1 libgomp1 libitm1 liblsan0 libmpx2 libmpxwrappers2 libnsl2-32bit libopenssl1_0_0 libopenssl1_0_0-32bit libopenssl-devel libreoffice-branding-upstream libtirpc3-32bit libtsan0 libX11-6 libX11-data libX11-devel libX11-xcb1 libz1 lsof MozillaFirefox MozillaFirefox-translations-common mozilla-nss nscd openssl pesign pesign-obs-integration poppler-tools shadow systemd-logger valgrind zlib-devel zypper-aptitude zypper-log
Die folgenden 2 Pakete werden die Architektur ändern:
libopenssl-devel
noarch -> x86_64
openssl
noarch -> x86_64
49 Pakete werden zurückgestuft, 16 neue, 8 zu entfernen, 2 Architekturwechsel.
Gesamtgröße des Downloads: 251,4 MiB. Bereits im Cache gespeichert: 0 B. Nach der Operation werden zusätzlich 729,7 MiB belegt.
Fortfahren? [j/n/...? zeigt alle Optionen] (j):
Warum hast du Kernel 4.18 installiert?
Gibt es dafür eine Grund?
Wenn nein, mach ein
zypper dup
Und bevor du neu startest, würde ich einfach Yast----System----Boorloader aufrufen, dort aber nichts ändern und nur auf ok klicken, um den Bootloader noch einmal schreiben zu lassen.
Erst jetzt neu starten.
Der Kernel 4.18 kam beim Update mit rauf - ich wüsste nicht, wofür ich es unbedingt brauche. Der zypper dup stellte nun aber 4 Dateikonflikte fest und empfahl mir den Abbruch:
4 Dateikonflikte festgestellt:
File /lib64/libnss_nis.so.2
from install of
glibc-2.22-19.1.x86_64 (openSUSE-Leap-42.3-Update)
conflicts with file from package
libnss_nis2-3.0-2.3.x86_64 (@System)
File /usr/bin/rpcgen
from install of
glibc-devel-2.22-19.1.x86_64 (openSUSE-Leap-42.3-Update)
conflicts with file from package
rpcgen-1.4-1.2.x86_64 (@System)
File /usr/share/doc/packages/kernel-syms/README.SUSE
from install of
kernel-syms-4.4.155-68.1.x86_64 (openSUSE-Leap-42.3-Update)
conflicts with file from package
kernel-syms-4.18.7-1.5.x86_64 (@System)
File /usr/share/man/man1/rpcgen.1.gz
from install of
glibc-devel-2.22-19.1.x86_64 (openSUSE-Leap-42.3-Update)
conflicts with file from package
rpcgen-1.4-1.2.x86_64 (@System)
Dateikonflikte treten auf, wenn zwei Pakete versuchen, Dateien mit demselben Namen, jedoch anderen Inhalten zu installieren. Wenn Sie den Vorgang fortsetzen, werden die im Konflikt stehenden Dateien ersetzt, wobei der bisherige Inhalt verloren geht.
Fortfahren? [ja/nein] (nein):
Während oder nach der Installation/dem Entfernung von Paketen ist ein Problem aufgetreten:
Installation aborted by user
In der Fehlermeldung oben finden Sie einen entsprechenden Hinweis.
Ich bin mir zwar relativ sicher, die openSUSE-Versionen haben zu wollen, hatte aber noch nicht das Problem, im System bei Dateikonflikten entscheiden zu müssen (bei eigenen Sourcen weiß ich, wie’s geht), hier fehlen mir jegliche Entscheidungsgrundlagen und auch das Wissen, wie ich die beseitige. Hilft mir zypper dabei oder muss ich mit anderen Werkzeugen aktiv werden?
Dankbar für einen Tip.
Es scheint, ich kann fortfahren. - Ein Neustart nach Bootloader-Update lädt aber nach wie vor den Kernel 4.18 - und VMWare verlangt bei einer Neuinstallation nach einem gcc8, der aber nicht in der Liste der Pakete gefunden wird. - Hmm… wirklich besser ist es nicht
gelernt und das gleich mit kernel-Paketen. Nun lud sich der richtige Kernel ins System und nach einer Neuinstallation von VMWare läuft diese “Kiste in der Kiste” nun auch wieder. Danke Sauerland aus dem Sauerland.
Wo darf man das Problem jetzt als “erledigt” markieren?
<F>
Wo darf man das Problem jetzt als “erledigt” markieren?
Gibt es hier nicht…
Übrigens, das Problem war das factory Repo bzw. das daraus einige Pakete installiert worden sind und nicht alles darauf umgestellt worden ist…
Dann wär es auch kein Leap 15 mehr gewesen…
There are different organizations running from Twenty20, played over a couple of hours with each group batting for a solitary innings of 20 overs, to Test matches, played more than five days with boundless overs and the groups each batting for two innings of boundless length. Cricket Match Highlights