Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

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

  1. #11
    Join Date
    Mar 2011
    Location
    Sauerland
    Posts
    6,630

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

    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:
    Code:
    rpm -q --whatprovides /etc/uefi/certs/BCA4E38E-shim.crt
    shim-15.4-4.7.1.x86_64
    Last edited by Sauerland; 23-Oct-2021 at 00:11.

  2. #12

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

    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...ecific-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.

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

    Code:
    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

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

    Code:
    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

    Code:
    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

    Code:
    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

    Code:
    zypper locks
    as a “root” user. Following advice in the ensuing output of the command

    Code:
    zypper update
    I entered the command

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

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

    Code:
    ./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

    Code:
    ./uninstall.sh
    in the directory /opt/VBoxGuestAdditions-6.1.22.

    4) 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.

    5) 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.

    6) 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/showthre...-marks-forever)

    Code:
    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:

    Code:
    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.

  3. #13

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

    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.

  4. #14

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

    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/showthre...hat-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/showthre...n-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
    Code:
    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
    Code:
    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/showthre...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
    Code:
    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
    Code:
    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...ergency-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.

  5. #15

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

    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."

  6. #16

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

    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

    Code:
    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/quest...el-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.

  7. #17

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

    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.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •