Problems attempting an upgrade of 64-bit openSUSE 13.2 to Leap 45.1 within VirtualBox 5.0.8

Hi. I have been using 64-bit openSUSE 13.2 in Oracle Virtual Machine (VM) VirtualBox, hereafter referred to as VirtualBox. On November 2, 2015 I updated VirtualBox from version 4.3.32 r103443 of it to version 5.0.8 r103449 of it. On November 2 and 4, 2015 I updated my installation of the 64-bit openSUSE-13.2 operating system. Then later on November 4, 2015 I attempted to upgrade 64-bit openSUSE 13.2 to 64-bit openSUSE Leap 45.1. Some openSUSE-13.2 repositories may have been removed in the beginning of that upgrading process. Some conflicts needed to be manually resolved. Among the choices for such conflict resolutions were to delete such packages as virtualbox-guest-kmp-desktop-4.3.30_k3.16.7_24-20.1.x86_64 and virtualbox-guest-kmp-desktop-4.3.32_k3.16.7_29-32.2.x86_64. I eventually aborted that upgrade process. The operating system 64-bit openSUSE 13.2 still functioned, except for problems accessing some online software repositories. After skipping or going around such repository access in Yet another Software Tool 2’s (YaST2’s) Software Manager I noticed that version 4.3.32… of the software package virtualbox-guest-kmp-desktop was shown as being installed, but not version 4.3.30… or version 5.0.8… of it. I could access the Internet in 64-bit openSUSE 13.2 in VirtualBox 5.0.8…, despite the fact that no virtualbox-guest-kmp-desktop-5.0.8… existed in my installation of 64-bit openSUSE-13.2 Linux. In 64-bit openSUSE 13.2 I have version 3.16-7-29 of the Linux kernel installed. Do I need to “roll back” my installation of VirtualBox to version 4.3.32… of it, perhaps because version 5.0.8… of VirtualBox was too new for the computer program to install 64-bit openSUSE Leap 45.1 to “recognize” or work with it, and then try to update VirtualBox to version 5.0.8… of it or else wait awhile until version 5.0.8… of some VirtualBox files become available in 64-bit, openSUSE Leap 45.1 repositories and then update VirtualBox to version 5.0.8… of it? If so, on the Internet explains how to perform such a roll back of VirtualBox in such a way that the Virtual Machines (VMs) within it are not lost. Also in the installation of 64-bit openSUSE Leap 45.1 I was asked whether I wanted to configure an Internet connection or not, which if I had tried to do that would have required me to click on an “Edit” software “button” and input some data, data I probably did not immediately know at that time. At the moment I can’t access some openSUSE-13.2 repositories without problems, perhaps because some of them may have been deleted in an early stage of the upgrade process, again a process which I eventually aborted. Fortunately I wrote a backup of the data on my notebook computer’s internal hard-disk drive during November 2-3, 2015 so that if necessary I can hopefully return to a working system including VirtualBox 5.0.8… with good access to openSUSE repositories in 64-bit openSUSE 13.2 when I visit a place with free, fast Internet access. Without being sure of everything here I guess that if I would return my computer to its state on November 2, 2014 before I backed up its data onto an external hard-disk drive; keep VirtualBox guest additions for version 4.3.32… of it installed; uninstall VirtualBox 5.0.8…; install VirtualBox 4.3.32… and make use of the previous VMs, which amounts to using their .vdi files in VirtualBox 4.3.32…; update openSUSE 13.2 within VirtualBox; and then try to upgrade 64-bit openSUSE 13.2 to 64-bit openSUSE Leap 45.1, I could hope that all of the problems I mentioned here would not occur. And perhaps then VirtualBox could be updated from version 4.3.32… to version 5.0.8… of it and following that that 64-bit openSUSE Leap 45.1 could be updated hopefully without problems.

maybe you should re-ask this in the Virtualization sub-forum

properly formatted as I tried reading this twice and I couldn’t get pass the 2nd line.

With minor edits I posted the above contents on Both there and here and below this paragraph I continue writing on this topic. This subject turned out to be partly mixing two kernels in an openSUSE upgrade and at least partly using two different kernels, one in the running Linux kernel of 64-bit openSUSE 13.2 that was “inherited” in the upgrade to 64-bit openSUSE Leap 45.1 and a different one in making one or more Linux kernel modules in openSUSE Leap 45.1 for the use of VirtualBox Guest Additions. I suppose that in effect mixing two Linux kernels into the upgraded version of the openSUSE operating system may have caused some problems. If this brief description is unclear to you, I hope the more lengthy description below will make this matter clearer for you.

