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

Content edited slightly from November 4, 2015 and https://forums.opensuse.org/showthread.php/510605-Problems-attempting-an-upgrade-of-64-bit-openSUSE-13-2-to-Leap-45-1-within-VirtualBox-5-0-8?p=2735081#post2735081

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, https://forums.virtualbox.org/viewtopic.php?f=6&t=49528 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. After aborting the upgrade process in openSUSE 13.2 I could not 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.

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 could 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 guessed 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.

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 https://features.opensuse.org/319416 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 https://www.centos.org/forums/viewtopic.php?t=3811 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 https://en.opensuse.org/openSUSE:Leap#Kernel_Version 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 http://www.virtualbox.org/ 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 http://download.virtualbox.org/virtualbox/5.0.8 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 http://en.opensuse.org/VirtualBox. 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 http://download.virtualbox.org/virtualbox/5.0.8 and opened that file. Next I input a command of the form

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

. (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/VboxLinuxAdditions.run

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 https://features.opensuse.org/319416. 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 http://www.virtualbox.org/VirtualBox 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 /…/…VboxLinuxAdditions.run 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.

The basic description of the scenario is that an upgrade (change) failed mid-stream, leaving an inconsistent install.

In this case, virtualization is not a critical part of the solution but might have been part of the reason for the failed upgrade (unable to know for sure by now). In any case, the correct path to resolve is generic and would apply whether the machine is physical or virtual.

The most important factor when you have this kind of problem is whether you have Internet access.
If networking works, then you have more options than if you have no networking, and in that case recovery can require additional steps.

First the offline steps (thankfully not the case for the OP) if you don’t have networking…
You need to repair the system sufficiently to get networking.
First, try booting to Emergency/Repair mode in your Grub Menu options. If networking works, skip to the online recovery steps below.
If you can’t get networking to work, then use your DVD to repair your system, which will replace files with versions in the original release. Usually that is enough to get networking, and you can now skip down to the online recovery steps below.
If you can’t download a DVD, then you may have to try manual fixes from a LiveCD, but at this point your chances for success start becoming problematic because you’d have to be skilled to troubleshoot your system enough to use automatic tools.

Now, the online recovery steps…
You should be seeing a bootable system but it’s internally inconsistent… You may have wrong files, wrong versions of files, various parts of your system may be non-functional. But, if it boots and you have network access your chances are reasonably good for full recovery…

  1. Verify your existing configured repositories. You can do this using YAST or with the following zypper command
zypper lr

1a. Disable any repositories that shouldn’t be used. The OP described wanting to return to 13.2 but not finding the old repos… I submitted a bugzilla awhile back that repos should only be disabled (not removed) by default but the idea was rejected probably to simplify the User experience.** I strongly recommend only disabling, not removing old repos** until you know you won’t use them anymore unless you are willing to re-type in all the old repos if your upgrade is borked. My recommendation is both the non-default for any DVD upgrade and the SDB for upgrading (at this time).
1b. Enable the repos you wish to use. Whether this is the original repos or the new repos depends on whether you wish to recover to your original system or wish to continue to try to push forward (my guess is that most will want to try to recover to old instead of continue a risky path which already failed). A good recommendation as always is if you are experiencing problems to keep things simple and enable the OSS repo (no updates, no non-OSS, no Packman, no debug or source, etc).

  1. Do your actual online upgrade. I also recommend this step even if you did an offline upgrade to restore internal consistency to your system. An online upgrade is supposed to re-install everything (although you’ll verify later)
zypper dup
  1. After “zypper dup” you should be seeing a fundamentally working system although non-core apps may not work. Create your checklist what is working and what isn’t. Then,
    3a. Re-enable any repos besides OSS if they weren’t enabled during your “zypper dup” and do a “zypper up”
zypper up

3b. Some apps like virtualization will have to be re-installed completely to re-build the necessary kernel modules. Use the “-f” flag to force re-install the app even if YAST/zypper thinks the app is already installed

zypper in -f *packagename_list *

Speaking of which, virtualization is a special case application because of its requirement for special kernel modules nowadays, and it’s for that reason that these kinds of apps almost certainly never can be recovered without complete re-installation. You don’t have to remove the app first, and removing might not actually ensure a proper re-install in many cases because apps often don’t uninstall their config files so uninstall/re-install solves nothing. Do a “force re-install” as described to ensure that config files are over-written with new, default files. If force re-installing the virtualization app doesn’t work, then do a force re-install of the kernel first (which would remove the virtualization modules) first, then re-install the virtualization app.

HTH,
TSU

I’m not going to wade through the rest of this over long post but

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.

If this is true you did not upgrade correctly and the rest of your post is immaterial since not having the correct kernel indicates that the rest of the upgrade is probably wrong or at best partial.

So we are not really interested in your story so much as the facts

Sorry, I made the error of citing 45.1 instead of 42.1 in a 64-bit, openSUSE Leap, 42.1 Linux operating system. But for my and others’ benefits, thanks for mentioning and correcting this error of mine. I am not aware of any means for me to edit old openSUSE postings of mine. So this is a way for me to discuss and/or correct past errors of mine.

Correction: In my last sentence in the first paragraph of posting #2 in this “thread” I had too many “that"s in it. The beginning of the text there should instead read as " There were several clues to what that greater problem turned out to be: …” Sorry, I made that error.

Another correction for too many "that"s in my posting #2 in this “thread:”

‘B) In the “building” of one or more kernel modules via the command “sudo zypper in kernel-devel gcc make” I suppose that one or more Linux kernel modules…’

