In VirtualBox 6.1.26 help needed for VirtualBox Guest Additions from Leap 15.3 to function

2009Newbie · October 14, 2021, 4:00am

I. Background and Introduction

My “host” operating system has been 64-bit Windows 10 Home Edition for a few years. In Oracle Virtual “Machine” (VM) VirtualBox I have since December of the year 2013 had an openSUSE operating system installed as a “guest” operating system or VM. In Leap-15.2 openSUSE from July 23, 2020 through May or so of the year 2021 a usually quite workable procedure for me to obtain working VirtualBox Guest Additions was by executing VBoxLinuxAdditions.run from Oracle Corporation’s VirtualBox after installing a kernel update in Leap 15.3 or a new version of VirtualBox in Windows 10. However, after upgrading Leap 15.2 to Leap 15.3 I could no longer reliably use this procedure to obtain working VirtualBox Guest Additions in Leap 15.3 with VirtualBox. That is I learned from Larry Finger and/or the Internet that the kernel code in Oracle Corporation’s VirtualBox was apparently for a version of the Linux kernel newer than supplied through openSUSE Leap repositories. So to enable Oracle Corporation’s VBoxLinuxAdditions.run to work properly in openSUSE Leap 15.3 currently requires an openSUSE Leap code writer or writers to backport some kernel code to probably produce a Leap-15.3, kernel-appropriate version of VBoxLinuxAdditions.run. But it appears that this backporting has not always been performed for each new version of VirtualBox from Oracle Corporation and for each new version of the Linux kernel supplied through openSUSE Leap repositories.

So the alternative for obtaining working VirtualBox Guest Additions has been for me to, instead of producing VirtualBox Guest Additions from the latest version of Oracle Corporation’s VirtualBox, to try to use VirtualBox Guest Additions which come with the Linux kernel or else the VirtualBox Guest Additions in one of the virtualbox-… software packages, which in each of those cases is supplied through openSUSE Leap repositories. (Note that this makes a total of three sources for VirtualBox Guest Additions. And when all three of them are simultaneously installed, I don’t know for certain all of the openSUSE rules or priority for determining which of those three sets of VirtualBox Guest Additions will actually be used.) But I found that one or more functions of the VirtualBox Guest Additions in my Leap-15.3 installation could unfortunately rather easily be lost after making some software changes in that installation. These functions include the sharing of contents between my Windows-10 “host” and Leap-15.3 “guest” operating systems through a folder set up within VirtualBox for them to share and the copying and “pasting” of text via the computer “clipboard” between those two operating systems. And sometimes I saw that three question marks appeared in a window while “booting” my Leap-15.3 installation toward its graphical login screen.

Thus far my sure means to recover from such malfunctions has been to restore data onto my computer’s internal hard-drive from a backup of those data previously written onto an external hard-drive drive when the VirtualBox Guest Additions were working well for me. However, recovering to a previous state of the computer software was not always a means to proceed with working VirtualBox Guest Additions through updated or altered computer software. So I would instead like to have a means to repair or reconfigure the VirtualBox Guest Additions after one or more of their functions have been lost due to some change in my Leap-15.3 computer software. My approach up to now to proceed onward from a working state of the VirtualBox Guest Additions has been one of attempting to learn what to do from postings on the Internet and to employ methods of guessing with trial and error. These approaches have recently been unproductive uses of my time, including the fact that the restoration of Leap-15.3 data from a hard-drive backup could take about nine hours of time. Furthermore the methods posters posted for obtaining working VirtualBox Guest Additions in versions of openSUSE prior to Leap 15.3 might not apply to Leap 15.3, due to changes in the openSUSE computer software over some years of time. So rather than continue in such a slow, trial-and-error approach I think it would make more sense for me to learn from people who already know how to recover or obtain the functions of VirtualBox Guest Additions from openSUSE Leap-15.3 repositories. So that is my goal here.
**
II. Symptoms of My Troubles, Some of My Attempts to Remedy The Troubles, and Some of My Mysteries**

With the installed software packages

virtualbox-guest-tools 6.1.26-lp153.2.9.3
virtualbox-guest-x11 6.1.26-lp153.2.9.3
virtualbox-guest-source 6.1.26-lp153.2.9.3
virtualbox-kmp-default 6.1.26_k5.3.18_59.19-lp153.2.9.2
virtualbox-kmp-preempt 6.1.26_k5.3.18_59.19-lp153.2.9.2,

the running Linux kernel version 5.3.18-59.19-default,
the installed Linux kernel versions kernel-default 5.3.18-59.24.1 and kernel-preempt 5.3.18-59.24.1, and

the installed version 6.1.26r145957 (Qt5.6.2) of Oracle VM (Virtual Machine) VirtualBox from Oracle Corporation, Larry Finger on https://bugzilla.opensuse.org/show_bug.cgi?id=1187011 wrote that with virtualbox-guest-source installed the command “sudo /sbin/vboxguestconfig” one can “build” VirtualBox Guest Additions. In addition, in order for vboxguestconfig to be installed in my Leap-15.3 installation from experience on August 17, 2021 I found that it was necessary to have the software package virtualbox-guest-tools installed. Below I show you what occurred after entering the command ./vboxguestconfig in the directory /sbin as a “root” user.

linux-hdi0:/sbin # ./vboxguestconfig
Kernel modules available. but we will continue...
virtualbox-guest-source package version doesn't match the version of virtualbox package.
This situation is probably not fatal, thus we will try to continue ..
Building kernel modules...

Build of VirtualBox guest kernel modules failed.
Look at /var/log/virtualbox.log to find reasons.
linux-hdi0:/sbin #

/var/log/virtualbox.log

=== Building 'vboxguest' module ===
make[1]: Entering directory '/usr/src/kernel-modules/additions/src/vboxguest'
make V= CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/5.3.18-59.19-default/build M=/usr/src/kernel-modules/additions/src/vboxguest SRCROOT=/usr/src/kernel-modules/additions/src/vboxguest -j2 modules
make[2]: Entering directory '/usr/src/linux-5.3.18-59.19-obj/x86_64/default'
  Building modules, stage 2.
  MODPOST 1 modules
make[2]: Leaving directory '/usr/src/linux-5.3.18-59.19-obj/x86_64/default'
make[1]: Leaving directory '/usr/src/kernel-modules/additions/src/vboxguest'

=== Building 'vboxsf' module ===
make[1]: Entering directory '/usr/src/kernel-modules/additions/src/vboxsf'
make V= CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/5.3.18-59.19-default/build M=/usr/src/kernel-modules/additions/src/vboxsf SRCROOT=/usr/src/kernel-modules/additions/src/vboxsf -j2 modules
make[2]: Entering directory '/usr/src/linux-5.3.18-59.19-obj/x86_64/default'
  Building modules, stage 2.
  MODPOST 1 modules
make[2]: Leaving directory '/usr/src/linux-5.3.18-59.19-obj/x86_64/default'
make[1]: Leaving directory '/usr/src/kernel-modules/additions/src/vboxsf'

=== Building 'vboxvideo' module ===
make[1]: Entering directory '/usr/src/kernel-modules/additions/src/vboxvideo'
make V= CONFIG_MODULE_SIG= CONFIG_MODULE_SIG_ALL= -C /lib/modules/5.3.18-59.19-default/build M=/usr/src/kernel-modules/additions/src/vboxvideo SRCROOT=/usr/src/kernel-modules/additions/src/vboxvideo -j2 modules
make[2]: Entering directory '/usr/src/linux-5.3.18-59.19-obj/x86_64/default'
  CC [M]  /usr/src/kernel-modules/additions/src/vboxvideo/vbox_drv.o
  CC [M]  /usr/src/kernel-modules/additions/src/vboxvideo/vbox_irq.o
/usr/src/kernel-modules/additions/src/vboxvideo/vbox_drv.c:311:6: error: ‘DRIVER_PRIME’ undeclared here (not in a function); did you mean ‘DRIVER_NAME’?
      DRIVER_PRIME |
      ^~~~~~~~~~~~
      DRIVER_NAME
make[4]: *** [/usr/src/linux-5.3.18-59.19/scripts/Makefile.build:288: /usr/src/kernel-modules/additions/src/vboxvideo/vbox_drv.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [/usr/src/linux-5.3.18-59.19/Makefile:1675: _module_/usr/src/kernel-modules/additions/src/vboxvideo] Error 2
make[2]: *** ../../../linux-5.3.18-59.19/Makefile:179: sub-make] Error 2
make[2]: Leaving directory '/usr/src/linux-5.3.18-59.19-obj/x86_64/default'
make[1]: *** [/usr/src/kernel-modules/additions/src/vboxvideo/Makefile-footer.gmk:117: vboxvideo] Error 2
make[1]: Leaving directory '/usr/src/kernel-modules/additions/src/vboxvideo'
make: *** [Makefile:65: vboxvideo] Error 1

Mystery 1