The strategy I set forth earlier in this thread did not result in a solution to my problems in attempting to upgrade 64-bit openSUSE 13.2 to 64-bit openSUSE Leap 45.1. I did restore my computer’s internal hard-dive data back to the data of November 2, 2015. I in effect replaced VirtualBox 5.0.8… with VirtualBox 4.3.32… But in the attempt to upgrade openSUSE software conflicts similar to earlier appeared! The conflicts I encountered had to do with versions of the Linux kernel and versions of VirtualBox Guest Addition files. I eventually found an almost random combination of keep some software packages and deinstall some other software packages that enabled that upgrade to proceed. Afterward I could access the Internet and install updates in 64-bit openSUSE Leap 45.1. But the contents of a folder I shared between my host Windows operating system and the guest, 64-bit, openSUSE-13.2 Linux operating system in VirtualBox using VirtualBox Guest Addition files were no longer visible in the 64-bit, openSUSE Leap 45.1 operating system. That turned out to be a symptom of the greater problem. There were several clues to what that greater problem that turned out to be:

  1. The response to the Linux command “uname -a” was that version 3.16.7-24.1 of the Linux kernel was the kernel being run in the Leap, 45.1 installation of openSUSE.

  2. In Software Manager I saw red-colored digits in the version number beside the installed software package kernel-desktop.

  3. On on the Internet the proposal was to modify the default Linux kernel and drop the desktop version of the Linux kernel for the openSUSE Leap and SUSE Linux Enterprise (SLE) versions of Linux.

  4. In Software Manager I saw that the uninstalled version of kernel-default in my installation of the 64-bit openSUSE Leap 45.1 Linux operating system was 4.1.12-1.1.

  5. On on which someone else had trouble with VirtualBox Guest Additions someone asked, “Do you have the kernel-devel package installed that matches your currently running kernel?”

  6. My installed version of kernel-devel was 4.1.12-1.1 in 64-bit openSUSE Leap 45.1.

  7. On Takashi Iwai and Richard Brown proposed using the 4.1 Long-Term Support (LTS) as the version of openSUSE Leap’s default Linux kernel; and that was done on July 22nd of I presume the year 2015.

Probable conclusions of a learner (myself):

A) I suppose that in my installation of the 64-bit openSUSE Leap, 45.1 Linux operating system that version 3.16.7-24.1 of the kernel-desktop was likely a remnant of my openSUSE-13.2 installation, since version 4.1 LTS of the Linux kernel was likely designed for openSUSE Leap and the version 3.16.7-24.1 appeared in a red color beside kernel-desktop in Software Manager.

B) In the “building” of one or more kernel modules via the command “sudo zypper in kernel-devel gcc make” I suppose that that one or more Linux kernel modules may have been “built” with version 4.1.12-1.1 of the Linux kernel, the probable version of the Linux kernel in kernel-devel that was used in that “build,” a possible explanation for why that module or those modules did not work completely well in the version 3.16.7-24.1 of the Linux kernel that I had running!

Also in the reported conflicts among software packages and/or proposed remedies during the upgrade or in Software Manager I noticed the number 5.0.6 instead of 5.0.8. From probably somewhere within I noticed that 5.0.6 was a version of VirtualBox, even though it was not a version of VirtualBox that I had installed on my computer. My settings in openSUSE’s “User and Group Management” for permissions to read and write files in the folder I designed to be shared between Windows and openSUSE Linux appeared to have been “inherited” pretty well in the upgrade from version 13.2 to Leap 45.1 of openSUSE.

A solution I tried:

to uninstall kernel-desktop 3.16.7-24.1, to install kernel-default 4.1.12-1.1, and to obtain version 5.0.8… of the VirtualBox Guest Additions by clicking on the hyperlink reading VboxGuestAdditions_5.0.8.iso on and hope that a) the kernel module or modules produced using kernel-devel 4.1.12-1.1 would work in kernel-default 4.1.12-1.1 and b) that applications, such as Konqueror, that were “inherited” or upgraded from openSUSE 13.2 would work with that higher version of the Linux kernel.

As a “side effect” that solution automatically resulted in the installation of virtualbox-guest-kmp-default. What I did afterward was similar, but slightly different from what I saw on In the computer program Terminal I input:

sudo zypper rm virtualbox-guest-kmp-default virtualbox-guest-tools virtualbox-guest-x11
(And if “Software Management” shows that virtualbox-guest-kmp-desktop is installed, add it to the above list software packages to be removed as well. I probably was prompted to input my root-user password at this point.)

sudo zypper in kernel-devel gcc make
(Of course the software packages zypper, kernel-devel, gcc, and make all have to be installed in the operating system for the above command to work.)

In the left-hand portion of the Web browser and file manager Konqueror, if VBOXADD… appears, one can right-click on it and select “eject” or “Eject.” Then in the VirtualBox window for my openSUSE guest operating system I clicked on the “Devices” menu, then on “Optical Drives,” “Choose disc image…”, and then browsed to the file VboxAdditions_5.0.8.iso that I downloaded by clicking on the hyperlink reading VboxGuestAdditions_5.0.8.iso on and opened that file. Next I input a command of the form

sudo /run/media/”MY_OPENSUSE_USER_NAME”/VBOXADDITIONS_5.0.8_103449/

. (Or replace 5.0.8_103449 with whatever version you need in the above command corresponding to your download of a VboxGuestAdditions…iso. If you are prompted to do so at this point in time, input your root-user password.).

In Yet another Software Tool 2’s (YaST2’s) “User and Group Management” with the previously set permissions for my user name for vboxsf on the “Groups” tab in “System Users” and in Windows 10 Home Edition with the directory ‘C “colon” “backslash” HostFolder’ set to be shared with “Everybody,” this gratefully allowed the contents of that directory to be displayed in the openSUSE directory /media/sf_HostFolder in the K Desktop Environment (KDE).