Sorry, I had two "that"s in a row before the above correction of the first portion of my sentence.

I am expecting to upgrade from version 42.1 to version 42.2 of 64-bit openSUSE Leap on or after November 17, 2016 when, based on what I read on https://www.opensuse.org/ on October 19, 2016, the community release of 64-bit openSUSE Leap 42.2 is expected to become publicly available. Given the considerable troubles I had in upgrading from 64-bit openSUSE 13.2 to 64-bit openSUSE Leap 42.1 which I have reported in this “thread,” I have been thinking about how to perform that upgrade hopefully without those kinds of previous troubles. So in this posting I have a combination of “looking” backward in time to hopefully avoid those types of difficulties I encountered in the past and “looking” forward in time to how perform this future upgrade.

“Looking” backward in time, when performing an upgrade from a Recordable Digital Video Disc (DVD-R) of openSUSE Leap 42.1 installation software, a major cause of my past trouble was likely that the software package kernel-default in openSUSE Leap 42.1 did not automatically replace the software package kernel-desktop in openSUSE 13.2. But based on https://features.opensuse.org/319416, the proposal was to modify kernel-default and drop kernel-desktop. So if that proposal was adopted, I am hoping this won’t be a problem in the upgrade from version 42.1 to 42.2 of 64-bit openSUSE Leap and will amount to an update of kernel-default in that part of that upgrade.

Concerning my past problem after the upgrade of a folder’s contents not immediately being shared between my Windows 10 host and openSUSE Leap 42.1 guest operating systems using VirtualBox Guest Additions, I noted that virtualbox-guest-kmp-default 5.0.26_k4.1.31_30-31.1 required kernel-default to be installed. Yet after the upgrade I had the openSUSE-13.2 kernel-desktop running, which used a lower-numbered version of the Linux kernel than the kernel-default I had installed. So in “looking” to the future upgrade from version 42.1 to 42.2 of 64-bit openSUSE Leap, I wonder if my past problem with VirtualBox Guest Additions might disappear after that upgrade, too, just by using a common version of kernel-default throughout openSUSE and not using the old kernel-desktop.

Based on what I have read within https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.update.osuse.html#sec.update.zypper, it appears that there will be at least two major choices for upgrading from version 42.1 to 42.2 of 64-bit openSUSE Leap: 1) via installation from a DVD-R of version-42.2 installation software, which has been referred to as via YaST (Yet another Software Tool), or 2) via one or more zypper commands. Option 1 appears simpler than option 2 to me. It appears to me that if I follow the recommendation that option 1 may be a combination of upgrading offline from the version-42.2, installation DVD-R and online to obtain updates and security fixes to 64-bit openSUSE Leap 42.2, if any of them will be available at that time. I wonder if the installation is so intelligently designed that instead of a file on the DVD-R that an updated version of it from online will instead be installed. Or perhaps the file from the DVD-R might first be installed and then be updated with possibly a more current version of it from an online repository. But either way I suppose that after the upgrade will have been completed while online that the installation of openSUSE Leap 42.2. will be up to date.