Note that the major part of the version 6.1.26-lp153.2.9.3 of the Leap-15.3 software package virtualbox-guest-source at the time matched the major part of the version 6.1.26r145957 (Qt5.6.2) of VirtualBox. In addition virtualbox-guest-tools 6.1.26-lp153.2.9.3, virtualbox-guest-x11 6.1.26-lp153.2.9.3, virtualbox-kmp-default 6.1.26_k5.3.18_59.19-lp153.2.9.2,
and virtualbox-kmp-preempt 6.1.26_k5.3.18_59.19-lp153.2.9.2 were installed. And even the version 5.3.18-59.19-default of the running Linux kernel matched the number 5.3.18_59.19 which appeared in the installed versions of virtualbox-kmp-default and virtualbox-kmp-preempt. Yet the output of vboxguestconfig included “virtualbox-guest-source package version doesn’t match the version of virtualbox package.”

Mystery 2

After executing vboxguestconfig, /var/log/virtualbox.log included

/usr/src/kernel-modules/additions/src/vboxvideo/vbox_drv.c:311:6: error: ‘DRIVER_PRIME’ undeclared here (not in a function); did you mean ‘DRIVER_NAME’?

, which appears to be evidence of a mismatch between two computer codes. Searching the Internet I found this same sort of message posted by poster IamSteve on https://www.virtualbox.org/ticket/19863. The writing following that posting is not very direct regarding the cause of such a message, but includes a mention of backporting associated with one or two versions of the Linux kernel. So this makes me wonder whether my trouble with a similar message could be due to missing kernel backporting code or not.

I guess that the command “rcvboxadd setup” might have been a way fix or configure some faulty VirtualBox Guest Additions. This command was reported to have worked well in Leap 15.1 by the poster RustyPuma on https://forums.virtualbox.org/viewtopic.php?t=94359. However, no file named rcvboxadd was found in my Leap-15.3 installation!

A major result:

In a hard-drive backup including Leap 15.3 I had VirtualBox 6.1.22 from Oracle Corporation installed, which I think was “inherited” from my Leap-15.2 installation which was upgraded to Leap 15.3. I restored that Leap-15.3 installation onto my computer’s internal hard-disk drive. Then on October 8, 2021 in the directory /opt as a “root” user I entered the command ./uninstall.sh to uninstall the VirtualBox Guest Additions produced from Oracle Corporation’s VirtualBox 6.1.22. By that time I was working with VirtualBox-6.1.24 software packages from openSUSE, Leap-15.3 repositories; and since August 2, 2021 I had VirtualBox 6.1.26 installed in my “host,” Windows-10 operating system. So it makes sense to abandon something to do with VirtualBox 6.1.22 when working with VirtualBox 6.1.24 software packages from Leap-15.3 repositories. But the result of that uninstallation was that I lost the VirtualBox Guest Addition functions of the copying and “pasting” of text between my Windows-10 and Leap-15.3 operating systems; and the folders in my Leap-15.3 directory /media/sf_HostFolder, which corresponded to my Windows-10 directory C:\HostFolder, were invisible in Leap 15.3, while generally visible in Windows 10.—So, more simply, the file- and folder-sharing capabilities of the folder set up in VirtualBox to be shared between the Windows-10 “host” and Leap-15.3 “guest” operating systems were lost. So, with some mystery on my part, these important functions of the VirtualBox Guest Additions were evidently linked with the installation of the VirtualBox Guest Additions from Oracle Corporation’s VirtualBox 6.1.22 and not linked to the VirtualBox Guest Additions included in the Leap-15.3 virtualbox-… software packages or to the VirtualBox Guest Additions which have been reported by Larry Finger to be included in recent Leap Linux kernels. Updating multiple, Leap-15.3, virtualbox software packages to versions including “6.1.26” and updating the default and preempt versions of the Linux kernel from version 5.3.18-lp59.19 to version 5.3.18-lp59.24 appear to have restored the copying and “pasting” functions between the “host” and “guest” operating systems. But the folders in /media/sf_HostFolder were still invisible in Leap 15.3. And on at least one occasion I saw three question marks on a window while “booting” toward the Leap-15.3 graphical login screen.

2009Newbie · October 14, 2021, 4:04am

A difficulty in entering commands in the terminal computer program LXTerminal in my Leap-15.3 installation was that due to the malfunctioning or non-functioning VirtualBox Guest Additions, the window provided by VirtualBox 6.1.26 for the Lightweight X windows system, version 11 (X11), Desktop Environment (LXDE) in my Leap-15.3 installation was that that the useful part of the LXDE window was often not resizable. A consequence of this problem was that sometimes the lowest line of text in LXTerminal could not be read. Nevertheless I tried a few more things or else collected some information by entering some commands.
As a regular user:

newbie@linux-hdi0:~> lsmod | grep vbox
vboxguest             380928  5
newbie@linux-hdi0:~>

So vboxsf was not running.

newbie@linux-hdi0:~> su
Password: 
linux-hdi0:/home/newbie # systemctl start vboxadd-service
Warning: The unit file, source configuration file or drop-ins of vboxadd-service.service changed on disk. Run 'systemctl daemon-reload' to reload units.
linux-hdi0:/home/newbie # systemctl daemon-reload
linux-hdi0:/home/newbie # systemctl start vboxadd-service
Warning: The unit file, source configuration file or drop-ins of vboxadd-service.service changed on disk. Run 'systemctl daemon-reload' to reload units.
linux-hdi0:/home/newbie # 

linux-hdi0:/home/newbie # systemctl enable vboxadd-service

Earlier after entering the above command I received the response of

Created symlink /etc/systemd/system/multi-user.target.wants/vboxadd-service.service→ /usr/lib/systemd/system/vboxadd-service.service

Later after entering that same command I received just a prompt in response.

linux-hdi0:/home/newbie # systemctl start vboxadd-service
Warning: The unit file, source configuration file or drop-ins of vboxadd-service.service changed on disk. Run 'systemctl daemon-reload' to reload units.
linux-hdi0:/home/newbie # systemctl daemon-reload
linux-hdi0:/home/newbie # systemctl start vboxadd-service
Warning: The unit file, source configuration file or drop-ins of vboxadd-service.service changed on disk. Run 'systemctl daemon-reload' to reload units.
linux-hdi0:/home/newbie # 

linux-hdi0:/home/newbie # VBoxClient --version
6.1.26_SUSEr145957
linux-hdi0:/home/newbie #

Conclusion

So perhaps with my report of the above data a knowledgeable person can inform me what to do now to restore the resizability of the useful part of the LXDE window and the sharing of files and folders between my Windows “host” and Leap-15.3 “guest” operating systems. Another problem which occurred, recently on October 13, 2021, is that sometimes three question marks could be seen en route to the graphical login screen for Leap 15.3. The general problem for which I would like a solution is how to configure VirtualBox Guest Additions obtained from openSUSE Leap-15.3 repositories or to restore its functions after losing one or more of its functions. Again I could restore all of the functions of the VirtualBox Guest Additions from a hard-drive backup which includes a working Leap-15.3 installation. But for the purpose of accommodating future changes in the computer software in my Leap-15.3 installation, as well as future versions of VirtualBox from Oracle Corporation in my “host,” Windows-10 operating system, I would like to be able to do better than that.

larryr · October 14, 2021, 3:00pm

You do not want any of the preempt stuff - it breaks VirtualBox guest (it did mine). Some update that was broken downloaded them - they are for real time Linux.

virtualbox-kmp-preempt 6.1.26_k5.3.18_59.19-lp153.2.9.2,

kernel-preempt 5.3.18-59.24.1

get rid of them and prevent them from reinstalling and validate they are locked.

zypper rm  virtualbox-kmp-preempt  kernel-preempt
zypper al virtualbox-kmp-preempt  kernel-preempt
zypper ll

reboot linux without the preempt kernel that causes the issue.

I found guest run better when I do not update virtualbox-guest-x11.

this is my locked guest (I use MATE rather than LXDE as desktop)

VM1:~ # zypper ll

# | Name                   | Type    | Repository
--+------------------------+---------+-----------
1 | kernel-preempt         | package | (any)
2 | virtualbox-guest-x11   | package | (any)
3 | virtualbox-kmp-preempt | package | (any)

VM1:~ #

2009Newbie · October 14, 2021, 9:34pm

A correction: My reference for Larry Finger mentioning that in effect the VirtualBox Guest Additions are included in a recent Linux kernel from openSUSE should have been https://bugzilla.opensuse.org/show_bug.cgi?id=1174048 on the Internet instead of https://bugzilla.opensuse.org/show_bug.cgi?id=1187011. Sorry, I made that error. Also I should have had a “III.” before my word “Conclusion” earlier in this “thread” of postings.

Thank you, poster larryr, for kindly taking some time to post some comments here. Unfortunately removing the preempt software packages from my present Leap-15.3 installation did not eliminate my problems with that installation. Given your comments concerning especially the preempt version of the Linux kernel causing you trouble in probably your Leap-15.3 installation, I think I should restore my Leap-15.3 Virtual “Machine” back to its working state with the preempt and default versions of the Linux kernel 5.3.18-59.19.1 from my hard-disk-drive backup written during October 7-8. 2021. Then after that I should try following your advice to remove the preempt software packages from my working Leap-15.3 installation and putting “locks” on those software packages and virtualbox-guest-x11 to prevent those software packages from being installed or updated in the future. I expect the restoration of my working Leap-15.3 installation from my hard-disk-drive backup to take about nine hours of time.

