Can't install new kernel, hangs on DKMS installing EVDI - linux

Whenever I see the update manager glowing that I have an update I get annoyed and click it, so I'm almost always updating something and usually this has gone fine without any problems...
Recently it told me there was a new kernel update, so I clicked install like I usually do but it just got stuck, for hours. When I examined the terminal output it was hanging on a DKMS installation step, so I grabbed all the active DKMS processes and found that the specific thing it was hanging on was installing something called EVDI (which is related to the DisplayLink Ubuntu driver, I think). After letting it sit there doing nothing for more than a day I killed it and had to Timeshift back to before I had done the installation as it corrupted my kernel.
I examined the log file in /var/lib/dkms/evdi/5.2.14/build/make.log and found that it has many errors reported, and the one that starts the chain is:
make -f ./scripts/Makefile.build obj=scripts
make[1]: *** [arch/x86/Makefile:211: archscripts] Error 2
I can provide the full log file if you want, it's just long.
I've tried to google around this and haven't been able to find anyone with this specific issue, so any help is much appreciated! I have also tried installing the DisplayLink driver from source (since it includes an install of EVDI) but it also hangs in the same place (for hours) -- it gets stuck at [[ Installing EVDI DKMS module ]].
I've thought about straight up removing all references to EVDI and hoping that it would then rebuild it, but I am not sure if this would cause further problems. In a different answer I saw that I could remove all DKMS instances of a package from all kernels by doing something like sudo dkms remove package --all but this is entirely new territory for me and I have decided I should wait for someone smarter than me to tell me whether that's a good idea or not before I end up irreparably breaking my installation.
I'm running Linux Mint 20.1 Cinnamon (Cinnamon v 4.8.6), Linux kernel 5.8.0-44-generic, on a Dell XPS 13 with an i7-1065G7 CPU (no GPU). Everything does work fine right now, I just would like to not be stuck on this version of the Linux kernel forever! Any help is very much appreciated :)

Ultimately fixed by booting into an old 5.4 kernel, purging DKMS + all of the 5.8 kernels and a troublesome 5.4 kernel (had to do some things by hand as apt would not remove some directories), then reinstalling everything and updating grub from the 5.4 kernel. Just tested an update via the update manager (now running on the latest 5.8 kernel) and it worked fine! Unclear what exactly was causing the problem but glad it's fixed and hope this helps others if they stumble into something like this.

Related

Any success installing VMware Workstation on virgin Rocky Linux 8.5?