On October 19, 2016 gratefully the copy-and-paste function using the computer “clipboard” is working between my Windows 10 host and openSUSE Leap 42.1 guest operating systems via Oracle Virtual “Machine” (VM) VirtualBox 5.1.6r110634; and the contents of a folder I am sharing between Windows 10 and openSUSE Leap 42.1 are gratefully visible in each of those operating systems. To enable the sharing of the computer-”clipboard”’s contents between openSUSE Leap 42.1 and Windows 10 through VirtualBox I followed some instructions on https://www.liberiangeek.net/2013/09/copy-paste-virtualbox-host-guest-machines/.---Namely I clicked on VirtualBox’s “Settings” menu, then on “General,” then on the “Advanced” tab, and beside both “Shared Clipboard:” and “Drag’n’Drop:” I changed “Disabled” to “Bidirectional” and clicked on an “OK” button.

In 64-bit openSUSE Leap 42.1 these are the VirtualBox Guest Addition software packages I have installed:

virtualbox-guest-kmp version 5.0.26_k4.1.31_30-31.1,
virtualbox-guest-x11 version 5.0.26-31.1, and
virtualbox-guest-tools version 5.0.26-31.1.

Perhaps one or more of the above software packages might be updated in the upgrade from version 42.1 to 42.2 of 64-bit openSUSE Leap. I expect openSUSE Leap 42.2 to use a higher-numbered version of the Linux kernel than openSUSE Leap 42.1. For that reason and because virtualbox-guest-kmp requires kernel-default, I expect that at least virtualbox-guest-kmp, among the above three, virtualbox-guest-… software packages, to be updated in the upgrade of openSUSE Leap. And I hope that the settings I have within YaST2’s User and Group Management and Oracle VM VirtualBox that enable the sharing of computer-“clipboard” content and a folder’s contents will be preserved and transferred in the process of upgrading from version 42.1 to 42.2 of openSUSE Leap. But if not, I might need to go through the lengthy process of installing VirtualBox Guest Additions, setting folder permission, et cetera, that I described earlier in this “thread” of postings. I would not expect any settings within VirtualBox to be changed by that upgrade. Of course between October 19, 2016 and the day I hopefully perform that upgrade perhaps some of the software packages and computer programs will be updated to newer versions of them than I have listed here.

But what about the one or more kernel modules I had produced with the command “sudo zypper in kernel-devel gcc make” that I mentioned in posting #2 in this “thread” of postings? After the Linux kernel will presumably be updated in the future upgrade of openSUSE Leap, will that command have to be reissued? Or will the so- and past-”built” kernel modules automatically be updated to work with the updated version of the Linux kernel? I probably have had one or more kernel updates installed in openSUSE Leap 42.1 since I first tried to install 64-bit openSUSE Leap 42.1 on about November 4, 2015. But during the past several months I have not had to reissue that command. So this may be evidence that I might not need to reissue that command after the future upgrade of openSUSE Leap. If so, how could that be so? Are there commands in kernel-module codes which refer only to a file name like kernel without regard to its version number? If so, that’s one way I can at least imagine this phenomenon occurring.

  1. Any upgrade from one distro version to another is problematic unless you’re
  • Following an approved path. There are alwasy SDB guides that describe approved upgrade paths.
  • Only upgrades between official releases are supported. YMMV if you’re installing any alpha, beta or RC versions.
  1. Virtualbox is generally updated on its own schedule independently of the distro release.

  2. If you’re installing any Virtualbox Guest kernels, tools or other related packages from openSUSE, the code is pre-compiled. This means that you do not need kernel headers provided by kernel-devel, or any compiling tools like gcc and make. On the other hand, if you install Virtualbox as a download from the Oracle website, you’ll likely need those compiling tools.

HTH,
TSU