Concerning the file rcvboxadd, based on at least https://www.virtualbox.org/wiki/LinuxAdditionsDebug I am now supposing that it might have appeared in a Linux “guest” Virtual “Machine” after installing VirtualBox Guest Additions from Oracle Corporation’s VirtualBox’s executable file VBoxLinuxAdditions.run rather than via VirtualBox Guest Additions obtained through openSUSE, Leap-15.3 repositories. So when I do not have VirtualBox Guest Additions installed by executing Oracle Corporation’s executable file VBoxLinuxAdditions.run, this hypothetical explanation would be consistent with me not finding the file rcvboxadd in my Leap-15.3 installation. If a future problem would arise with VirtualBox Guest Additions obtained through openSUSE repositories, rather than via their production by executing Oracle Corporation’s VirtualBox file VBoxLinuxAdditions.run, I am still interested in obtaining a possible Linux command to restore or reconfigure VirtualBox Guest Additions back to a working state.

Sauerland · October 14, 2021, 9:45pm

Post:

zypper se -si kernel virtualbox

uname -a

Your Text is not easy to read for me, please use more often the Return key.

larryr · October 14, 2021, 11:52pm

If you have the Oracle VB extensions in 15.3 - I think they are in /opt

I did that once by mistake and had to uninstall VB and all the rpm’s with it.
I think there was an uninstall script in the /opt folder as well.

If you install OpenSUSE VirtualBox as a linux guest you should get a virtualbox-kmp-default for every kernel on your system - I never have to add guest additions to linux guest - just Windows.

2009Newbie · October 19, 2021, 2:11am

Correction: Looking at my notes from past restorations of my Leap-15.3 installations, including their /home directories, it took about six and two-thirds hours instead of nine hours for me to extract about a 90- to 93-gigabyte, Leap-15.3 virtual disk image (.vdi) file from a previously written hard-disk-drive backup. Sorry, I made that error twice or once in this “thread” of postings.

I think the VirtualBox Guest Additions kernel modules may be some .ko files contained in the Leap-15.3 software package virtualbox-kmp-default. Based on the version number of that package it appears that it has taken some time for Leap-15.3 developers to “catch up” with the latest released versions of both VirtualBox from Oracle Corporation and the Linux kernel from Leap-15.3 repositories. As for the VirtualBox Guest Additions, which according to Larry Finger are included in the Linux kernel (https://bugzilla.opensuse.org/show_bug.cgi?id=1174048 on the Internet) obtained from Leap-15.3 repositories, I have not studied the source code in the Leap-15.3 software package kernel-source-default to see whether the versions of VirtualBox Guest Additions included in a Linux kernel obtained from a Leap-15.3 repository are designed to match or not the installed version of VirtualBox installed in the “host” operating system and the Linux kernel in the Leap-15.3 “guest” operating system. But perhaps someone already knows whether or not the VirtualBox Guest Additions included in a Linux kernel obtained through Leap-15.3 repositories is designed to match the versions of both A) VirtualBox from Oracle Corporation that one is using and B) the Linux kernel in which VirtualBox Guest Additions are included and can testify to that matter here. And in my case I wonder if the version of VirtualBox in the Linux kernel came from /opt/VBoxGuestAdditions-6.1.22 or VirtualBox 6.1.26 installed in my Windows-10 “host” operating system, each of which probably came from Oracle Corporation.

On October 8, 2021 I uninstalled the VirtualBox Guest Additions from Oracle Corporation’s VirtualBox via as a “root” user the command

./uninstall.sh

in the directory /opt/VBoxGuestAdditions-6.1.22. But after “rebooting” into Leap 15.3 with the Linux kernel 5.3.18-59.19-preempt the result was the loss of the copying and “pasting” of text between my Windows-10 “host” and Leap-15.3 “guest” operating systems and that the folders in the folder shared between Windows 10 and Leap 15.3 were invisible in Leap 15.3. Based on larryr’s writing in this “thread” of postings those losses could perhaps be attributed to the use of the Linux kernel 5.3.18-59.19-preempt. Another possibility is that the good functioning of the VirtualBox Guest Additions somehow depended on the VirtualBox Guest Additions 6.1.22 I installed from Oracle Corporation’s VirtualBox. Lately I have instead been operating with the VirtualBox Guest Additions 6.1.22 still installed while using VirtualBox 6.1.26 from Oracle Corporation and updating the Linux kernel from Leap 15.3 repositories.

In my Leap-15.1 “guest” operating system with VirtualBox 6.1.10 in my Windows-10 “host” operating system on July 16, 2020 I lost the sharing of folders within the folder shared by my Windows-10 “host” and Leap “guest” operating systems after updating virtualbox-guest-x11, virtualbox-guest-tools, and virtualbox-kmp-default from versions 6.0.18.… to versions 6.0.22…. And this function was not restored by downgrading those three software packages back to versions 6.0.18…! And I don’t recall preempt versions of Linux kernels being available from Leap-15.1 repositories on July 16, 2020. My temporary solution during July 16-17, 2020 was to return to a working Leap-15.1 installation by means of a hard-disk-drive backup written on July 1-2, 2020.

In my Leap-15.3 installation I have been experimenting with a fairly conservative approach in the hope of obtaining at least temporarily working VirtualBox Guest Additions, as outlined below.

On October 16, 2021 I wrote a hard-disk-drive backup in which the VirtualBox Guest Additions work with

a) protections against updating away from versions 6.1.24… of the software packages virtualbox-guest-x11, virtualbox-guest-tools, virtualbox-guest-source, and virtualbox-kmp-default;

b) all preempt software packages have been uninstalled and kernel-preempt is listed in YaST2 (Yet another Setup Tool 2) as “taboo,” meaning to prevent kernel-preempt from being installed;

c) I kept VirtualBox Guest Additions 6.1.22 from Oracle Corporation installed in Leap 15.3 and VirtualBox 6.1.26 installed in Windows 10;

d) version 5.3.18-59.27.1 of kernel-default, kernel-devel, kernel-extra, and kernel-optional is installed, without protection against any of those software packages being updated.

e) I think I probably inherited from a Leap-15.3 repository probably a prohibition against installing the software package Mesa-dri-nouveau.

f) And since I found that on October 4, 2021 I had three question marks appear before reaching the Lightweight X Windows System, version 11 (X11), Desktop Environment (LXDE) in Leap 15.3 after on October 1, 2021 installing updates to probably at least the software packages

ca-certificates-mozilla,
kpartx,
libmpath0,
libpq5,
multipath-tools,
openSUSE-build-key,
openSUSE-release,
openSUSE-release-dvd, and
openSUSE-release-ftp,

I “locked” all of those software packages against being updated. In addition, in response to the “root”-user command

zypper locks

the product Leap was listed as locked. Perhaps that item will disappear from that list of locked products and packages after locks are removed from the software packages

openSUSE-build-key,
openSUSE-release,
openSUSE-release-dvd,
openSUSE-release-ftp,

and/or after a possible future software conflict permission is given to install some Leap-15.3 software package.

Let me define this working state of Leap-15.3 installations as “October 16, 2021 Backup.” After writing that backup I was free to experiment by installing updates to that working installation. My first experiment was to update ca-certificates-mozilla, a software package which, based on its name, I expected to have nothing to do with the functions of VirtualBox Guest Additions in my Leap-15.3 installation. But the disappointing result was that after updating ca-certificates-mozilla in October 16, Backup, I lost the sharing of folders in the folder shared between my Windows-10 “host” and Leap-15.3 “guest” operating systems!

Thank you, poster Sauerland, for also kindly taking some time to write something in this “thread” of postings. For poster Sauerland during the afternoon of October 16, 2021 in the state October 16, 2021 Backup, including when VirtualBox Guest Additions were working well, after “rebooting” into Leap 15.3 with Oracle Corporation’s VirtualBox 6.1.22 still installed, Linux kernel 5.3.18-59.27.1-default running, and Linux kernel 5.3.18-59.27.1-preempt not installed:

2009Newbie · October 19, 2021, 2:14am

newbie@linux-hdi0:~> su
Password: 
linux-hdi0:/home/newbie # zypper se -si kernel virtualbox
System management is locked by the application with pid 843 (/usr/bin/zypper).
Close this application before trying again.
linux-hdi0:/home/newbie # kill -9 843
linux-hdi0:/home/newbie # zypper se -si kernel virtualbox
Loading repository data...
Reading installed packages...

