How to install VirtualBox Guest Addition on TinyCore - linux

When I run "sudo sh VBoxLinuxAdditions.run" just like on Ubuntu or CentOS, TinyCore throws errors and failed, and the /var/log/vboxadd-install.log shows that:
/tmp/vbox.0/Makefile.include.header:97: *** Error:
unable to find the sources of your current Linux kernel.
Specify KERN_DIR=<directory> and run Make again. Stop.
I have used tce tools installed some packets such as gcc, make, linux-kernel-sources-env.tcz, linux-3.16.2_api_headers.tcz, and then the VBoxLinuxAdditions.run can get the KERN_DIR, but no KERN_INC at this time.
If anybody has done this before could you please give me some points? I really don't know which packages should be installed in TinyCore to make VBoxAdditions work. My VBox and TinyCore is up to date. Thanks.

Found a repo for this issue, but have yet to verify:
https://github.com/MSumulong/vmware-tools-on-tiny-core-linux
Prior to that, I attempted to follow this tutorial, but it is incomplete:
https://www.gilesorr.com/blog/tcl641-guest-additions.html
Prior to that, attempted to build the kernel headers (/lib/modules/5.15.10-tinycore) with no luck.
Copying the Guest Additions to home folder and running sudo VBoxLinuxAdditions.run returns "Kernel headers not found for target kernel 5.15.10-tinycore. Please install them and execute /sbin/rcvboxadd setup"

Basically you have to install the package linux-headers-${kernel_version}
# apt-get install linux-headers-3.16.0-4-amd64
This solved my problem on Debian linux.
To check the version of your kernel, you should run the command:
# uname -a
# Linux debian 3.16.0-4-amd64 # SMP Debian

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.

Can't execute .run file in Ubuntu container

there.
I'm trying to install the Microchip XC8 compiler on a Ubuntu container to make a pipeline for building the project with Gitlab CI. But there's no response after I run the "xc8-v1.45-full-install-linux-installer.run" file.
Here is the environment I have:
Official Ubuntu 18.04 LTS image on a Docker container
Docker version 19.03.13
Windows 10 as Docker host
Microchip XC8 v1.45 compiler
And the commands I used for downloading and installing are as following:
# Download XC8 from the Microchip official site
wget http://ww1.microchip.com/downloads/en/DeviceDoc/xc8-v1.45-full-install-linux-installer.run
# Change the access permission
chmod +x xc8-v1.45-full-install-linux-installer.run
# Execute the ".run" file
./xc8-v1.45-full-install-linux-installer.run
After I did them all, there's no response. Obviously, something went wrong.
I have tried the installation process above on a native Ubuntu computer, and it just works fine.
Is there any prerequisite I missed? Or there have some ways for me to achieve the same purpose?
Thanks!
I was having this problem on 64 bit Ubuntu 20.04 as well.
I had several problems, could not change execution bit because it was on an NTFS partition and the executable required 32 bit libraries to run.
First I had to move the file from an NTFS partition so that I could set the file to executable. In my case I moved it to my downloads directory and then in that folder executed:
sudo chmod +x ./xc8-v1.42-full-install-linux-installer.run
It still would not run, so I checked its type by executing:
file ./xc8-v1.42-full-install-linux-installer.run
which resulted in the response:
./xc8-v1.42-full-install-linux-installer.run: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, no section header
Eventually the main solutions was to install 32 bit libraries:
sudo apt-get install lib32z1
Finally I could install install that 32 bit library. Then running this worked:
sudo ./xc8-v1.42-full-install-linux-installer.run
Using existing MPLAB Docker repo
This GitLab.com project exists:
MPLAB X IDE/IPE podman/docker container
This may not help with your .run file problem, but maybe switching to an existing docker container might make it easier for you.
They also work with .run files, so you may find your solution over there as well.
Features:
Has a general-purpose installation of MPLAB X and the toolchain.
X11 forwarding for working in the IDE is supported.
Can use USB from inside the container.
Requires some setup. See readme for installation instructions.
MIT License
Need to test this still myself, but just wanted to share here, might just as well.
Posted in the microchip forums by the creator:
Dockerfile for MPLAB X IDE/IPE and toolchains