Two phenomena some of my readers might consider surprising:

i) But in the Lightweight X Windows System, Version 11 (X11) Desktop Environment (LXDE) I found it was necessary to repeat at least the command

sudo /run/media/”MY_OPENSUSE_USER_NAME”/VBOXADDITIONS_5.0.8_103449/

in order to have the contents of /media/sf_HostFolder displayed in Konqueror in the LXDE. And,

ii) although in the past few years I have used the LXDE much more than the KDE with openSUSE, after the installation of 64-bit openSUSE Leap 45.1 Linux, in it I found that in the KDE on November 5, 2015 there were 1,619 updates for me to install, nearly all of which I was not notified to install in the LXDE.

So in 64-bit openSUSE Leap 45.1 Linux “i” is an example of an activity performed in the KDE that did not effect the LXDE in the same way. And from “ii” without knowing for certain if all of the updates obtained in the KDE would suffice for updating the LXDE, the safe thing to do would likely be to try to separately update the KDE and LXDE in an openSUSE Linux operating system.

A remaining query is why I had the software conflicts in upgrading from version 13.2 to Leap 45.1 of openSUSE. Looking at my notes I found that I made a so-called “clean” installation of openSUSE 13.2 on November 27, 2014 which involved formatting the virtual partition containing the 64-bit, openSUSE-13.1 Linux operating system. So it is easy to understand why there were no software conflicts between remnants of openSUSE 13.1 in openSUSE 13.2.—In a so-called “clean” installation of openSUSE 13.2 in which the Linux-containing partition was formatted, there would not have been any remnants of the openSUSE 13.1 operating system in the subsequent installation of openSUSE 13.2. But in the upgrade from version 13.2 to version Leap 45.1 of 64-bit openSUSE I suspect the kernel conflict might have arisen because the computer program to install openSUSE Leap 45.1 did not automatically replace kernel-desktop 3.16.7-24.1 from openSUSE 13.2 with kernel-default 4.1.12-1.1 from openSUSE Leap 45.1; and it appears that this was a special situation because openSUSE Leap 45.1 did not contain the software package kernel-desktop, it likely having been discontinued, according to In an upgrade of an old Linux operating system with a new Linux operating system I suppose it ought to be safe to replace the kernel in the old Linux operating system with the kernel in the new Linux operating system, as long as the desktop, for example KDE, LXDE, Gnome, et cetera, appropriate for the old Linux kernel in the old Linux operating system can be upgraded with new versions of those desktops appropriate for the new Linux kernel in the new Linux operating system. And this assumes that all applications in each desktop work well with the kernel with which that desktop works.

When there is a large number of software packages to install by the first time picking and choosing them, for example many TeX Live software packages, plus a number of settings and a couple of passwords to avoid resetting after a “clean” installation of openSUSE Linux, I think it makes sense to perform an upgrade instead of a “clean” installation of openSUSE Linux. But from what I have learned in this experience here would be my approach to resolving kernel and virtualbox-guest conflicts, if they would occur in a future upgrade of openSUSE:

  1. Learn what version of the Linux kernel and its software package name the new version of openSUSE uses.
  2. Arrange to have all kernel-version-specific software packages in the old version of openSUSE replaced by their corresponding packages in the new version of openSUSE with its new version of the Linux kernel. I suspect this may automatically be done, except in the special cases when a package name changes, such as kernel-desktop in the old version being replaced by kernel-default in the new version of the openSUSE Linux operating system.
  3. The program for the upgrade may not allow the upgrade to continue if it detects software conflicts concerning software packages with names beginning with “virtualbox-guest”. So as to hopefully keep some folder-sharing settings in the upgrade, I recommend at first keeping one or more of those old virtualbox-guest… packages during the upgrading process.

After the upgrade is complete, from in the host operating system download the appropriate VBoxGuestAdditions_.iso file for the version () of VirtualBox being used. Using the above sudo zypper command remove all of the software packages with names beginning with virtualbox-guest… And continue as above with the zypper in …. command, ejecting any loaded VBOXADDI… optical drive shown in the file manager Konqueror or another file manager, and via the “Devices” menu in the window opened by “Start”ing the openSUSE operating system in VirtualBox inserting the downloaded .iso file, and inputting the sudo /…/… command. At least the latter command and perhaps some of the earlier zypper commands and “Devices” menu activity may need to be repeated in multiple desktops, such as the KDE and LXDE.

tldr but I noticed

to uninstall kernel-desktop 3.16.7-24.1, to install kernel-default 4.1.12-1.1, and to obtain version 5.0.8… of the VirtualBox Guest Additions by clicking on the hyperlink reading VboxGuestAdditions_5.0.8.iso on

you broke something in the guest operating system.
ps, it’s 42.1 not 45.1 and don’t double post

you had 13.2 in a VM and you changed it’s kernel from 3.16 to 4.1 just so that you can upgrade to LEAP 42.1 why?

as this is a duplicate of a mod might want to remove it or move it.