installing vmware - gcc version [solved]

[djemos]

sha1 sum is ok.
When installing do you get any message about unistalling a previous version? If so then remove by hand previous version before installing the new one.
googling can find how to do it.
Also do you have upgrade the kernel? What kernel headers you have. You also will need the kernel source package installed.

[mimosa]

When I upgraded the kernel, I also upgraded the headers:

Code: Select all

mimosa[~]$ ls /var/log/packages/kernel*
/var/log/packages/kernel-firmware-20170626git-noarch-1  /var/log/packages/kernel-huge-4.4.38-x86_64-1  /var/log/packages/kernel-modules-4.9.34-x86_64-1
/var/log/packages/kernel-headers-4.9.34-x86-1           /var/log/packages/kernel-huge-4.9.34-x86_64-1  /var/log/packages/kernel-source-4.9.34-noarch-1
mimosa[~]$ uname -r
4.9.34

I will look into removing the old version of VMware more thoroughly, but perhaps I should downgrade the kernel headers to the default?

Code: Select all

mimosa[~]$ sudo slapt-get --simulate -i -reinstall kernel-headers
Password: 
Reading Package Lists...Done
The following packages will be upgraded:
  kernel-headers 
1 upgraded, 0 reinstalled, 0 newly installed, 0 to remove, 0 not upgraded.
Need to get 728.0kB of archives.
After unpacking 346.0kB of additional disk space will be used.
kernel-headers-4.9.34-x86-1 is to be upgraded to version 4.4.88-x86-1

[djemos]

I see that you have kernel 4.4.38 and no kernel modules 4.4.38. You have also kernel 4.9.34. You also have kernel headers 4.9.34.
But this line? kernel-headers-4.9.34-x86-1 is to be upgraded to version 4.4.88-x86-1
There is no 4.4.88 kernel in your system.
I suggest to install a kernel version and headers and remove any other kernel exist in your system.
Running same command in my system which is slackel (slackware current) i get

Code: Select all

sudo slapt-get --simulate -i -reinstall kernel-headers
Reading Package Lists...Done
The following packages will be reinstalled:
  kernel-headers 
0 upgraded, 1 reinstalled, 0 newly installed, 0 to remove, 0 not upgraded.
Need to get 2.0kB/772.0kB of archives.
After unpacking 606.0kB of additional disk space will be used.
kernel-headers-4.9.52-x86-1 is to be upgraded to version 4.9.52-x86-1

You see? kernel-headers-4.9.52-x86-1 is to be upgraded to version 4.9.52-x86-1
So you have messed up your system with kernel packages.
This is the problem.

[mimosa]

I don't know why the package management system thinks I still have the old kernel "installed", but I am running 4.9.34 everything, as the output I posted above shows.

In fact I did try "downgrading" the headers, and it also made no difference.

It was some time ago but I'm pretty sure I carried out the upgrade according to the instructions on the wiki - except that I did upgrade the headers. There was some discussion here about that issue at the time and the upshot was that it probably didn't generally matter much either way.

Code: Select all

mimosa[~]$ ls -l /boot | grep vmlinuz
lrwxrwxrwx 1 root root      19 Jun 28 08:31 vmlinuz -> vmlinuz-huge-4.9.34
lrwxrwxrwx 1 root root      19 Jun 28 08:31 vmlinuz-huge -> vmlinuz-huge-4.9.34
-rw-r--r-- 1 root root 7629056 Jan 19  2017 vmlinuz-huge-4.4.19
-rw-r--r-- 1 root root 7624944 Jan 19  2017 vmlinuz-huge-4.4.38
-rw-r--r-- 1 root root 8194336 Jun 24 19:00 vmlinuz-huge-4.9.34
mimosa[~]$ uname -r
4.9.34

EDIT
What I'll try later is upgrading to the same kernel you have, djemos. But it occurs to me there may be another explanation: some build tools you may have installed and I don't. (Assuming I haven't somehow broken my system).

Looking at the Arch wiki, it seems problems like this are not uncommon. Nonetheless, it works for you and others.

[laprjns]

mimosa, are you running 14.2 or current?
14.2 is using the 4.4 series kernel and current is on 4.9. Are you mixing repos? The current version of the 14.2 kernel is 4.4.88

Code: Select all

ich[~]$ sudo slapt-get -l | grep kernel-
kernel-firmware-20160628git-noarch-1 [inst=no]: kernel-firmware (Firmware for the kernel)
kernel-firmware-20170914git-noarch-1 [inst=yes]: kernel-firmware (Firmware for the kernel)
kernel-generic-4.4.14-x86_64-1 [inst=no]: kernel-generic (a general purpose SMP Linux kernel)
kernel-generic-4.4.88-x86_64-1 [inst=no]: kernel-generic (a general purpose SMP Linux kernel)
kernel-headers-4.4.14-x86-1 [inst=no]: kernel-headers (Linux kernel include files)
kernel-headers-4.4.88-x86-1 [inst=yes]: kernel-headers (Linux kernel include files)
kernel-huge-4.4.14-x86_64-1 [inst=no]: kernel-huge (a fully-loaded SMP Linux kernel)
kernel-huge-4.4.88-x86_64-1 [inst=yes]: kernel-huge (a fully-loaded SMP Linux kernel)
kernel-modules-4.4.14-x86_64-1 [inst=no]: kernel-modules (Linux kernel modules)
kernel-modules-4.4.88-x86_64-1 [inst=yes]: kernel-modules (Linux kernel modules)
kernel-source-4.4.14-noarch-1 [inst=no]: kernel-source (Linux kernel source)
kernel-source-4.4.88-noarch-1 [inst=yes]: kernel-source (Linux kernel source)

[mimosa]

I upgraded to a more recent kernel, but other than that, this is 14.2. In fact, I think it may originally have been the beta. On my laptop, where I also have been testing the steps with VMware recommended on this thread, it is a straight 14.2 install, but also with a more recent kernel.

EDIT

And you're quite right - it seems that was an upgrade too far. I downgraded to the 4.4.74 kernel, which I kept, and the necessary modules seem to have been built during boot. Sorry to have wasted everyone's time!

I can't remember what led me not to stick with that kernel, but in any case, I've learned my lesson - to keep within the same series.

[elcore]

There's plenty of things wrong with it, honestly I don't know where to start.
The bundle installs a whole lot of gnome libs, enforces a gtk theme, reads files in /usr/share/ and more..
It uses a non standard binary path, requires headers that match the running kernel, and needs rebuilding on each kernel update.
Furthermore, some things that used to work before don't work now, for example the installer does not create /etc/vmware/networks anymore so vmnetlib fails.
There is no tool to configure networks on CLI anymore, there's only a set of binaries that are used by their GUI which needs elevated privilege for no good reason.
I used to just edit the configuration files by hand without the GUI and it worked great, now it needs root access to X screen.
Almost like they introduce this security risk intentionally, see also what the data collection script does. Wouldn't recommend it.

[mimosa]

I've updated the wiki to try and make it a little more idiot-proof:
https://docs.salixos.org/wiki/How_to_in ... ent_kernel
Comments or suggestions welcome.