S  | Name                        | Type    | Version                          | Arch   | Repository
---+-----------------------------+---------+----------------------------------+--------+-------------------------------------------------------------
i+ | kernel-default              | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-59.10.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-57.3                      | x86_64 | Main Repository
i+ | kernel-default              | package | 5.3.18-57.3                      | x86_64 | openSUSE-Leap-15.3-1
i+ | kernel-default-devel        | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-devel        | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-devel        | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.10.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-optional     | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-optional     | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-optional     | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel                | package | 5.3.18-59.10.1                   | noarch | (System Packages)
i+ | kernel-devel                | package | 5.3.18-59.27.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel                | package | 5.3.18-59.19.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel                | package | 5.3.18-59.16.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-firmware-all         | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-all         | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-amdgpu      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-amdgpu      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ath10k      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ath10k      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ath11k      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ath11k      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-atheros     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-atheros     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-bluetooth   | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-bluetooth   | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-bnx2        | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-bnx2        | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-brcm        | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-brcm        | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-chelsio     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-chelsio     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-dpaa2       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-dpaa2       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-i915        | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-i915        | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-intel       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-intel       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-iwlwifi     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-iwlwifi     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-liquidio    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-liquidio    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-marvell     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-marvell     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-media       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-media       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-mediatek    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-mediatek    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-mellanox    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-mellanox    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-mwifiex     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-mwifiex     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-network     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-network     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-nfp         | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-nfp         | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-nvidia      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-nvidia      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-platform    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-platform    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-prestera    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-prestera    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-qlogic      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-qlogic      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-radeon      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-radeon      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-realtek     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-realtek     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-serial      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-serial      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-sound       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-sound       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ti          | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ti          | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ueagle      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ueagle      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-usb-network | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-usb-network | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-macros               | package | 5.3.18-59.27.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-source               | package | 5.3.18-59.27.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-source               | package | 5.3.18-59.19.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-source               | package | 5.3.18-59.16.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | purge-kernels-service       | package | 0-8.3.1                          | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | texlive-l3kernel            | package | 2017.133.svn44483-5.18           | noarch | Main Repository
i+ | texlive-l3kernel-doc        | package | 2017.133.svn44483-5.18           | noarch | Main Repository
il | virtualbox-guest-source     | package | 6.1.24-lp153.2.6.1               | noarch | Main Update Repository
il | virtualbox-guest-tools      | package | 6.1.24-lp153.2.6.1               | x86_64 | Main Update Repository
il | virtualbox-guest-x11        | package | 6.1.24-lp153.2.6.1               | x86_64 | Main Update Repository
il | virtualbox-kmp-default      | package | 6.1.24_k5.3.18_59.16-lp153.2.6.1 | x86_64 | Main Update Repository
il | virtualbox-kmp-default      | package | 6.1.22_k5.3.18_59.5-lp153.2.3.2  | x86_64 | Main Update Repository
il | virtualbox-kmp-default      | package | 6.1.20_k5.3.18_57-lp153.1.2      | x86_64 | Main Repository
il | virtualbox-kmp-default      | package | 6.1.20_k5.3.18_57-lp153.1.2      | x86_64 | openSUSE-Leap-15.3-1


For an extended search including not yet activated remote resources you may run
'zypper search-packages' at any time.
Do you want to run 'zypper search-packages' now? [yes/no/always/never] (no): yes

Could not parse the options: ambiguous option: -si
Could not search for the package: SocketError: Failed to open TCP connection to scc.suse.com:443 (getaddrinfo: Name or service not known)
Could not search for the package: SocketError: Failed to open TCP connection to scc.suse.com:443 (getaddrinfo: Name or service not known)
Could not search for the package: SocketError: Failed to open TCP connection to scc.suse.com:443 (getaddrinfo: Name or service not known)
No package found

linux-hdi0:/home/newbie # uname -a
Linux linux-hdi0 5.3.18-59.27-default #1 SMP Tue Oct 5 10:00:40 UTC 2021 (7df2404) x86_64 x86_64 x86_64 GNU/Linux
linux-hdi0:/home/newbie #

2009Newbie · October 19, 2021, 2:17am

After rebooting, installing the Leap-15.3 software package ca-certificates-mozilla, and finding folder sharing lost within the folder shared by Windows 10 and Leap 15.3 on the evening of October 16, 2021:

linux-hdi0:/home/newbie # zypper refresh
Repository 'Packman Repository' is up to date.                                  
Repository 'libdvdcss repository' is up to date.                                
Repository 'openSUSE-Leap-15.3-1' is up to date.                                
Repository 'Update repository of openSUSE Backports' is up to date.             
Repository 'Non-OSS Repository' is up to date.                                  
Repository 'Main Repository' is up to date.                                     
Repository 'Update repository with updates from SUSE Linux Enterprise 15' is up
to date.
                                                                                
Repository 'Main Update Repository' is up to date.                              
Repository 'Update Repository (Non-Oss)' is up to date.                         
All repositories have been refreshed.
linux-hdi0:/home/newbie # zypper se -si kernel virtualbox
Loading repository data...
Reading installed packages...

S  | Name                        | Type    | Version                          | Arch   | Repository
---+-----------------------------+---------+----------------------------------+--------+-------------------------------------------------------------
i+ | kernel-default              | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default              | package | 5.3.18-59.10.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-devel        | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-devel        | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-devel        | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-extra        | package | 5.3.18-59.10.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-optional     | package | 5.3.18-59.27.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-optional     | package | 5.3.18-59.19.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-default-optional     | package | 5.3.18-59.16.1                   | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel                | package | 5.3.18-59.10.1                   | noarch | (System Packages)
i+ | kernel-devel                | package | 5.3.18-59.27.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel                | package | 5.3.18-59.19.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-devel                | package | 5.3.18-59.16.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-firmware-all         | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-all         | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-amdgpu      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-amdgpu      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ath10k      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ath10k      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ath11k      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ath11k      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-atheros     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-atheros     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-bluetooth   | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-bluetooth   | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-bnx2        | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-bnx2        | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-brcm        | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-brcm        | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-chelsio     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-chelsio     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-dpaa2       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-dpaa2       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-i915        | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-i915        | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-intel       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-intel       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-iwlwifi     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-iwlwifi     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-liquidio    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-liquidio    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-marvell     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-marvell     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-media       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-media       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-mediatek    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-mediatek    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-mellanox    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-mellanox    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-mwifiex     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-mwifiex     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-network     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-network     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-nfp         | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-nfp         | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-nvidia      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-nvidia      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-platform    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-platform    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-prestera    | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-prestera    | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-qlogic      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-qlogic      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-radeon      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-radeon      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-realtek     | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-realtek     | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-serial      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-serial      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-sound       | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-sound       | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ti          | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ti          | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-ueagle      | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-ueagle      | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-firmware-usb-network | package | 20210208-2.4                     | noarch | Main Repository
i+ | kernel-firmware-usb-network | package | 20210208-2.4                     | noarch | openSUSE-Leap-15.3-1
i+ | kernel-macros               | package | 5.3.18-59.27.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-source               | package | 5.3.18-59.27.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-source               | package | 5.3.18-59.19.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | kernel-source               | package | 5.3.18-59.16.1                   | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | purge-kernels-service       | package | 0-8.3.1                          | noarch | Update repository with updates from SUSE Linux Enterprise 15
i+ | texlive-l3kernel            | package | 2017.133.svn44483-5.18           | noarch | Main Repository
i+ | texlive-l3kernel-doc        | package | 2017.133.svn44483-5.18           | noarch | Main Repository
il | virtualbox-guest-source     | package | 6.1.24-lp153.2.6.1               | noarch | Main Update Repository
il | virtualbox-guest-tools      | package | 6.1.24-lp153.2.6.1               | x86_64 | Main Update Repository
il | virtualbox-guest-x11        | package | 6.1.24-lp153.2.6.1               | x86_64 | Main Update Repository
il | virtualbox-kmp-default      | package | 6.1.24_k5.3.18_59.16-lp153.2.6.1 | x86_64 | Main Update Repository
il | virtualbox-kmp-default      | package | 6.1.22_k5.3.18_59.5-lp153.2.3.2  | x86_64 | Main Update Repository
il | virtualbox-kmp-default      | package | 6.1.20_k5.3.18_57-lp153.1.2      | x86_64 | Main Repository
il | virtualbox-kmp-default      | package | 6.1.20_k5.3.18_57-lp153.1.2      | x86_64 | openSUSE-Leap-15.3-1


For an extended search including not yet activated remote resources you may run
'zypper search-packages' at any time.
Do you want to run 'zypper search-packages' now? [yes/no/always/never] (no): no

linux-hdi0:/home/newbie # uname -a
Linux linux-hdi0.site 5.3.18-59.27-default #1 SMP Tue Oct 5 10:00:40 UTC 2021 (7df2404) x86_64 x86_64 x86_64 GNU/Linux
linux-hdi0:/home/newbie # 

linux-hdi0:/home/newbie # zypper locks

#  | Name                           | Type    | Repository
---+--------------------------------+---------+-----------
1  | Leap                           | product | (any)
2  | Mesa-dri-nouveau               | package | (any)
3  | kernel-preempt                 | package | (any)
4  | kernel-preempt-devel           | package | (any)
5  | kernel-preempt-extra           | package | (any)
6  | kernel-preempt-livepatch-devel | package | (any)
7  | kernel-preempt-optional        | package | (any)
8  | kpartx                         | package | (any)
9  | libmpath0                      | package | (any)
10 | libpq5                         | package | (any)
11 | multipath-tools                | package | (any)
12 | openSUSE-build-key             | package | (any)
13 | openSUSE-release               | package | (any)
14 | openSUSE-release-dvd           | package | (any)
15 | openSUSE-release-ftp           | package | (any)
16 | virtualbox-guest-source        | package | (any)
17 | virtualbox-guest-tools         | package | (any)
18 | virtualbox-guest-x11           | package | (any)
19 | virtualbox-kmp-default         | package | (any)
20 | virtualbox-kmp-preempt         | package | (any)

linux-hdi0:/home/newbie #