Thanks, TSU, for kindly taking some time to write something here. From https://en.opensuse.org/VirtualBox on the Internet, “However, as of openSUSE 11.4 the packaged Guest Additions version is slightly old, and may not allow use of Shared Folders with a Windows XP host for example.” However, in the case of a 64-bit openSUSE Leap, 42.1 guest operating system, based on my reading within https://www.virtualbox.org/manual/ch02.html#idm927, I am suspicious that the reason for a possible failure of this kind might not be within the software packages virtualbox-guest-kmp-default, virtualbox-guest-x11, and virtualbox-guest-x11 that 64-bit openSUSE Leap 42.1 repositories provide, but the need to “build” the kernel-appropriate kernel modules vboxdrv, vboxnetflt, and vboxnetadp with the software packages gcc, kernel-devel, and “make” installed and perhaps do other needed things by executing VBoxLinuxAdditions.run, an executable file provided within the VirtualBox Guest Additions .iso (International Standards Organization) file by Oracle Virtual “Machine” (VM) VirtualBox.

On October 19, 2016 I had VirtualBox updated to version 5.1.8r111374. And I noticed something interesting on October 22, 2016.—My installed version of the Linux kernel in openSUSE Leap 42.1 was updated to version 4.1.34-33.1 on that day. Yet my installed versions of virtualbox-guest-kmp-default, virtualbox-guest-tools, and virtualbox-guest-x11 in openSUSE Leap 42.1, which are each dated September 13, 2016, each has a portion 31.1 of an older Linux kernel version number within them. And the contents of the folder I have shared by my Windows-10 host and openSUSE Leap, 42.1 guest operating systems through VirtualBox are still visible in each of those operating systems. And I could gratefully still “copy” and “paste” text via the computer “clipboard” between text editors in those two operating systems through VirtualBox. This confirms what I earlier thought that after the VirtualBox Guest Additions have been installed once using the procedure involving compilation similar to what is posted on https://en.opensuse.org/VirtualBox, after that the VirtualBox Guest Additions performed well, even after an update of the Linux kernel.

This is not to write that I know with certainty why these successes occurred.–But one guess, similar to what I stated earlier, was that perhaps the Guest-Addition code references the Linux kernel by its file name and does not reference its version number; if so, then that Guest-Addition code would reference the new version of the kernel file that replaced the old version of it and keep on going. Without complete and certain knowledge on this matter, nevertheless I am grateful for these successes. And I wonder if these two kinds of Guest-Addition functions will still work after upgrading from version 42.1 to 42.2 of 64-bit openSUSE Leap 42.1.

First,
Linux and openSUSE like most computing technology has been advancing very quickly over the past few years…
A good rule of thumb is that anything written over a year or two ago should be viewed with some suspicion, and anything over 3 years old should be considered extremely suspect. Always inspect the versions of anything described in the content and match to what you are using… If there is more than one historical version exists between the content and what you are using, don’t consider the article reliable.

As for your kernel question, nowadays openSUSE supports multiple installed kernels by default, your Grub boot menu allows you to choose any installed kernels for that bootup.

TSU

On November 1, 2016 I saw on https://en.opensuse.org/Main_Page that the community release of openSUSE Leap 42.2 is scheduled to be released on, effectively, November 15, 2016. I can hope that with respect to the VirtualBox Guest Additions an upgrade from version 42.1 to version 42.2 of 64-bit openSUSE Leap will be like updating the Linux kernel in 64-bit openSUSE Leap 42.1. If so, based on the continued ability to share a folder between my openSUSE-Leap guest and Windows 10 host operating systems and to copy and “paste” text between text editors in those two operating systems after updating the Linux kernel in 64-bit openSUSE Leap 42.1, I could hope that the VirtualBox Guest Additions would still work after that future upgrade of 64-bit openSUSE Leap from version 42.1 to version 42.2 of it.

Thanks, TSU, for kindly posting something on October 25, 2016 in this “thread” of postings. I noticed that posting of yours after I wrote the above paragraph. I discovered that the version of the Linux kernel to use in an openSUSE session can be selected at “boot” time in Oracle Virtual “Machine” (VM) VirtualBox by in the first step pushing on a downward-pointing arrow key to select “Advanced options for openSUSE Leap 42.1” instead of “openSUSE Leap 42.1.” Based on the menu choices I saw then, this appeared to allow me to choose between two versions of the Linux kernel, the most recently installed one and probably the version of it installed before that one.

I apparently wrote the text below on November 1, 2016.

