Cześć po aktualizacji do Ubuntu 17.10, vmware nie uruchamia się teraz.
Dostaję wiadomość:
/usr/lib/vmware/bin/vmware-modconfig: Relink `/lib/x86_64-linux-gnu/libbsd.so.0' with `/lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol `clock_gettime'
Wiem, że są dostępne łatki i staram się je zastosować i ponownie skompilować. Uruchomiłem z rozwiązania na https://communities.vmware.com/thread/571370 :
cd ~
#Copy the vmmon source tar ball to your temporary location
cp /usr/lib/vmware/modules/source/vmmon.tar .
#Extract the tar ball
tar xf vmmon.tar
#Download the modified file that mkubecek posted and overwrite the one from the tar ball for VMware Workstation 12.5:
wget -O ./vmmon-only/linux/hostif.c https://raw.githubusercontent.com/mkubecek/vmware-host-modules/b50848c985f1a6c0a341187346d77f0119d0a835/vmmon-only/linux/hostif.c
#Wrap up the newly modified files into a tar ball replacing the original one
sudo tar cf /usr/lib/vmware/modules/source/vmmon.tar vmmon-only
#Rebuild the VMware kernel modules
sudo vmware-modconfig --console --install-all
Failed to get gcc information.
gcc --version
gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0 ...
Niestety, vmware-modconfig nie działa z powodu zależności, która wydaje się na konkretnej wersji gcc. Czy jestem na dobrej drodze? Jakakolwiek pomoc w tej kwestii byłaby bardzo mile widziana.
EDYCJA Dziękuję Steve, poniżej znów uruchomiono vmware. Zawarłem drobną korektę. Przetestowano i potwierdzono, że mogę uruchomić maszynę wirtualną.
sudo su
# do all below as root
cd /usr/lib/vmware/modules/source
tar xvf vmmon.tar
tar xvf vmnet.tar
wget -O ./vmmon-only/linux/hostif.c https://raw.githubusercontent.com/mkubecek/vmware-host-modules/b50848c985f1a6c0a341187346d77f0119d0a835/vmmon-only/linux/hostif.c
vim vmnet-only/bridge.c
cd vmmon-only/
make
cd ../vmnet-only/
make
cd ..
mkdir /lib/modules/4.13.0-16-generic/misc
cp *.o /lib/modules/4.13.0-16-generic/misc
insmod /lib/modules/4.13.0-16-generic/misc/vmmon.o
insmod /lib/modules/4.13.0-16-generic/misc/vmnet.o
rm /usr/lib/vmware/lib/libz.so.1/libz.so.1
ln -s /lib/x86_64-linux-gnu/libz.so.1 /usr/lib/vmware/lib/libz.so.1/libz.so.1
vmware-networks --start
exit
# run vmware as normal user
/usr/lib/vmware/bin/vmware
2
Ogólnie rzecz biorąc, wirtualizacja stron trzecich będzie nieco opóźniona w przypadku nowych jąder i nowych wydań. Wydaje się, że wpływa to bardziej na vmware niż virtualbox. Ponieważ vmware jest zamkniętym źródłem, będziesz musiał o nie zapytać. Jako potencjalna alternatywa - dlatego staram się jak najwięcej korzystać z KVM lub LXC (chociaż nadal uważam, że LXC nie jest gotowy na serwery produkcyjne). Przyprawa KVM + jest bardzo szybka (FWIW). W przypadku vmware przypuszczam, że będzie działać od 1 do 3 dni lub 3–4 tygodni, w zależności od złożoności problemu.
—
Panther
Łatka, którą próbujesz zastosować, służy do rozwiązania problemu z obsługą pamięci, a nie do problemu związanego z wymienionym komunikatem o błędzie. AFAIK nie ma jeszcze rozwiązania tego problemu. Raport o błędzie na launchpad
—
user749720
udało Ci się rozwiązać problem „Nie udało się uzyskać informacji gcc”.
—
Oğuzhan Topçu,
Na szczęście nie, obecnie uruchamiam skrypt, który sudo wykonuje
—
user1330734,
insmodi wykonuje vmware-networkspolecenia, a następnie vmware binarny jako zwykły użytkownik.
Mam Lubuntu 18.04 - Metoda Stephena Wassella nie zadziałała. Rozwiązanie od tokam - aktualizacja do VMWare 14 też nie działało - ze względu na politykę VMWare tylko do obsługi najnowszego sprzętu. Metoda od Johna zadziałała - ale tylko wtedy, gdy uruchomię vmplayer jako su. W przeciwnym razie otrzymam niezawodny komunikat: wiersz 106: 29487 błąd pamięci (zapisany zrzut pamięci) „$ BINDIR” / vmware-modconfig --appname = "VMWaer Player! --Ivon =" vmware-player "
—
Tobias Trappe