Assuming that the installation of ca-certificates-mozilla had nothing to do with the functions of VirtualBox Guest Additions, I wonder if the process of updating Leap 15.3 via the “root”-user command

zypper update ca-certificates-mozilla

or else just a “rebooting” somehow caused the loss of folder sharing in the folder shared by my Windows-10 “host” and Leap-15.3 “guest” operating systems.

2009Newbie · October 23, 2021, 3:16am

Thank you, posters larryr and Sauerland, for kindly taking some time to post some writing here.

The kernel modules provided by virtualbox-kmp-default 6.1.24… are

vboxdrv.ko,
vboxguest.ko,
vboxnetadp.ko,
vboxnetflt.ko, and
vboxsf.ko.

The October 16, 2021 portion of the file \var\log\messages might contain some clues to my trouble of in my Leap-15.3 installation failing to see the folders in my “host,” Windows folder C:\HostFolder shared with my “guest,” Leap-15.3 installation as /media/sf_HostFolder within VirtualBox 6.1.24… And I had a second shared folder: C:\VirtualBox in Windows 10 and /media/sf_VirtualBox in Leap 15.3. During the afternoon of that day, when VirtualBox Guest Additions were working well, \var\log\messages had

2021-10-16T13:07:31.090293-04:00 linux-hdi0 vboxadd-service.sh: VirtualBox Guest Addition service started.
2021-10-16T13:07:31.331442-04:00 linux-hdi0 kernel:   128.912888] vboxsf: g_fHostFeatures=0x8000000f g_fSfFeatures=0x1 g_uSfLastFunction=29
2021-10-16T13:07:31.331471-04:00 linux-hdi0 kernel:   128.913099] vboxsf: Successfully loaded version 6.1.24_SUSE r145751
2021-10-16T13:07:31.331477-04:00 linux-hdi0 kernel:   128.913163] vboxsf: Successfully loaded version 6.1.24_SUSE r145751 on 5.3.18-59.16-default SMP mod_unload modversions  (LINUX_VERSION_CODE=0x50312)
2021-10-16T13:07:31.360693-04:00 linux-hdi0 kernel:   128.941010] 17:07:31.353934 automount vbsvcAutomounterMountIt: Successfully mounted 'HostFolder' on '/media/sf_HostFolder'
2021-10-16T13:07:31.360729-04:00 linux-hdi0 kernel:   128.943248] 17:07:31.356200 automount vbsvcAutomounterMountIt: Successfully mounted 'VirtualBox' on '/media/sf_VirtualBox'

But there was a hint there that there might be future trouble with a tainting of the Linux kernel from

2021-10-16T13:06:57.858130-04:00 linux-hdi0 kernel:    10.278377] vboxguest: module verification failed: signature and/or required key missing - tainting kernel
2021-10-16T13:06:57.858160-04:00 linux-hdi0 kernel:    10.422628] vgdrvHeartbeatInit: Setting up heartbeat to trigger every 2000 milliseconds
2021-10-16T13:06:57.858166-04:00 linux-hdi0 kernel:    10.423139] input: Unspecified device as /devices/pci0000:00/0000:00:04.0/input/input4

From my reading of the Internet a tainted kernel is a kernel not supported by the community of, I presume in this case, Leap-15.3 code developers. The above, last-time-stamped line is a mystery for me.

2021-10-16T13:06:57.858169-04:00 linux-hdi0 kernel:    10.433703] libata version 3.00 loaded.

. However, there was apparently no apparent immediate trouble in loading the Linux kernel module vboxguest, based on

2021-10-16T13:06:57.858172-04:00 linux-hdi0 kernel:    10.434605] vboxguest: Successfully loaded version 6.1.24_SUSE r145751
2021-10-16T13:06:57.858175-04:00 linux-hdi0 kernel:    10.434703] vboxguest: misc device minor 56, IRQ 20, I/O port d020, MMIO at 00000000f0400000 (size 0x400000)
2021-10-16T13:06:57.858189-04:00 linux-hdi0 kernel:    10.434707] vboxguest: Successfully loaded version 6.1.24_SUSE r145751 (interface 0x00010004)

I presume that any change to the running Linux kernel would not be manifested until a later “boot” into Leap 15.3 using that tainted Linux kernel.

Then beginning at about 2:34 p.m., Eastern Daylight Saving Time, on October 16, 2021 I began writing a backup of my computer’s internal hard-disk drive onto an external hard-disk drive, a state of my computer’s software I defined as “October 16, 2021 Backup.” That backup process took four hours, 47 minutes, and 48 seconds of time to copy approximately 277 gigabytes of data from my computer’s internal hard-disk drive with a capacity or approximately 486 gigabytes.

Then during the evening of October 16, 2021 I “booted” into Leap 15.3 with the Linux kernel 5.3.18-59-27.1-default. Before unlocking and updating the software package ca-certificates-mozilla in /var/log /messages I had a very different set of messages from earlier that day:

2021-10-16T20:49:31.499121-04:00 linux-hdi0 vboxadd-service.sh: VirtualBox Guest Addition service started.
2021-10-16T20:49:31.503474-04:00 linux-hdi0 kernel:    63.547516] 00:49:31.502868 main     vbglR3GuestCtrlDetectPeekGetCancelSupport: Supported (#1)
2021-10-16T20:49:31.816451-04:00 linux-hdi0 kernel:    63.856958] 00:49:31.812437 automount Error: vbsvcAutomounterMountIt: Failed to mount 'HostFolder' on '/media/sf_HostFolder': No such device (-1,19)
2021-10-16T20:49:31.835546-04:00 linux-hdi0 kernel:    63.877133] 00:49:31.832610 automount Error: vbsvcAutomounterMountIt: Failed to mount 'VirtualBox' on '/media/sf_VirtualBox': No such device (-1,19)
2021-10-16T20:49:32.847514-04:00 linux-hdi0 kernel:    64.890281] 00:49:32.845703 automount Error: vbsvcAutomounterMountIt: Failed to mount 'HostFolder' on '/media/sf_HostFolder': No such device (-1,19)
2021-10-16T20:49:32.860393-04:00 linux-hdi0 kernel:    64.902969] 00:49:32.858564 automount Error: vbsvcAutomounterMountIt: Failed to mount 'VirtualBox' on '/media/sf_VirtualBox': No such device (-1,19)

Note that this time the kernel module vboxsf was not successfully loaded. And since ‘HostFolder’ could not be mounted and no such device as /media/sf_HostFolder could be found, it is clear that the installation of the software package ca-certificates-mozilla later that evening in my Leap-15.3 installation could not have been the cause of those reported problems!

In a search of the Internet I found a similar problem, including “vboxguest: module verification failed: signature and/or required key missing – tainting kernel” reported on https://www.virtualbox.org/ticket/15419 on the Internet and by Daniel Glasser on https://forums.virtualbox.org/viewtopic.php?f=3&t=77687. On the latter Web page Daniel Glasser wrote, “It seems as though GuestAdditions” (so probably VirtualBox Guest Additions) “is not signing, or is using the wrong key to sign, the kernel module it builds.” In the case of a tainted Linux kernel it is at least imaginable that a reinstallation of the Linux kernel could at least temporarily eliminate that tainting. However, if that reinstallation process would not cause any further problem, unless the cause of such tainting would be eliminated, I could expect the kernel to be tainted again by that cause after reinstalling that Linux kernel. And if the cause of folders being invisible in my shared folder is due to kernel tainting, then I could expect the folders to again be invisible in my shared folder. So in that case it would be better to find the exact cause of the kernel tainting and afterward to eliminate that cause. And unfortunately, although I don’t think I realized it when I wrote the backup of my internal hard-disk drive’s data onto an external hard-disk drive, I suppose that the Linux kernel 5.3.18-59.27.1-default in my hard-disk-drive backup may be tainted.

Sauerland · October 23, 2021, 9:03am

You use Virtualbox 6.1.26 but you lock the openSUSE Versions.
No good choice also the installed Versions of the openSUSE packages are 6.1.24, but in the Repo is 6.1.26 and soon also 6.1.28…

So i would say delete the locks on all Virtualbox packages.

I have not read the whole Thread because as I said its to hard to read for me.
Have you uninstalled the Virtualbox Guest Modules from the Virtualbox ISO?

PS:
Disable EFI in the Virtualbox Host configuration for openSUSE and you will get no bad signature error.

The cert for secure boot is in the shim package:

rpm -q --whatprovides /etc/uefi/certs/BCA4E38E-shim.crt
shim-15.4-4.7.1.x86_64

2009Newbie · October 26, 2021, 3:51am