I can hope that with respect to the VirtualBox Guest Additions an upgrade from version 42.1 to version 42.2 of 64-bit openSUSE Leap will be like updating the Linux kernel in 64-bit openSUSE Leap 42.1. If so, based on the continued ability to share a folder between my openSUSE-Leap guest and Windows 10 host operating systems and to copy and “paste” text between text editors in those two operating systems after updating the Linux kernel in 64-bit openSUSE Leap 42.1, I could hope that the VirtualBox Guest Additions would still work after that future upgrade of 64-bit openSUSE Leap from version 42.1 to version 42.2 of it.

The community release of the International Standards Organization (.iso) file for the upgrade to or installation of the 64-bit, openSUSE, Leap, 42.2, Linux operating system appears to have actually taken place sometime during the morning of November 16, 2016, Eastern Standard Time; sorry, my earlier posting of the community release date for openSUSE Leap 42.2 was incorrect. During that same day in a process which began with that downloaded .iso file I upgraded my 64-bit, openSUSE, Leap, Linux operating system from version 42.1 to version 42.2 of it. Afterward gratefully the VirtualBox Guest Additions of sharing both a file and the contents of my computer-“clipboard” memory between my host, 64-bit, Windows 10 Home Edition and my guest, 64-bit, openSUSE, Leap, 42.2, Linux operating systems via Oracle Virtual “Machine” (VM) VirtualBox were able to be continued! In copying and “pasting” the text from a file in the text editor KWrite in the openSUSE system to the LibreOffice text editor Writer in the Windows-10 system I found it was important to first save the Writer document containing the text to be transferred in the 8-bit Uniform Transformation Format (UTF-8) encoding, which matched the encoding used in KWrite in the openSUSE, Linux operating system; in a transfer of text via the computer “clipboard” in the reverse direction from Writer to KWrite, I found the matching of the encodings in those two text editors to not be so critically important.–Nevertheless when the encodings in open documents in those two text editors were each UTF-8 and the Writer document had previously been saved in that encoding, the copying and “pasting” of text between those two text editors via the computer “clipboard” gratefully worked well. In the openSUSE system in these tests I used the Lightweight, X Windows System, version 11 (X11), Desktop Environment (LXDE), which appears to be a smaller version of the K Desktop Environment (KDE). Thanks to all of you who kindly worked on the procedure for upgrading from version 42.1 to version 42.2 of the 64-bit, openSUSE, Leap, Linux operating system to make that upgrade work so very well regarding the continuation of both these two functions of the VirtualBox Guest Additions and user groups within Yet another Software Tool 2’s (YaST2’s) User and Group Management!

Now I discuss some other interesting things I noted regarding this upgrade of the 64-bit, openSUSE, Leap, Linux operating system. I had openSUSE Leap 42.1 as one of my installed Virtual “Machines” (VMs) in VirtualBox. To begin the execution of the installation software on that DVD-R I found that it was insufficient to have my upgrade installation DVD-R in my computer’s DVD drive and click on VirtualBox’s “Start.” No, that just started the process of “booting” VirtualBox or my computer into openSUSE Leap 42.1. To instead have VirtualBox execute the installation program on that DVD-R, in VirtualBox I clicked on “Settings,” then on “System,” and then clicked on an upward-pointing arrow beside “Optical” to have my optical drive moved up to the top of the list in the “boot” order above “Hard Disk;” then I clicked on an “OK” software “button.” Then clicking on VirtualBox’s “Start” began the execution of the computer program on the openSUSE DVD-R for the purpose of either installing openSUSE Leap 42.2 or upgrading to it. After I completed this upgrade I returned to VirtualBox’s “Settings,” “System” to return the “boot” order to “Hard Drive” first and “Optical” second by clicking on an upward-pointing arrow beside “Hard Disk” and clicking on the software “OK” “button.”

As a part of this upgrade my installed version of the Linux kernel was updated from 4.1.34-33-default to 4.4.27-2-default. In the past I usually upgraded or made a so-called “clean” (not an upgrade) installation of openSUSE offline from an installation, Recordable Digital Video Disc (DVD-R) after “burning” the .iso image onto a DVD-R for such an upgrade or installation. This meant that afterward I probably updated some installed, openSUSE software packages while online somewhere where a fast Internet service was available free of charge to me. I remember only once performing such an upgrade while online via one or more commands. But in this most-recently completed upgrade of openSUSE I executed the openSUSE installation program from a so-produced DVD-R while online where a fast Internet service was available free of charge to me. And as such I found that this combined, upgrade-and-software-update process actually used a combination of offline and online methods.