Using a virgin (but updated) version of Rocky Linux 8.5, I am trying to install VMware Workstation 16.2.1 (and others), but get compile errors during the first attempt to run, when vmmon and vmnet are being built.
All the proper, current headers from kernel-devel and kernel-headers are installed.
I tried upgrading to the 5.16.4 kernal at kernel.org, with all associated headers, and basically get the same errors.
"Unable to install all modules." i.e., vmmon and vmnet
Posts i have found with searching the net seem to indicate that there was a "back-port" of an upstream fix to Rocky that has affected the ability to build the loadable kernel modules necessary to run vmware - but i cannot confirm this is actually the problem that I am experiencing.
So i simply ask these questions: Can anyone (today) install VMware Workstation 16.2.1 (or any version), on a fresh install of Rocky Linux 8.5?
If so, would you please point me at your installation instructions, because I am unable to build "vmmon" and "vmnet" modules today (2022-01-04), that allow me to actually run virtual machines with vmware? (The kernel modules fail to compile and build.)
(and after 15 years of using stackoverflow i do not have the reputation to create a "rocky-linux" question tag...)
See https://unix.stackexchange.com/questions/689436/the-vmmon-and-vmnet-vmware-workstation-kernel-modules-fail-to-build-on-rocky-lin
mbubecek's instructions work for a variety of releases and should compile perfectly and run without issue, if you follow his instructions.
I have successfully used these methods at least a half dozen times with Rocky 8.5 and 8.6 with vmware workstation 16.1 up to version 16.2.1
NOTE: This error is NOT Rocky Linux specific. Also happens on some versions of RHEL 8 and CentOS 8.x I would also expect this "fix" to work on all of the other linux versions that are RHEL 8-derived.
I've been having difficulty with the same issue, and a colleague pointed me to check my kernel. This is our "official" resolution. See if the below works for you.
This is due to differences between the kernel and the source code for the VMWare modules, see here for more information. You can get the correct kernel modules, and build them by executing the following commands
wget https://github.com/mkubecek/vmware-host-modules/archive/workstation-16.1.0.tar.gz
tar -xf workstation-16.1.0.tar.gz
cd vmware-host-modules-workstation-16.1.0/
make
sudo make install
If you get the error,
crosspage.c:53:16: fatal error: linux/frame.h: No such file or directory
The error is described here. The solution is to remove (i.e. comment out) the offending include file in crosspage.c After doing the sudo make install, it is a very good idea to restart you host.
You may need to manually insert the modules into the kernel the first time after running make install'. The kernel modules (vmmon.ko and vmnet.ko) will be found at /lib/modules//misc. The following set of command will do this:
cd /lib/modules/$(uname -r)/misc
sudo insmod vmmon.ko
sudo insmod vmnet.ko
The modules should be load automatically after a restart/reboot.
If you update vmware to a different version (say 16.2.1) you may need to this again. Just change the versions in the above commands. If you hit the update button on the splash-screen and failed to notice the version you are updating to, you can run `vmware -v' at a command prompt to get the version you updated to.

How to start Unity Editor on Linux?

I downloaded the latest version of Unity platform-agnostic self-extracting installation script and successfully installed it:
$ sudo sh ./unity-editor-installer-5.4.0p1+20160810.sh
Installer for Unity 5.4.0p1
Press Enter to begin extracting to ./unity-editor-5.4.0p1
Unpacking Unity 5.4.0p1 ...
Extraction complete. Run ./unity-editor-5.4.0p1/Editor/Unity to begin
Then I tried to run the Editor:
$ ./unity-editor-5.4.0p1/Editor/Unity
These two windows appear immediately when the command above is run:
and nothing more happened for the whole night. No error messages, no console output, no log files and no syslog entries. top utility shows that Unity process utilizes one core for 100% of it's CPU time.
I run OpenSUSE 13.2 with up-to-date nVidia graphics drivers. My system also matches all dependencies and requirements listed here, and I didn't see any other instructions except "run the installation script, then run the editor". Unity works OK on Windows with the same hardware.
So my questions are:
How (if possible) to run Unity Editor on non-Ubuntu distributions?
Where can I find error messages (if any) which might clarify the reasons of the issue?
This seems to be a common linux bug.
I can't make any assurances but what worked for me (and what seems to be the most suggested fix on the unity forums) is to do two things:
update or install NPM
create the directory "~/.local/share/unity3d/Packages"
If your npm is up to date, the directory thing seems to be the big to-do (it worked like crackers for me).
If you've got both...well, at least you get the joy of adventure trying to figure out what else could be going against you.

Make changes to kernel version

I am using Fedora 20 and somehow it boots to an older version of the kernel: 3.11, instead of 3.14. uname -r shows 3.11.10-301.fc20.x86_64 and rpm -qa kernel shows kernel-3.11.10-301.fc20.x86_64, kernel-3.13.10-200.fc20.x86_64, kernel-3.14.4-200.fc20.x86_64
I am curious why this is caused.
How I can make it to boot to 3.14 (the updated version.)
Would it cause trouble if I remove the older versions?
If not, how can I remove the older version, just for the record.
A user from another thread suggested me to hold 'Ctrl' key to change this, but this didn't quite work out and I wish to have more permanent solution to this.
All other thread only mentions how to install and boot to older versions, not the other way around. Any help would be appreciated!
Are you getting all the kernel version in GRUB Screen. if not then update GRUB then it will display all the kernel version and then you can select as per your choice.
grub2-mkconfig -o /boot/grub2/grub.cfg
try above using super user mode.
You should not delete the older kernels as i tried in Debian it made me to format the HD so better keep all versions. You can remove the kernel package but due to dependency and other reasons it may create problems. Still you want to remove the kernels then you can follow the link.

No such file or directory; But the file does exist

I am trying to run a Binoinformatics program, DistMap on Ubuntu 12.04 LTS (x86_64). I am getting the error No such file or directory. But the file do exist in the required location.
I have used this program before and it ran perfectly fine. Yesterday I installed virtualenv-burrito for some other program, Seal. Since then I haven't been able to run DistMap.
I know there have been many posts regarding this error all over the internet. But the solution seems to be the same for all the posts.
sudo apt-get install ia32-libs
This solution is for running 32-bit application on 64-bit machines. But since Distmap worked before without any problem I dont think that is the problem. Still, I installed ia32-libs; just for the sake of it but no use.
I am sure the problem is virtualenv-burrito. So I uninstalled it from my machine (Deleted .virtualenv and .virtualburrito folders. Since that's the only way i found for uninstalling virtualenv-burrito on the internet). Still my application is not running.
How can I bring my system to default as in to the previous state of virtualenv-burrito installation?
I hope I will get some good suggestions. I have been struggling for sometime now.
Thanks.

OpenCV keeps "uninstalling" itself (Linux)

Really annoying issue here. On Linux Mint OS. Every so often, I'll get this error when running OpenCV code:
HIGHGUI ERROR: V4L/V4L2: VIDIOC_S_CROP
OpenCV Error: Unspecified error (The function is not implemented. Rebuild the library with Windows, GTK+ 2.x or Carbon support. If you are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then re-run cmake or configure script) in cvNamedWindow, file /home/ravi/Desktop/opencv/OpenCV-2.1.0/src/highgui/window.cpp, line 180
terminate called after throwing an instance of 'cv::Exception'
what(): /home/ravi/Desktop/opencv/OpenCV-2.1.0/src/highgui/window.cpp:180: error: (-2) The function is not implemented. Rebuild the library with Windows, GTK+ 2.x or Carbon support. If you are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then re-run cmake or configure script in function cvNamedWindow
The way to fix this, I've found, it to do the following:
cd OpenCV/
cd build/
cmake ..
make
sudo make install
sudo ldconfig
<restart computer>
Then I'll come back, start running my OpenCV code again, and it'll be fine. But then a few hours later, or possibly between turning cpu on/off, I'll be back to the same stupid error!
Does anyone have any idea what's going on here and how I can prevent this? It's frustrating as hell.
It sounds like a general critical error in the program code. Is there a specific task that is done when the error occurs? You might want to use strace to get the output of the program as it runs or enable application memory dumps for the user you are running the process as. This would be passed to the developer for debugging and inspection.
I believe the problem was solved by paying attention to where my USB camera was actually located in /dev/. Giving a faulty path to the get video source functions causes this type of error; restarting my computer occasionally shifted which /dev/video# my device was attached to.
Please do ls /dev/vid* to find out if you're using the right video source!

Resources