I learned that beginning with VirtualBox 6.1.24 Oracle Corporation has been supporting SUSE (System Und System Entwicklung https://www.abbreviations.com/SUSE on the Internet]) Linux Enterprise Server 15, Service Pack 3 (https://9to5linux.com/virtualbox-6-1-24-released-with-support-for-linux-5-13-and-ubuntu-specific-kernels), which has since at least sometime in June of the year 2021 been using versions of the Linux kernel 5.3.18 (https://www.suse.com/support/kb/doc/?id=000019587), which is being used in Leap 15.3! So in my mind this seemed to mean that the backporting of code from VirtualBox 6.1.24 may not be necessary to adapt some VirtualBox code to work in Leap 15.3. And that could have meant that my preferred method of installing VirtualBox Guest Additions, similar to on https://en.opensuse.org/Virtualbox, by executing the executable file VBoxGuestAdditions.run from each version of VirtualBox beginning with version 6.1.24 of it could become possible. (With different version numbers for VirtualBox and the Linux kernel than now this was a general method which often worked quite well for my in Leap 15.2 for a number of versions of VirtualBox, but during those times probably as the result of some backporting work kindly performed by Larry Finger.)

So I decided to attempt that method in Leap 15.3 using VBoxLinuxAdditions.run from VirtualBox 6.1.26. But before attempting this method I performed some preliminary things in my Leap-15.3 installation. Below I outline those preliminary activities, as well as some later activities.

As a “root” user using a command or commands of the form

zypper removelock Package_Name1 Package_Name2

, listing perhaps even more than two software packages in such a form. I released some locks against changes to multiple software packages, but, in accordance with advice from poster larryr, continued to prevent installations of any software packages having the word “preempt” in them. In addition so far I have maintained a lock on the software package Mesa-dri-nouveau, a lock which I think I obtained from a Leap-15.3 repository on that software package, which is so far not installed in my Leap-15.3 installation. And I had a lock on “Leap” in response to the command

zypper locks

as a “root” user, a lock which I could not eliminate with a command similar to

zypper removelock Leap

, but which I found was eventually eliminated, as I explain in the following step 2 here.
2) To avoid possible problems due to non-working VirtualBox Guest Additions I think I tried to avoid “reboots” of my Leap-15.3 installation until this step 2 and the following steps 3 and 4 had been completed. As a “root” user I entered the commands

zypper refresh
zypper update

to update 157 software packages, several tens of which were texlive-… software packages, and probably to install one new software package. In the output of the command

zypper update

among among the packages which were reported would not be updated or else were reported as locked (against updating) was “openSUSE Leap 15.3”. In Yet another Setup Tool 2 (YaST2) I could see that the software package named “openSUSE” in the column labeled “Package” was in the “Summary” column called “openSUSE Leap 15.3”. I changed that software package’s status from “Protected-Do Not Modify” to “Update” and clicked on the software “button” labeled “Accept”. This action gratefully eliminated the line “Leap” in the results of the command

zypper locks

as a “root” user. Following advice in the ensuing output of the command

zypper update

I entered the command

systemctl daemon-reload

as a “root” user. The result was a Leap-15.3 installation quite different from my “October 16, 2021 Backup” state.

I uninstalled VirtualBox Guest Additions 6.1.22, which I had long ago obtained by entering the command

./VBoxLinuxAdditions.run

as a “root” user in the directory /run/media/newbie(my user name)/VBox_GAs-6.1.22 from Oracle Corporation’s VirtualBox 6.1.22, via the command as a “root” user

./uninstall.sh

in the directory /opt/VBoxGuestAdditions-6.1.22.

Then I had my Leap-15.3 installation in a state in which I could follow the instructions on https://en.opensuse.org/Virtualbox to install VirtualBox Guest Additions from Oracle Corporation’s VirtualBox 6.1.26’s executable file VBoxLinuxAdditions.run as a “root” user. However, the software package virtualbox-guest-kmp-default, mentioned on that Web page, was probably not installed in my Leap-15.3 installation. Gratefully with VirtualBox 6.1.26 in Leap 15.3 I did not see the discouraging message of “Look at /var/log/vboxadd-setup.log to find out what went wrong” that I had seen in an earlier attempt to have VirtualBox Guest Additions produced in my Leap-15.3 installation on June 3, 2021 using VirtualBox 6.1.22 from Oracle Corporation.
Finally after completing the above steps 2-4 I could attempt to “reboot” into Leap 15.3 and see what would occur. On the way toward the graphical login screen I saw three question marks instead of the Plymouth “splash” screen, as I think it may be called. But the good news was that the VirtualBox Guest Additions functions of the copying and “pasting” of text could be performed between my Windows-10 “host” and Leap-15.3 “guest” operating systems; and the folders in the folder C:\HostFolder (the Windows-10 path) shared by my Windows-10 “host” and Leap-15.3 “guest” operating systems could gratefully be seen in /media/sf_HostFolder in my Leap-15.3 installation! Furthermore the window for my Lightweight X Windows system, version 11(X11), Desktop Environment (LXDE) was nice and wide.–That is I found that when my LXDE window was horizontally narrow that at least sometimes that window was not resizable. So in a summary of the results, the functions of the VirtualBox Guest Additions were gratefully again working for me! And the appearance of the three question marks, though undesirable, during the “booting” process were inconsequential for my desired functions of the VirtualBox Guest Additions.
And I updated VirtualBox to version 6.1.28r147628, installed its extension pack, and, similar to in VirtualBox 6.1.26, executed VirtualBox 6.1.28’s executable file VBoxGuestAdditions.run. Gratefully the functions of VirtualBox Guest Additions mentioned in the above item 5 were still good with the Linux kernel 5.3.18-59.27.1-default!

I tried a few things in attempts to obtaining the Plymouth “splash” screen instead of the three question marks during “booting” into Leap 15.3 with the Linux kernel 5.3.18-59.27.1-default:

A) the “root”-user command (with help from poster broadstairs on https://forums.opensuse.org/showthread.php/519509-How-to-fix-plymouth-s-question-marks-forever)

plymouth-set-default-theme bgrt -R

;
as suggested by Martin Whitaker in “Comment 19” on https://bugs.mageia.org/show_bug.cgi?id=19642 for the following items B1 and B2,

B1) increasing and decreasing the value of DeviceTimeout. In my Leap-15.3 installation I found this variable set to its default value of 8, which I suppose might be for eight seconds, in the directory and file /usr/ share/plymouth/plymouth.defaults. As a “root” user I substituted 4, 16, and 32 for DeviceTimeout.

B2) With additional help from https://linux.die.net/man/8/dracut I added the kernel module vboxvideo to the initrd (initial ram disk) by inputting the following command as a “root” user:

dracut -f –add-drivers vboxvideo

.

C) In VirtualBox’s “Settings, Display” for the “Graphics Controller” I tried all of the settings there of VBoxVGA, VMSVGA, VBoxSVGA, and “None,” and attempted both with and without “3D Acceleration” the VMSVGA and VBoxVGA “Graphics Controller”s.

But unfortunately none of the methods A, B, or C was successful for me. However, eliminating the three question marks during “booting” into Leap 15.3 is not essential, since the functions of VirtualBox Guest Additions are gratefully good now for me in my Leap-15.3 installation. I found that the three question marks appeared during the “booting” toward the graphical login screen in Leap 15.3 using the Linux kernel 5.3.18-59.19.1-default on August 16, 2021, but not with the Linux kernel 5.3.18-59.16.1-default on August 7, 2021. When using the Linux kernel 5.3.18-59.19.1-default I could eliminate the appearance of the three question marks by the above method A. An interesting effect, which may be a clue to the cause of the three question marks for someone, is that the word “Leap” and a swirling white line have appeared normally in the late stage of either “rebooting” or shutting down my Leap-15.3 installation with the Linux kernel 5.3.18-59.27.1-default, but not during “booting” while approaching the graphical login screen. So the appearance of three question marks or not in that situation of mine was kernel-dependent. The poster Barry Jackson in “Comment 3” on https://bugs.mageia.org/show_bug.cgi?id=19642 also, in effect, reported a kernel dependence concerning the appearance of the three question marks or not in what was probably a Mageia operating system on one computer.

2009Newbie · October 27, 2021, 10:34pm

Sorry, poster Sauerland, I did not notice your October 23, 2021 posting in this “thread” of postings until October 27, 2021. That is I have been temporarily “caught” probably twice during interim periods of time in missing at least one person’s postings when they appeared on a second or later Web page of openSUSE “forum” postings in the same “thread” of postings. So while looking at just the first Web page of postings in a “thread” of them I did not see the second page of postings in such a “thread” of postings. And when looking at the first Web page of postings I could enter another posting in the “thread” of them with things looking quite normal on the first Web page of postings. But in such a Web-page-“overflow” situation a posting of mine was posted on the second Web page of postings so that it could not be seen on the first Web page of postings. And until recently my common habit has been to look just at the bottom of the first Web page of postings to see if anyone posted any comments in a “thread” I initiated. This situation is somewhat like someone reading someone’s letter on paper, getting to the bottom of the first page of it, and not realizing that the back of that sheet of paper has additional writing on it, unless the reader misses seeing the letter writer’s name at the bottom of such a letter or sees a message like “OVER;” “Turn the sheet over;” “More writing on the back of this sheet of paper,” et cetera. I realize that at the bottom of the first Web page of postings in such a page-“overflow” situation one can see “Page 1 of 2, Page 2 of 2”, et cetera. But if one does not notice those things or else does not remember or think that a “thread” could occupy more than one Web page, he may, in the transitional period of time when the second Web page begins to fill up, miss checking the second Web page of postings until he realizes that his latest posting cannot be seen on the first Web page of postings and then begins to think about what could have occurred. A suggestion: So it might be helpful to have some bold-lettered message on the first page of postings to alert posters and readers that there is more than one Web page of postings in a “thread” of them which could read something like, “NOTE: IN A NORMAL ‘OVERFLOW’ OF CONTENT THIS ‘THREAD’ OF POSTINGS HAS BEEN CONTINUED ON A LATER WEB PAGE. CLICK NEAR THE BOTTOM OR TOP OF THIS WEB PAGE TO ‘VISIT’ THE PAGE OF POSTINGS YOU WISH TO VIEW.” Otherwise, having encountered this kind of situation a couple of times by now, I think I am now more likely within at least several weeks of future time to remember that a “thread” of postings could occupy more than one Web page, if I would encounter it again in the future.