/lib/modules/*/build point to non existing files

I have a CentOS Linux release 7.2.1511 (Core).
I want to build some kernel code for currently running kernel.
My uname -r says 3.10.0-327.10.1.el7.x86_64, but ls -l /usr/src/kernels/
shows only 3.10.0-327.13.1.el7.x86_64. Why do I have sources of not current kernel on my filesystem(vanilla fresh provisioned Digitalocean box)?
Why does yum install kernel-devel does not install headers for currently running kernel?
uname is a system call to the kernel to get information. It's telling you what's running on that machine. What's physically present on the hard drive can be anything that anyone has installed. Someone may have downloaded the wrong package or you may have multiple kernels installed etc. But, the one that's running is what uname is telling you.

Fedora 19 x86_64 kernel version is different with kernel source

I installed Fedora 19 x86_64 on My vmware workstation. When I try to install the third party software. it give me a message "can't find kernel source files".
I checked that the kernel version is 3.9.5-301.fc19.x86_64 via uname -r.
but I found the kernel source version is higher than the current running kernel version.
there are two symblic links in /lib/modules/3.9.5-301.fc19.x86_64 folder. they are
build -> /usr/src/kernels/3.9.5-301.fc19.x86_64
source -> build
They are broken, because there is no folder /usr/src/kernels/3.9.5-301.fc19.x86_64 in my system.
Can anyone tell me why this situation happens. and how to install correct kernel source in my Fedora.
Big thanks.
Any reason to not run the latest kernel? You might benefit from updating everything first.
# yum update
Doubt you actually need the entire kernel source. Have you installed kernel-devel?
# yum install kernel-devel
If you need more, next install kernel headers.
# yum install kernel-headers
If you do update the running kernel, reboot into that kernel before installing the 3rd party software.
You can check here what is the currently most stable kernel available (and download associated RPMs if you requiere):
https://admin.fedoraproject.org/updates/kernel
The same happened to me on my Fedora 19 box and my kernel version was: 3.14.4-100.fc19.x86_64 so VirtualBox was looking for the source here:
/usr/src/kernels/3.14.4-100.fc19.x86_64
I checked my /usr/src/kernels dir which and found that it was empty. Then I downloaded the kernel src from the net which was named:
kernel-3.14.4-100.fc19.**src**.rpm
and extracted to /usr/src/kernels/ and run:
/etc/init.d/vboxdrv setup
Which returned:
Stopping VirtualBox kernel modules [ OK ]
Recompiling VirtualBox kernel modules [ OK ]
Starting VirtualBox kernel modules [ OK ]
Was working great!

apt-get auto prompt disappears after kernel upgrade

I've got some problem about bash.
Before today, my VPS (Ubuntu 12.04 LTS) was using kernel 2.x. (Because it was upgraded from 11.04 and the boot options did not get updated.)
Today I want to use kernel 3.2 as the default kernel.
After modifying the grub config, I've successfully booted the VPS up in kernel 3.2. Using uname -r will show 3.2.0-24-generic instead of 2.x.y-z-generic now.
However, something wonky happened and I don't why.
Before the kernel change, if I type some unkown command, the shell will prompt me to use apt-get to install it. For example, I don't have bind9 installed, and when I try to run named, I will be prompted like this:
wzyboy#vermilion:~$ named
The program 'named' is currently not installed. You can install it by typing:
sudo apt-get install bind9
Sometimes when I make a typo, I will be corrected ("did you mean"):
wzyboy#vermilion:~$ namedd
No command 'namedd' found, did you mean:
Command 'named' from package 'bind9' (main)
namedd: command not found
However, after the kernel change, when I try to run named, the shell simply says:
wzyboy#natatio:/$ named
-bash: named: command not found
I think it may be something wrong with bash, but I don't know how to fix the problem. Can anybody help?
[SOLVED] Thanks! After installing command-not-found package, the problem is solved. However, I still don't why the package got lost after changing the kernel...
To enable those auto suggestions you need to ensure that you have command-not-found installed. It is usually automatically enabled via /etc/bash.bashrc if installed correctly.

Resources