WhyItsLikeThis's Posts

Thank you so much. Sorry for the misunderstanding.
The official docs mention how to uninstall VMWare Workstation in Linux distros, but it works poorly in reality. ⟹ sudo vmware-installer -u vmware-workstation All configuration information is about... See more...
The official docs mention how to uninstall VMWare Workstation in Linux distros, but it works poorly in reality. ⟹ sudo vmware-installer -u vmware-workstation All configuration information is about to be removed. Do you wish to keep your configuration files? You can also input 'quit' or 'q' to cancel uninstallation. [yes]: Uninstalling VMware Installer 3.0.0 Deconfiguring... [######################################################################] 100% Uninstallation was successful. Ist vmware-installer is asking two question at once, - Do you wish to keep your configuration files? - You can also input quit or q to cancel uninstallation. If you target first question, and write "yes", then I suppose they keep the configuration files! And if write, "no", then I suppose they delete everything! -------->> This is not technically a ture. Whether you choose, yes or no, as an answer, you WILL get to see this: ⟹ ls /usr/bin/ | grep -i vm vm-support vmhgfs-fuse vmstat vmtoolsd vmware-alias-import vmware-checkvm vmware-hgfsclient vmware-installer -> /usr/lib/vmware-installer/3.0.0/vmware-installer vmware-namespace-cmd vmware-rpctool vmware-toolbox-cmd vmware-user -> vmware-user-suid-wrapper vmware-user-suid-wrapper vmware-vgauth-cmd vmware-vmblock-fuse vmware-xferlogs vmwgfxctrl   vm-installer doesn't truly wipe your system clean. It will still leave some junk there to rot forever! Users to manually find each VMware tool/script inside the sensitive directory to manually wipe it out. This is not a good approach. vm-installer command is designed in such a poor way! A half cleaning mechanism. If this was a graphical uninstall, I would have said nothing. But this is a sudo permission requiring script and it works like this. VM-Installer -u have literally 1 job. Please fix this. Don't bloat the system unnecessarily.
> sudo CPATH=/usr/src/kernels/5.16.5-200.fc35.x86_64/include/linux vmware-modconfig --console --install-all @nexuscoreThank you for providing that command. I don't really know what that command is a... See more...
> sudo CPATH=/usr/src/kernels/5.16.5-200.fc35.x86_64/include/linux vmware-modconfig --console --install-all @nexuscoreThank you for providing that command. I don't really know what that command is actually doing. But it did work. When I launched VMware again, it didn't ask for vmmon and vmnet updates anymore and launched VMWare Workstation without an issue. What I don't understand is, why vmnet and vmnet modules SUCKS so much!? In each kernel update, it tends to break. Is it because these two modules are proprietary and need continuous maintenance!? Does every user have to google or post in the VMware community to find hacks/workaround after module update?! Aren't modules-update supposed to be rolled after proper testing?  And most importantly, if we know that "hacks" like this works, then doesn't VMware should use it to patch the update?! Annoyed user.
I now use Fedora 34 these days. pranav@fedora ~> cd /etc/ld.so.conf.d/ pranav@fedora ~> sudo touch vmware-authdlauncher.conf [sudo] password for pranav: pranav@fedora /etc/ld.so.conf.d> ls lib... See more...
I now use Fedora 34 these days. pranav@fedora ~> cd /etc/ld.so.conf.d/ pranav@fedora ~> sudo touch vmware-authdlauncher.conf [sudo] password for pranav: pranav@fedora /etc/ld.so.conf.d> ls libiscsi-x86_64.conf                 tix-x86_64.conf pipewire-jack-x86_64.conf      vmware-authdlauncher.conf pranav@fedora ~> cat /etc/ld.so.conf.d/vmware-authdlauncher.conf #pranav did this #linking libssl and libcrypto /usr/lib/vmware/lib/libssl.so.1.0.2 /usr/lib/vmware/lib/libcryto.so.1.0.2 pranav@fedora ~> sudo ldconfig [sudo] password for pranav:   And when I wanted to verify whether it worked or not, well it didn't because as you can see: pranav@fedora ~> ldd /usr/sbin/vmware-authdlauncher linux-vdso.so.1 (0x00007ffe7836d000) librt.so.1 => /lib64/librt.so.1 (0x00007faa6ddc1000) libssl.so.1.0.2 => /usr/lib/vmware/lib/libssl.so.1.0.2/libssl.so.1.0.2 (0x00007faa6db50000) libcrypto.so.1.0.2 => not found libdl.so.2 => /lib64/libdl.so.2 (0x00007faa6db49000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007faa6db2e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007faa6db0d000) libc.so.6 => /lib64/libc.so.6 (0x00007faa6d93c000) /lib64/ld-linux-x86-64.so.2 (0x00007faa6e0e9000) libcrypto.so.1.0.2 => not found pranav@fedora ~>   And I wonder why it didn't worked for me. And it showed libcryto.so error twice! I even restarted the distro to see whether I will get an error or not. Got the new error. At least it doesn't mention libssl anymore. @petra_zThank you petra. I finally figure out what might have went wrong. I left a word "p" when I write libcrypto.so.1.0.2. That was a dumb mistake. Anyway, thanks a lot.
pranav@exam ~> journalctl -r | grep -i "libssl" May 12 10:39:12 exam VMware[2973]: /usr/sbin/vmware-authdlauncher: error while loading shared libraries: libssl.so.1.0.2: cannot open shared objec... See more...
pranav@exam ~> journalctl -r | grep -i "libssl" May 12 10:39:12 exam VMware[2973]: /usr/sbin/vmware-authdlauncher: error while loading shared libraries: libssl.so.1.0.2: cannot open shared object file: No such file or directory The output of sudo vmware-modconfig --console --install-all is over here and see if its helpful: https://pastebin.com/q5R1e9Su After my research, I found this trick: It's a mistake on VMware developers, their binary is looking for this libs in... /usr/lib! This practice is super-outdated. Dirty fix is like this: sudo ln -s /usr/lib/vmware/lib/libssl.so.1.0.2/libssl.so.1.0.2 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 sudo ln -s /usr/lib/vmware/lib/libcrypto.so.1.0.2/libcrypto.so.1.0.2 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 But this trick didn't worked.  Do I need to manually install libssl or does the vmware install itself? Is this old ancient problem even fixable? - Ubuntu 21.04 - VMware Workstation 16.1.1 build-17801498
I really hoped this trick you've mentioned will work but sadly, it didn't. Because I still see the same message: 1 question though, do I need to install libssl.so.1.0.2 package separately?!, or ... See more...
I really hoped this trick you've mentioned will work but sadly, it didn't. Because I still see the same message: 1 question though, do I need to install libssl.so.1.0.2 package separately?!, or is it already installed in my distro. Because I think the trick you have mentioned will work if there is a binary named "libssl.so.1.0.2" inside this folder -> " /usr/lib/x86_64-linux-gnu/".   Another question: sudo ln -s /usr/lib/vmware/lib/libcrypto.so.1.0.2/libcrypto.so.1.0.2 /usr/lib/libcrypto.so.1.0.2 Is this command correct? Because the symbolic links will be created in /libcrypto.so.1.0.2 /usr/lib/libcrypto.so.1.0.2 folder instead of this  /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 folder. Is my correction correct, or your earlier comment did a typing mistake?
And the new problem I post wasn't 100% equal. This post is more about VMware's guest OS not reviewing user inputs. And my second post was about VMware killing the user interface of host OS... See more...
And the new problem I post wasn't 100% equal. This post is more about VMware's guest OS not reviewing user inputs. And my second post was about VMware killing the user interface of host OS application's normal behavior. I wonder what kind of sandboxing VMware use/have. I wonder if VMware even uses sandboxing or not. But this is NOT good. Anyway, if u are the developer stating both problems are the same, then u 'might' be right.
I get at least a link to that post. That would a great way to solve the problem form your side.
I am trying to learn ethical hacking during this lockdown. The video series often need me to play with Kali Linux since its one of the most common distribution for pen-testing. But sadly VMware h... See more...
I am trying to learn ethical hacking during this lockdown. The video series often need me to play with Kali Linux since its one of the most common distribution for pen-testing. But sadly VMware has not been a very helpful/reliable experience. Because 3 out of 5 times, I either have to wait for VMware to recognize that I am on it so that I can use Keyboard OR sometimes it gets even worse, no matter what I do, I cannot type at all. Yes, I can move my mouse freely, copy-paste each word/letters but that's it. No user input. Pressing letters on host OS will click some option as if I am using the mouse or it will write tetter like this  ^[s if I press s, ^[d if I press d and so on. This is very disturbing. I dunno what to do. If there something I need to do in order to make this work, please let me know. Note: 1. This doesn't happen if I use VM only. But if I go back-and-forth between host OS application and guest OS application, we will see the problem. 2. VM which I have installed is the latest stable and Kali Linux is also the latest version. 2 screenshot with 2 situations: 1st screenshot: VM is working fine when using host Os and guest os back-and-forth. 2nd screenshot: VM is not recognized user keyboard input as I have mentioned in the post. VMware Workstation 15.5.6 build-16341506 Update: A reverse scenario I reported here: https://bugs.launchpad.net/ubuntu/+source/telegram-desktop/+bug/1891976 What happened here? Ans: In short, I am/was not able to use an app named Telegram which is installed in host OS due to VMware hijacking my mouse and keyboard.