Thank you, poster Sauerland, for kindly taking some time to post some comments on October 23, 2021. As you may see from my October 25, 2021 posting in this “thread” of postings, I have made a major change in my approach to my problems with VirtualBox Guest Additions in my Leap-15.3 installation. This is because Oracle Corporation has, beginning with VirtualBox 6.1.24, very kindly in its VirtualBox code included support for the versions 5.3.18… of the Linux kernel that have recently been used in Leap 15.3! So this kind inclusion appears to me to have eliminated the need for Larry Finger (https://bugzilla.opensuse.org/show_bug.cgi?id=1187011 on the Internet) and perhaps some helpers to backport computer code to adapt Oracle Corporation’s VirtualBox computer code to make it work in Leap 15.3!

In response to your question of “Have you uninstalled the Virtualbox Guest Modules from the Virtualbox ISO?” (Industry Standard’s Organization, .iso file), that was the procedure which gratefully usually worked well for me in Leap 15.2. But in VirtualBox 6.1.22 in June of the year 2021 it no longer worked for me in Leap 15.3 while the backporting of computer code in Leap 15.3 had not been performed. And, rightly or wrongly, I assumed that that necessary backporting work had not been performed in Leap 15.3 during June through late October of the year 2021. So I abandoned the production of VirtualBox Guest Additions from Oracle Corporation’s .iso files until I gratefully discovered in late October of the year 2021 that Oracle Corporation had included support for the Linux kernel versions 5.3.18… beginning with its VirtualBox 6.1.24. Until late October of the year 2021 I was trying to get VirtualBox Guest Additions from Leap-15.3-supplied computer software to fully function for me. Sometimes I had VirtualBox Guest Additions working in that way for me; and sometimes I did not have them working for me in that way. But gratefully, using the procedure I outlined in my October 25, 2021 posting in this “thread” of postings, in VirtualBox 6.1.26 and 6.1.28 I could return to my preferred method on https://en.opensuse.org/Virtualbox on the Internet of having VirtualBox Guest Additions produced from Oracle Corporation’s VirtualBox supplied through a .iso file instead of using the VirtualBox Guest Additions supplied through Leap-15.3, online repositories of computer software. According to the method on https://en.opensuse.org/Virtualbox I no longer have the software packages virtualbox-guest-x11 and virtualbox-guest-tools installed in Leap 15.3, but do have the software package virtualbox-kmp-default installed in my Leap-15.3 installation. And although it is probably no longer necessary, I also currently have the Leap-15.3-repository-supplied software package virtualbox-guest-source installed in my Leap-15.3 installation.

It took me a while to realize what you probably meant by “no bad signature error” in your comment of “Disable EFI in the Virtualbox Host configuration for openSUSE and you will get no bad signature error.” I suppose that you were referring to the message “vboxguest: module verification failed: signature and/or required key missing - tainting kernel” which I received in /var/log/messages during the afternoon of October 16, 2021 and reported in my posting dated October 22, 2021 in this “thread” of postings. Thank you, poster Sauerland, for kindly taking the time to post your comments in this regard.

2009Newbie · October 30, 2021, 12:40am

A correction to my earlier writing in posting number 13, paragraph 3: From https://www.geeksforgeeks.org/iso-full-form/ on the Internet the abbreviation ISO correctly stands for International Organization for Standardization; and the file type or extension .iso, came from that organization. Sorry, I made the error of ISO incorrectly standing for Industry Standard’s Organization.

In my 64-bit, Windows-10, “host” operating system’s “Device Manager” under “Display adapters” I have “Intel(R) Graphics 4000” listed. And my Leap-15.3 installation is a Virtual “Machine” (VM) within Oracle VM VirtualBox, which is installed in my “host,” Windows-10 operating system.

While en route to the graphical login screen for Leap 15.3 using the Linux kernel 5.3.18-59.27.1-default I noticed that the three question marks appeared on a nearly square window. Somewhat later that nearly square window was replaced by a horizontally lengthy window in which the Plymouth “splash” screen appeared. I suppose that the initial nearly square window was at least for the appearance of the “boot menu” and that the horizontally long window was at least for the appearance of the Plymouth “splash” screen and graphical login screen. And those two windows may or may not have different pixel-times-pixel resolutions. Speculation on my part was that if the appearance of the Plymouth “splash” screen could be delayed in its appearance until the horizontally lengthy window appeared that perhaps the appearance of the three question marks on the nearly square screen during “booting” might be avoided.

However, initially instead of trying to delay the start of the Plymouth “splash” screen during “booting,” on October 28, 2021 I did what poster Fraser_Bell reported doing in posting number eight on https://forums.opensuse.org/showthread.php/533126-Leap-15-Spash-Screen-What-s-it-doing, which was to remove the software package plymouth and in my case to perhaps make it “Taboo” for being installed in the future. In addition, to resolve a software conflict I also removed the software package plymouth-dracut and in my case perhaps made it “Taboo” for being installed in the future. And I left about 15 other software packages containing the word “plymouth”, or else were needed by the software package plymouth, installed and free to be updated. In this way I could gratefully avoid the appearance of the three question marks during “booting” into Leap 15.3 with the Linux kernel 5.3.18-59.27.1-default; and, of course, the Plymouth “splash” screen was no longer visible during such “booting;” in fact at that time lines of text appeared on the window provided by VirtualBox for Leap 15.3 which I think may at least partly have detailed processes being started on the way to the graphical login screen for Leap 15.3. This arrangement could make it possible to after the installation of a future update of the Linux kernel to remove the “Taboos” against installing plymouth and plymouth-dracut; if needed, to have their latest versions installed; and then to try “booting” again into Leap 15.3 to see if the three questions marks would appear or not during “booting” while using the future Linux kernel.

I failed in an experiment attempting to prevent the appearance of the three question marks during “booting,” which I discuss two paragraphs later. During October 28-29, 2021 I restored my Leap-15.3 installation from a hard-disk-drive data backup written onto an external hard-disk drive on October 26, 2021. That data backup probably contained some computer software for the appearance of the Plymouth “splash” screen. After that restoration of my Leap-15.3 installation from October 26, 2021 I on October 29, 2021 updated my Leap-15.3 installation. Afterward I was surprised to learn that the software package “plymouth” was no longer installed in my Leap-15.3 installation and that a software package named “plymouth” was unavailable from Leap-15.3 repositories, which agreed with the statement of “There is no official package” (contextually for ‘plymouth’) “available for openSUSE Leap 15.3” posted on https://software.opensuse.org/package/plymouth.

So this meant that I needed a new procedure in order to avoid using the Plymouth “splash” screen. I chose poster Argedion’s procedure in posting number eight on https://forums.opensuse.org/showthread.php/494573-How-would-I-remove-the-splash-screen-at-boot-time. For me that procedure was via Yet another Setup Tool 2’s (YaST2’s) “System”, “Boot Loader” and on the “Kernel Parameters” tab to under “Optional Kernel Command Line Parameter” among other things there change “splash=silent” to “splash=verbose” and then to click on an “OK” software “button.” In this rearrangement I could leave all of the Plymouth-related computer software installed in my Leap-15.3 installation for possible future updating. And after installing a possible future update to the Linux kernel I could revert from “splash=verbose” back to “splash=silent” and see if the three question marks would appear or not during “booting,” with the Plymouth “splash” screen hopefully appearing in such a test. And if the three question marks would appear then during booting, I could return to “splash=verbose” in the “Optional Kernel Command Line Parameter”.

On October 29, 2021 I performed an experiment to try to delay the start of the Plymouth “splash” screen during “booting” long enough to hope to have it appear on the horizontally long window in which it actually has appeared in the process of shutting down Leap 15.3. I read on https://wiki.archusers.ir/index.php/Plymouth that beginning with version 0.9.0 of the Plymouth “splash” screen there is the parameter ShowDelay to introduce such a delay. And on October 28, 2021 I was using version 0.9.5 of Plymouth. In a search for “Display Manager” in YaST2’s Software Management I found that I had the X Display Manager (xdm) installed in my Leap-15.3 installation. I suspect that this is the variety of a display manager that I should be using, since the X Display Manager is designed to work in the X Windows System (https://en.wikipedia.org/wiki/X_display_manager) and since I have largely been using Leap 15.3 in the Lightweight X Windows System, version 11 (X11), Desktop Environment (LXDE). My approach was to follow the instructions for Arch Linux on https://wiki.archlinux.org/title/plymouth#Show_delay and with detailed commands on https://wiki.archusers.ir/index.php/Plymouth, but with the Gnome Display Manager, or gdm on https://wiki.archusers.ir/index.php/Plymouth replaced by my installed xdm. But unfortunately following those instructions too literally without doing enough thinking led to one or two major mistakes of mine.–Corresponding to the software package gdm-plymouth in those instructions for Arch Linux I did not first check to see if I had a Leap-15.3 software package xdm-plymouth installed or available from Leap-15.3, online repositories. Later I learned that there was no such software package available from Leap-15.3. It appears that the plan in the online instructions was to first disable the gdm.service and then in its place to enable gdm-plymouth.service. So with my replacement of xdm for me instead of gdm in those instructions I as a “root” user entered the command

systemctl disable xdm.service

. I discovered that that command did not just “turn off” the xdm.service, but probably removed some computer software because I saw the word “remove”, “removed”, or “removing” in “response” to that command. So later inputting the command

systemctl status xdm.service

led to the “reponse” of the xdm.service not being found, even though I still had xdm installed in my Leap-15.3 installation. I tried to recover from this mistake of mine by following the instructions of https://forums.opensuse.org/showthread.php/531191-gdm-service-does-not-exist, but for xdm for me instead of gdm in the original poster’s case. But unfortunately I could not recover from those one or two mistakes of mine.

So still during October 28-29, 2021 I restored my Leap-15.3 installation from an October 26, 2021 hard-disk-drive backup of mine, in which the xdm service worked for me, and later, while online, updated my Leap-15.3 installation. In the directory /etc/plymouth I copied the file plymouthd.conf.rpmnew, which contained the statement ShowDelay=0, to plymouthd.conf.rpmnewbackup via the command as a “root” user of

cp plymouthd.conf.rpmnew plymouthd.conf.rpmnewbackup

. Then as an experiment in the file plymouthd.conf.rpmnew I changed the value of the parameter of ShowDelay to “30” probably seconds, saved the file plymouthd.conf.rpmnew, and entered the command

plymouth-set-default-theme bgrt -R

to have new a initrd (initial ramdisk) file and a new initramfs (initial random-access memory file system, according to https://fedoramagazine.org/initramfs-dracut-and-the-dracut-emergency-shell/), image file produced. But on “booting” toward the graphical login screen in Leap 15.3 again, unfortunately the three question marks still appeared; and the Plymouth “splash” screen did not appear, probably because of the 30-second delay I introduced with the statement ShowDelay=30. So with the failure of this experiment I deleted the file plymouthd.conf.rpmnew and renamed plymouthd.conf.rpmnewbackup as plymouthd.conf.rpmnew; that is I returned the contents of plymouthd.conf.rpmnew to their state before the experiment I performed and just described.

2009Newbie · October 30, 2021, 12:47am

Correction: In my previous last paragraph “new a initrd (initial ramdisk) file” should have instead been “a new initrd (initial ramdisk) file.” Sorry, I made that error of, in effect, the ordering of the words “new” and “a.”

2009Newbie · November 2, 2021, 12:25am

A correction: Sorry, I should have spelled “boot loader” as “bootloader” in an earlier posting in this “thread” of postings.

In a Linux command I posted earlier in this “thread” of postings “cp” stood and stands for “copy”.

Concerning messages of the types

2021-11-01T16:11:58.181228-04:00 linux-hdi0 kernel:    82.076000] vboxvideo: loading out-of-tree module taints kernel.
2021-11-01T16:11:58.181296-04:00 linux-hdi0 kernel:    82.076096] vboxvideo: module verification failed: signature and/or required key missing - tainting kernel