This time I chose to read some of the online release notes on https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/#upgrade on the Internet for performing an upgrade of openSUSE. My 64-bit, Inspiron-15, 3521 Dell notebook computer uses a Synaptics touchpad. Those release notes included the statement reading, “The Synaptics X driver is no longer supported by GNOME” (GNU’s Not Unix [GNU] Object Model Environment). In openSUSE I have been using the Lightweight X Windows System, version 11 (X11), Desktop Environment (LXDE) and the K Desktop Environment (KDE). So without having read those release notes as carefully enough, perhaps it wasn’t necessary for me to uninstall the software package xf86-input-synaptics in openSUSE Leap 42.1 before upgrading it to openSUSE Leap 42.2; nevertheless, as recommended for the GNOME, I did so by entering the command “sudo zypper rm xf86-input-synaptics” followed by my pressing of the “Enter” key on my computer’s keyboard and then entering my root-user password. I entered those commands in the computer program LXTerminal in the LXDE in openSUSE Leap 42.1. But afterward surprisingly my computer’s touchpad continued to work well in openSUSE Leap 42.1! So because of that I just guess that openSUSE Leap 42.1 might have its own, non-firmware, software package installed at that time for the operation of my computer’s touchpad.

The command “uname -m” gave x86_64 for my computer’s “architecture.” So the part of the release notes on https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/#upgrade having to do with the AArch64 computer “architecture did not apply to my computer.

Sometime after selecting “Upgrade” I read something about the “non-oss” repository being non-free. But I also read that the non-oss repository is for computer programs like Flashplayer, Java, et cetera, which I recognized as including some computer programs which are available free of charge to the public. So for at least this reason I accepted the installation of a non-oss repository in my openSUSE Leap 42.2 installation.

After I accepted or agreed to a second, perhaps openSUSE license agreement and clicked on probably a software “button” labeled “Next,” I noticed an apparent rotating action within a small, mostly white-colored disc on my computer screen. In my host, Windows-10 operating system I opened the Windows Task Manager and found that data were being obtained from a “Network” by VirtualBox. Perhaps what occurred inside VirtualBox, such as the openSUSE upgrade software on my openSUSE upgrade DVD-R that was being executed at the time, might have been directly hidden to Windows 10. So I presume that during that time some data were being downloaded from the Internet as part of my openSUSE upgrade procedure. After that process was apparently completed, the next screen to appear contained a list of major actions to be performed regarding various kinds of computer software during the subsequent upgrade procedure. My agreeing to all of those actions and continuing in the upgrade process resulted in 2,740 software packages to be updated, 279 new software packages to be installed, and 125 software packages to be removed. After I clicked on the software “button” labeled “Start Update” and clicked on a tab I think labeled “Details,” I noticed that lots of downloading was taking place.—Unless the term downloading was then being used loosely for copying files from the installation DVD-R to my computer’s hard-disk drive, this could have meant that some files were being downloaded from the Internet.

After those actions were completed I was informed: “Package updates have been found in these additional repositories:”

“…openSUSE-Leap-42.2-Oss….”
“…openSUSE-Leap-42.2-Non-Oss…”

“Start the software manager to check and install these updates?”

I then clicked on a check box beside “Show package updates” and subsequently found at least one python software package, one guile software package, and lots of texlive-… software packages with green-colored check marks beside them. I clicked on the “Accept” software “button,” another “Accept” “button” for an Adobe license agreement, and on a “Continue” “button” to accept software changes needed to accommodate some software dependencies. This resulted in 1,923 more software packages being downloaded probably from the Internet and installed. In support of this hypothesis of those packages being downloaded from the Internet, I did not hear my computer’s DVD drive spinning during such downloading and installing, as would have otherwise been the case if the necessary files would have been obtained from my installation DVD-R instead of from the Internet. Among the files or software packages being downloaded and installed I found wine-gecko, baloo-core, fcitx-config-kde4, gnumeric, and choqok in some of their names, which were not software packages with names beginning with “texlive.” So I guess to keep the size of the installation .iso such that “burning” its image onto a DVD-R would not overfill one, single-layer, 4.7-GigaByte (GB) DVD-R, some software packages, particularly many Teχ Live software packages may not have been included in the openSUSE, .iso, installation-and-upgrade file so that updates to those software packages were being obtained from the Internet while my computer was still online.