, they still appeared in the file /var/log/messages on November 1, 2021 in the process of my “booting” toward the graphical login screen in my Leap-15.3 installation after installing some updates in that installation. I do not have the EFI (Extensible Firmware Interface) enabled on VirtualBox 6.1.28’s “Settings", “System”, "Motherboard” tab, which is the default setting there. So I am not using secure or EFI “boot” in VirtualBox 6.1.28 for Leap 15.3. [And I assume that the Unified Extensible Firmware Interface (UEFI) elsewhere in VirtualBox writing is the same as the Extensible Firmware Interface (EFI).] This latter comment is relevant because from https://www.virtualbox.org/manual/UserManual.html on the Internet, “If you are running on a system using UEFI (Unified Extensible Firmware Interface) Secure Boot, you may need to sign the following kernel modules before you can load them: vboxdrv, vboxnetadp, vboxnetflt, vboxpci”. So I do not think that signing kernel modules is necessary in openSUSE Leap 15.3 when not using EFI or secure “boot.”

Concerning the general type of “module verification failed: signature…tainting kernel” notification, poster TBOne on https://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/module-verification-failed-signature-and-or-required-key-missing-tainting-kernel-4175533442/ posted the helpful comments, “That message is nothing to worry about, and has absolutely NOTHING to do with secure boot or UEFI. All that means, is that you’re loading a kernel module that hasn’t been fully tested/integrated with the kernel you’re running. This message was intended to identify conditions which may make it difficult to properly troubleshoot a kernel problem. For example, loading a proprietary module can make kernel debug output unreliable because kernel developers don’t have access to the module’s source code (like the nVidia or ATI proprietary drivers), and can’t determine what that module may have done to the kernel. Likewise, if the kernel had previously experienced an error condition or if a serious hardware error had occurred, the debug information generated by the kernel may not be reliable.”

“The WORST case, is that any kernel errors you encounter will be ignored by the kernel developers, until the authors of that module have fixed it. If things are running fine, you’re in good shape, and there’s nothing really to worry about.”

Therefore I have a suggestion for Leap-15.3 developers to make one or two lines of text appear in the file /var/log/messages after a line including “module verification failed: signature and/or required key missing - tainting kernel”.–That is I suggest adding text there reading something like, “So if your Leap-15.3 installation is working well, you may ignore this message concerning tainting the kernel.” In this way a non-expert, openSUSE, Leap-15.3 user’s concern over “tainting the kernel,” in instances when there are no negative effects of such tainting, may be eliminated.

Another suggestion: A better idea of mine than earlier in this “thread” of postings concerning multiWeb-page “threads” in openSUSE forums could be, if at possible concerning possible computer software and available money, to make each “thread” just one Web page in length which just increases in length over time as postings are appended within it. In that situation a “thread’s” original poster could look at the bottom of that Web page’s postings to see if anyone posted any recent comments concerning his “thread;” and in the case of a lengthy Web page of postings readers might want to first check near the end of those postings to see what solution, if any, might have been posted there for a posted problem.

Again, as I explained in greater detail in an earlier posting in this “thread” of postings, I am avoiding the appearance of the three question marks which appeared during “booting” toward the graphical login screen in my Leap-15.3 installation by changing “splash=silent” to “splash=verbose” among the kernel parameters of my bootloader. (Of course it would be better if I had a direct solution to avoid the appearance of the three question marks during “booting” which could be applied in various versions of the Linux kernel.) So with that “workaround” solution my Leap-15.3 installation is gratefully working well now for my main, possible future purposes of 1) producing technical write-ups using the computer programs PDFLateχ, or pdflatex and bibtex, or BibTeχ; 2) the proper functioning of VirtualBox Guest Additions; and 3) the capability to download and install updates to my Leap-15.3 installation from online repositories. Therefore I should soon back up the data on my computer’s internal hard-disk drive onto an external hard-disk drive.

2009Newbie · November 2, 2021, 8:51pm

I think my 64-bit, Dell, Inspiron-15 notebook computer uses the Unified Extensive Firmware Interface (UEFI) for “booting” into my “host,” Windows 10 Home Edition operating system. However, I have had no experience “booting” openSUSE from within VirtualBox using the UEFI or probably the equivalent EFI (Extensible Firmware Interface). But based on https://www.virtualbox.org/manual/UserManual.html on the Internet, which includes,

“If you are running on a system using UEFI (Unified Extensible Firmware Interface) Secure Boot, you may need to sign the following kernel modules before you can load them: vboxdrv, vboxnetadp, vboxnetflt, vboxpci”,

after some thinking it seems that both poster TBOne’s writing, which I quoted, and one of my suggestions in my previous posting here may need a qualifier. That is if one is not using secure or EFI “booting” for the Linux “guest” operating system in VirtualBox, then a signature key may not be needed for a kernel module package (KMP) in that “guest” operating system. But if one is using EFI or secure “booting” for that “guest” operating system in VirtualBox, then I suppose that a signature key may be needed for a KMP. Accordingly I modify my second suggestion in my previous posting here for openSUSE developers to insert text in the file /var/log/messages after a line including “module verification failed: signature and/or required key missing - tainting kernel” to read,

“So if your Leap-15.3 installation is working well and you are not using secure or an Extensivle Firmware Interface (EFI) “booting” setting in Oracle Virtual Machine VirtualBox or else in your computer in which no hypervisor, such as Oracle Virtual Machine VirtualBox is installed, you may ignore the message before this sentence concerning tainting the kernel.”

From experience I have discovered that at least sometimes when my computer has been busy that I did not have a wide window provided by VirtualBox for Leap 15.3. And from experience that often indicated that VirtualBox Guest Additions would not fully function for me, particularly for resizing Leap-15.3’s window. The solution for that situation has been quite simple, namely to “boot” into Leap 15.3 when my computer is not so busy and then have the functions of VirtualBox Guest Additions. I did indeed produce a backup of the data on my Dell computer’s internal hard-disk drive.