In limited use since my most recent upgrade to 64-bit openSUSE Leap 42.2 Linux I have so far tested a few things and gratefully found them to work well in the LXDE. For a fictitious LaTeχ-coded file with a name of the form MyLaTeXFile.tex in the computer program LXTerminal I entered the commands:

pdflatex MyLaTeXFile.tex (twice)
bibtex MyLaTeXFile (twice)
pdflatex MyLaTeXFile.tex (twice)

with a previously prepared file with a name of the form MyLaTeXFile.bib containing references to books and one or more Internet Web pages.

The openSUSE text editors Kate and KWrite appeared to work in openSUSE Leap 42.2. While online in openSUSE Leap 42.2 I could reach three Web pages in the Mozilla Firefox Web browser. With the computer program Okular I could see the contents of the file with a name of the form MyLaTeXFile.pdf produced by executions of the above pdflatex and bibtex commands. My regular and root-user passwords in openSUSE Leap were transferred properly from version 42.1 to version 42.2 of it. My openSUSE /home folder, which is probably on a partition on my virtual “hard drive” separate from my installation of the openSUSE Leap 42.2 operating system, appears to have been left undisturbed in the upgrade from version 42.1 to 42.2 of openSUSE Leap. My desktop shortcuts from openSUSE Leap 42.1 are still present on the desktop of openSUSE Leap 42.2 in the LXDE. Gratefully I can use the Konqueror file manager in version 42.2 as I could in version 42.1 of 64-bit openSUSE Leap.

So far in limited use of my installation of the 64-bit, openSUSE, Leap, 42.2, Linux operating system the only problem, but one which can easily be avoided, that I noticed in openSUSE Leap 42.2 was that at the login screen for openSUSE 42.2 I saw my name, rather than my chosen, openSUSE user name being displayed. Instead choosing “Other” and then entering my openSUSE user name and regular openSUSE password resulted in a PolicyKit error being reported to me which I think was something to the effect that that user name had already been used or assigned.—But nevertheless, via that “route” using “Other” and my openSUSE user name I could still enter the LXDE of openSUSE 42.2! So this PolicyKit error in my case was not consequential toward entering openSUSE Leap 42.2’s LXDE.

After having looked at the release notes before making this upgrade of openSUSE I wonder if some of my past problems in upgrading or installing previous versions of openSUSE could have been avoided by my reading and following some instructions in such release notes, if they were available at those times, before upgrading or installing openSUSE. Overall I am very pleased that gratefully this upgrade of 64-bit, openSUSE Leap from version 42.1 to version 42.2 of it worked very well for me! Thanks, all of you developers!—Put together you appear to have performed your tasks very well! And thanks for providing this upgrade free of charge to the world!

In 64-bit openSUSE Leap 42.2’s Yet Another Software Tool 2’s (YaST2’s) Software Manager I searched for software packages with “synaptics” in their names and found that the software packages gsynaptics, gsynapitcs-lang, and xf86-input-synaptics were already installed after my upgrade from version 42.1 to version 42.2 of 64-bit openSUSE Leap. Again the release notes on https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/42.2/#upgrade on the Internet advised removing xf86-input-synaptics from openSUSE Leap 42.1 prior to an upgrade to openSUSE Leap 42.2 when the GNU’s Not Unix (GNU) Object Model Environment (GNOME) will be used in it. But I may be largely using the Lightweight X Windows System, version 11 (X11) Desktop Environment (LXDE) and not the GNOME in 64-bit openSUSE 42.2. So it appears to have been my mistake to not notice or not pay sufficient attention to the GNOME detail in those release notes for me to have uninstalled xf86-input-synaptics from 64-bit openSUSE Leap 42.1 before upgrading it to 64-bit openSUSE Leap 42.2. In effect the upgrade process corrected for my human error regarding the software appropriate for my Dell computer’s Synaptics touchpad! So thank you, people, who designed such a good upgrading process to correct for even my human error!