http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 Bug ID: 1187011 Summary: Unable to have VirtualBox 6.1.22 Guest Additions "built" in Leap 15.3's two, supplied, Linux kernels Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Virtualization:Tools Assignee: virt-bugs@suse.de Reporter: l_pat_s@hotmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 850054 --> http://bugzilla.opensuse.org/attachment.cgi?id=850054&action=edit A report of errors during an attempt to have VirtualBox Guest Additions "built A One-Paragraph Summary After upgrading Leap from version 15.2 to version 15.3 of it in VirtualBox, in Leap 15.3 I could not have VirtualBox Guest Additions ���built��� for VirtualBox 6.1.22 and either one of the Leap-15.3 Linux kernels 5.3.18-57.3-default or 5.3.18-57.3-preempt using VirtualBox���s command ./VBoxLinuxAdditions.run. I include some vboxadd-setup.log files containing error messages near the ends of them. There is likely incompatibility between the codes of VirtualBox 6.1.22 and each of those two Linux kernels. But gratefully I could eventually have VirtualBox Guest Additions, which appear to have been ���inherited��� from Leap 15.2, working in Leap 15.3 for VirtualBox 6.1.22 and the Linux kernel 5.3.18-lp152.75.1.x86_64-default from Leap 15.2. And in Leap 15.3 I could have ���host���-to-���guest��� file sharing and text copying and ���pasting��� via the computer ���clipboard��� between my ���host,��� Windows-10 and ���guest,��� Leap-15.3 operating systems using either VirtualBox Guest Additions based on VirtualBox 6.1.20 and the Linux kernel 5.3.18-57.3-default or VirtualBox Guest Additions ���built��� in Leap 15.2 from VirtualBox 6.1.22 and the Linux kernel 5.3.18-lp152.75.1.x86_64. I gratefully obtained a better short-term result after updating my upgrade from version 15.2 to version 15.3 of the 64-bit, openSUSE, Leap, Linux operating system in June of the year 2021 than initially from attempting to update my upgrade of version 15.1 to version 15.2 of Leap in July of the year 2020 (a year-2020 reference: my contributions to https://bugzilla.opensuse.org/show_bug.cgi?id=1174048 on the Internet). Regarding VirtualBox Guest Additions (VBGA) my preference has been to have them made from computer software supplied with each new edition of Oracle Virtual ���Machine��� (VM) VirtualBox (VirtualBox), more specifically by entering the command ���./VBoxLinuxAdditions.run���, after installing either an update of the Linux kernel provided through an openSUSE Leap repository or an update of VirtualBox made available by VirtualBox. The procedure for ���building��� the VBGA in this way is on the Web page https://en.opensuse.org/VirtualBox. In essence it is to remove or delete the software packages virtualbox-guest-tools and virtualbox-guest-x11 or every software package with the beginning of its name reading as ���virtualbox-guest-������ supplied through openSUSE repositories and then for the running kernel, with compatible ���kernel-devel���, ���gcc���, and ���make��� software packages installed in openSUSE, to enter the command ���./VBoxLinuxAdditions.run��� using the file VBoxLinuxAdditions.run supplied by the currently installed version of VirtualBox. In that way, if the computer code in the Linux kernel is compatible with the computer code in the installed version of VirtualBox, hopefully there will be a workable match between the versions of the Linux kernel and VirtualBox ���built��� into the VBGA. And, as I have recently realized, at least partly, if not wholly, from my reading of a posting on on https://unix.stackexchange.com/questions/570240/virtualbox-guest-additions-e..., to produce those VBGA for the currently running kernel probably the versions of kernel-devel, kernel-source, and the running kernel had to match for that procedure to be successful. In addition to having the basic functions of the VBGA for the displays of windows in Leap, I like having the additional functions of a) being able to copy and ���paste��� text via the computer ���clipboard��� between my Windows-10 ���host��� operating system and my Leap ���guest��� operating system and b) being able to share and/or transfer files between my Windows and Leap operating systems through a folder those two operating systems share. Before my upgrade of Leap 15.2 to Leap 15.3 in 64-bit Windows 10 Home Edition I had VirtualBox 6.1.22r144080 (Qt5.6.2) installed with Leap 15.2 installed as a Virtual ���Machine��� (VM) within VirtualBox using the Linux kernel version 5.3.18-lp152.75.1.x86_64. After I offline upgraded Leap 15.2 to Leap 15.3 and then online updated that Leap-15.3 installation, unfortunately the procedure to ���build��� the VBGA that I discussed in the preceding paragraph failed to work for me after ���booting��� my computer into Leap 15.3 with either of the two Linux kernel versions 5.3.18-57-default, which was really kernel-default-5.3.18-57.3.x86_64, or 5.3.18-57-preempt provided for use in Leap 15.3. I remade those tests and obtained details of the errors reported in the following files included in this posting: while using Linux kernel 5.3.18-57-preempt and VirtualBox 6.1.22: vboxadd-setup.log.1 of 6:20 p.m., June 5, 2021; vboxadd-setup.log.2 of 6:21 p.m., June 5, 2021; while using Linux kernel 5.3.18-57-default and VirtualBox 6.1.22: vboxadd-setup.log.4 (4:24 p.m., June 5, 2021) There was another vboxadd-setup.log file produced as a result of this test, with probably double the size of the vboxadd-setup.log.4 which I include here, but which was probably automatically deleted. Matters for which I lack direct, definite explanations are 1) why some text in half of the so-produced vboxadd-setup.log files was in a red color and why that same text was in a black color in the other half of the vboxadd-setup.log files, 2) why two vboxadd-setup.log files were produced for each such test, and 3) why probably half of those files had the double the sizes of the other so-produced files. In addition, with my numerous deletings and reinstallations of the software packages virtualbox-guest-tools and virtualbox-guest-x11 installed in Leap 15.3 using the Linux kernel 5.3.18-57-default I at least temporarily lost the file-sharing capability using a folder shared by Windows-10 ���host��� operating system and the Leap ���guest��� operating system in VirtualBox 6.1.22 that I had in Leap 15.2; but later I gratefully had that file-sharing capability in Leap 15.3. And the copying and ���pasting��� of text between Windows 10 and Leap 15.3 with kernel 5.3-18-57-default has gratefully been working for me as it did in Leap 15.2. Eventually I noted that the versions of the installed software packages kernel-devel and kernel-source were the same as the version number 5.3.18-57 of the Linux kernel versions 5.3.18-57-default and 5.3.18-57-preempt supplied with Leap 15.3. During the offline upgrade of Leap 15.2 to Leap 15.3 I noted two software packages with ���virtualbox��� and ���6.1.20 in their names: virtualbox-kmp-default-6.1.20_k5.3.18_57-lp153.1.2.x86_64.rpm and virtualbox-guest-tools 6.1.20��� (A relatively unimportant matter in my logic here is that on my notes I don���t have any hyphen or period between ���virtualbox-guest-tools��� and ���6.1.20��� in that latter file name; though there might have been a hyphen or period there.). So it appears that some ���virtualbox-...���-named computer software supplied with Leap 15.3 during the time interval June 2-6, 2021 was ���built��� using VirtualBox 6.1.20. Since the VBGA could successfully be produced in Leap 15.2 using VirtualBox 6.1.22���s file VBoxLinuxAdditions.run and the Linux kernel version 5.3.18-lp152.75.1.x86_64, I think I initially thought that arrangement would also be successful in Leap 15.3 when Leap 15.3 would be ���booted��� using the Linux kernel version 5.3.18-lp152.75.1.x86_64 or 5.3.18-lp152.75-default. After putting the kernel version 5.3.18-lp175.75.1.x86_64 at the beginning of the list of kernels in the statement ���multiversion.kernels=latest,latest-1,running��� in the file /etc/zypp/zypp.conf as a root user and with help from quesomanrulz on https://www.youtube.com/watch?v=TDf_fRAophic and using the grub (GRand Unified Bootloader) update command grub2-mkconfig -o /boot/grub2/grub.cfg from the poster PiElle on https://forums.opensuse.org/showthread.php/477980-grub2-update-grub on the Internet I gratefully found a way to make such ���booting��� occur. However, the result of implementing a procedure similar to in the first paragraph of this posting was ���Kernel headers not found for target kernel.��� But I found that although at the time Leap 15.3 was running using the Linux kernel 5.3.18-lp152.75.1.x86_64 or 5.3.18-lp152.75-default, according to YaST2���s (Yet another Software Tool2���s) Software Management the installed versions of kernel-default and kernel-source were each 5.3.18-57.3; the installed version of ���gcc,��� probably standing for GNU���s Not Unix (GNU) Compiler Collection, was 7-3.3.22; and the installed version of ���make��� was 4.2.1-7.3.2. So I suspect that the failure to ���build��� the VBGA in Leap 15.3, using the Linux-kernel and VirtualBox versions which worked for ���building��� the VBGA in Leap 15.2, was likely because the version 5.3.18-57.. of both kernel-devel and kernel-source that I had installed in Leap 15.3 was not the same as the version 5.3.18-lp152.75... of the Linux kernel I had running during that attempt to have the VBGA ���built��� using the command from VirtualBox 6.1.22 of ���./VBoxLinuxAdditions.run���. And the error message ���Kernel headers not found for target kernel��� made sense after I learned that the kernel headers were reported to be in the software package entitled kernel-devel (https://superuser.com/questions/1532590/guest-additional-kernel-headers-not-..., posters Reda Salih and Frederick Alvarez); so when the versions of the installed software package kernel-devel and the running kernel did not match, it was understandable that appropriate kernel headers for the running kernel could not be found, assuming that according to https://superuser.com/questions/1532590/guest-additional-kernel-headers-not-... the VirtualBox code ���checks��� for such version matching. Using the commands ���rpm -q kernel-default ���last��� and ���rpm -q kernel-preempt ���last��� (reference: https://access.redhat.com/solutions/59698), with in each case two dashes before ���last���, I was gratefully able to see the history of the installed software packages with those names in my Leap-15.3 installation. The result was that as of June 6, 2021 the version 5.3.18-57.3 of kernel-default and kernel-preempt that was provided through an openSUSE Web site in the International Standards Organization (.iso) file for offline installations of Leap 15.3 is the only version of those packages which I had thus far installed in Leap 15.3. Despite the fact that I did not succeed to ���build��� new VBGA 6.1.22 with either of the Linux kernels kernel-default-5.3.18-57.3 or kernel-preempt-5.3.18-57.3, gratefully I eventually found a way to have VBGA appropriate for both the Linux kernel 5.3.18-lp152.75.1.x86_64 running and VirtualBox 6.1.22r144080 (Qt5.6.2) installed in Leap 15.3. The first factor in that success was that gratefully lots of files from that last kernel I used in Leap 15.2 were still present in Leap 15.3 after my upgrade of Leap 15.2 to Leap 15.3 and subsequently updated Leap 15.3. Secondly during my previous failed attempts to produce VBGA using the version 5.3.18-57-3 of kernel-default and kernel-preempt there was an instruction ���To build modules for other installed kernels, run VirtualBox Guest Additions: /sbin/rcvboxadd quicksetup <version>���. I had a number of difficulties ���figuring out��� exactly how those instructions should be executed. I decided to ���boot��� into Leap 15.3 using probably the Linux kernel 5.3.18-57-default. I decided that ���other ���. kernels��� likely meant kernels other than the kernel one was running at the time. A second puzzle was what exactly ���run VirtualBox Guest Additions��� could mean. I decided to click on ���Devices, Insert Guest Additions CD image������ in the window provided by VirtualBox for Leap 15.3 which at least had the directory of the form /run/media/MY_USER_NAME/VBox_GAs_6.1.22 open in a File Manager while I as a root user entered the command ���rcvboxadd quicksetup 5.3.18-lp152.75.1-default��� in the directory /sbin in the terminal computer program LXTerminal; but it is questionable whether I needed to have that directory ���./VBox_Gas_6.1.22 open in a File Manager, since the version of VirtualBox I was running at that time might have been detectable. Another challenge was exactly what syntax I should use to report the version of the Linux kernel for which I wanted to have the VBGA produced. As a root user in the directory /sbin I entered the following choices in the following order: rcvboxadd quicksetup 5.3.18-75.1 (which was incorrect) rcvboxadd quicksetup 5.3.18-lp152.75.1 Here the command ���sudo /usr/bin/modinfo vboxguest��� resulted in several lines of output; among them were filename: /lib/modules/5.3.18-57-default/extra/vboxguest.ko version: 6.1.20_SUSE r143896 description: Oracle VM VirtualBox Guest Additions for Linux Module . Those lines of output indicated that with the Linux kernel 5.3.18-57-default, which was probably the running kernel at the time, the VBGA being used were the VirtualBox 6.1.20r143896 Guest Additions. Still as a root user in the directory /sbin I entered rcvboxadd quicksetup 5.3.18-lp152.75.1-default . I think relatively soon after each such above rcvboxadd��� command I received an ordinary-looking response of .../sbin # . Although no error messages were displayed, nothing appeared to occur as a result of entering any of those commands! So it appeared that the VBGA were not being ���built��� using VirtualBox 6.1.22 as a result of entering any of those commands. So I think I thought that perhaps the new VBGA might automatically be ���built��� for me after ���booting��� into Leap 15.3 using the Linux kernel 5.3.18-lp152.75-default. Before ���rebooting��� that way I reinstalled the software packages virtualbox-guest-x11 and virtualbox-guest-tools in hopes that I could still have normal actions in Leap 15.3 if and when I would ���boot��� into Leap 15.3 using, say the Linux kernel 5.3.18-57-3-default. I clicked to ���reboot��� into Leap 15.3 to hopefully ���boot��� using the Linux kernel 5.3.18-lp152.75-default. But I did not see it listed among the four choices shown on the ���boot��� menu after clicking on ���Advanced������ on the ���boot menu.��� However, I gratefully discovered something new for me, which was that after pressing the computer-keyboard key with a pointing-downward-arrow on it to reach the fourth entry on the ���boot menu��� and then continuing to press that key that additional choices of Linux kernels gratefully appeared! Among them was kernel 5.3.18-lp152.75-default! So I pressed my computer keyboard���s ���Enter��� key when the ���boot-menu��� line containing ���5.3.18-lp152.75-default��� was highlighted. I noticed an unimportant and inconsequential initial irregularity in that a bar across the top of the window for Leap 15.3 did not fill up the whole width of the window. But later in such a ���boot��� it did fill up the width of the window. As a root user I again entered the command sudo /usr/bin/modinfo vboxguest and received several lines of response; among them were filename: /lib/modules/5.3.18-lp152.75-default/extra/vboxguest.ko version: 6.1.22_SUSE r144080 . This meant that my short-term desire had gratefully been achieved, namely that VBGA were available using VirtualBox 6.1.22 and the Linux kernel 5.3.18-lp152.75-default! And the contents of the folder shared by the Windows-10 ���host��� operating system and the Leap-15.3 ���guest��� operating system were gratefully visible in the Konqueror File Manager in Leap 15.3! And I could gratefully copy and ���paste��� text via the computer ���clipboard��� between the Windows-10 ���host��� and Leap-15.3 ���guest��� operating systems! Next was the matter of ���figuring out��� how I could have had the VBGA I wanted for VirtualBox 6.1.22 and Linux kernel 5.3.18-lp152.75.1.x86_64-default given that I did not see evidence of them being ���built��� with VirtualBox 6.1.22 and Linux kernel 5.3.18-lp152.75-default in Leap 15.3. In the Konqueror File Manager I looked at the date and time for the production of the file /lib/modules/5.3.18-lp152.75-default/extra/vboxguest.ko and found those data to respectfully be 5/13/21, which would undoubtedly mean May 13, 2021, and 7:16 a.m. Then I looked at my handwritten or printed notes of my computer activity on May 13, 2021 and discovered that in Leap 15.2 I had had the VBGA ���built��� that day using VirtualBox 6.1.22 and the Linux kernel 5.3.18-lp152.75.1.x86_64! So it appears that Leap 15.3 had ���inherited��� the VBGA from my Leap-15.2 installation! And this is one of the benefits of performing an upgrade of Leap versus performing a so-called ���clean,��� ���fresh,��� or ���begin-from-nothing��� installation of Leap! So the computer software associated with the command vboxadd quicksetup 5.3.18-lp152.75��� might have ���recognized��� that the desired VBGA already existed in /lib/modules/5.3.18-lp152.75-default/extra and therefore not directed them to be ���rebuilt,��� given the fact that the date of the file vboxguest.ko on June 7, 2021 was still May 13, 2021, which was before Leap 15.3 was released to the public on June 2, 2021! There is still another interesting datum to try to explain, namely why those ���prebuilt��� VBGA were not ���reported��� to me when I earlier tried, but failed to ���build��� the VBGA after ���booting��� into Leap 15.3 using the Linux kernel 5.3.18-lp152.75-default and VirtualBox 6.1.22. Not having studied the code associated with the command of the form ���rcvboxadd quicksetup 5.3.18-lp152.75.1-default��� I had issued in the directory /sbin as a root user, I just guess or suppose that that command was necessary to in effect set something like a ���switch��� so that afterward after ���booting��� into Leap 15.3 using the Linux kernel 5.3.18-lp152.75-default that Leap 15.3 would ���know��� to use those ���prebuilt��� VBGA for the VBGA. And, by the way, those ���prebuilt��� VBGA of VirtualBox 6.1.22 apparently overruled the VirtualBox 6.1.20 that would have been associated with the installed software packages virtualbox-guest-x11 and virtualbox-guest-tools installed in my Leap-15.3 installation. And I suppose that during the execution of the command ���./VBoxLinuxAdditions.run��� there may not have been a ���check��� to determine if the desired VBGA had already been ���built��� and were available in Leap or not and instead simply went ahead and ���tried��� to ���build��� those VBGA. So up to now here my conclusions are: 1a) The software ���bug��� is likely that the computer code in the Linux kernels 5.3.18-57.3.x86_64-default and 5.3.18-57.3.x86_64-preempt initially supplied with 64-bit openSUSE Leap 15.3 is in one or more ways likely incompatible with the computer code in VirtualBox 6.1.22r144080 (Qt5.6.2). Without having studied the computer codes this conclusion seems consistent with the kinds of errors reported near the end of some vboxadd-setup.log files. 1b) Concerning VirtualBox the computer software supplied with Leap 15.3 is based on VirtualBox 6.1.20. 1c) Concerning the ���building��� of VBGA using the executable file ./VBoxLinuxAdditions.run from VirtualBox 6.1.22, the likely incompatibility between VirtualBox 6.1.22 and the Linux kernels 5.3.18-57.3.x86_64-default and 5.3.18-57.3.x86_64-preempt could imaginably be rectified by modifying the source code for either VirtualBox or the kernels or some combination of them with the result of new versions or updates to one or more of these items of computer software. The imaginable approach to determining these incompatibilities could be for a computer code writer knowledgeable in kernel and VirtualBox computer codes to either examine the contents of the files vboxadd-setup.log and/or the working combination of the computer codes for VirtualBox 6.1.20 and the Linux kernel 5.3.18-lp152.75.1.x86_64-default that I gratefully could use in Leap 15.2. 2a. In the short tun the VBGA that I arranged to be ���built��� in Leap 15.2 are now usable for me in Leap 15.3 after having arranged for ���booting��� into Leap 15.3 using the Linux kernel 5.3.18-lp152.75.1.x86_64 and after having entered a command of the form ���rcvboxadd quicksetup 5.3.18-lp152.75.1-default��� in the directory /sbin as a root user while probably he Linux kernel 5.3.18-57.3.x86_64 was running. 2b. Alternatively I can still have the ordinary functions with windows in Leap 15.3, the file sharing between Windows and Leap 15.3, and the copying and ���pasting��� of text after ���booting��� into Leap 15.3 using the Linux kernel 5.3.18-57.3.x86_64-default with the software packages virtualbox-guest-x11 and virtualbox-guest-tools installed in Leap 15.3. 3. It appears that after entering the commands similar to ���rcvboxadd quicksetup 5.3.18-lp152.75.1-default��� and ���booting��� into Leap 15.3 with that version of the Linux kernel that in Leap 15.3 the VBGA that were previously produced in Leap 15.2 overruled the VirtualBox-6.1.20 VBGA that would have been associated with the software packages virtualbox-guest-tools and virtualbox-guest-x11 in Leap 15.3. 4. I now see a great benefit of upgrading Leap versus making a so-called ���clean��� installation of Leap due to in an upgrade ���inheriting��� useful items from the version of Leap before such an upgrade. One experiment I did not try was to see if the VBGA could be successfully produced in Leap 15.3 with VirtualBox 6.1.20���s command ���./VBoxLinuxAdditions.run��� and one of the Linux kernels 5.3.18-57-default or 5.3.18-57-preempt which came with Leap 15.3 running while kernel-devel-5.3.18-57 and kernel-source-5.3.18-57 were installed. Did such a test happen to have been made by Linux developers before Leap 15.3 was released? If not, could someone please make that test and report here his or her result of success or failure in having the VirtualBox Guest Additions produced? A Leap-15.3 operating system installed as a ���guest��� operating system or Virtual ���Machine��� in VirtualBox 6.1.20 in a 64-bit Windows 10 operating system would be the ideal combination in which such an attempt could be made; and someone or some people might already have such a computer ���environment.��� A Further Recommendation or Else Alternative Options If possible I recommend that kernel developers, the developers of the major distributors of the Linux operating system, and the developers of VirtualBox computer software work together to simultaneously release a version of the Linux kernel and a compatible version of VirtualBox. Otherwise, short of that ideal, if there are problems when ���building��� VBGA in the upgraded version of Leap, I see two other possibilities to largely avoid such incompatibilities at around the times of Leap upgrades: 1) to not have in the ���host��� operating system a version of VirtualBox installed before the version of the kernel released in and for the ���guest��� operating system has included computer software based on that version of VirtualBox. So in the present situation that would correspond to entering the command ���sudo /usr/bin/modinfo vboxguest��� in Leap to see what version of the VGBA are being used in Leap and then, if there isn���t a mtach between that version and the version of VirtualBox installed in the ���host��� operating system, to downgrade that version of VirtualBox installed in the ���host��� operating system to arrange such a match. Or 2) to do what I may have started this time, I could possibly arrange to use the last version of the Linux kernel and VirtualBox which worked well for ���building��� the VBGA in the previous version of Leap and wait for updates to the Linux kernel in the upgraded version of Leap to accommodate the latest VirtualBox code. Fortunately the problem I report is not at all a severe one. And I hope that the error messages reported in the files with names of the form vboxadd-setup.log which I include here will assist computer-code writers in both diagnosing the cause or causes of the problem I report here and fixing it. And I thank such code writers in advance for taking some time to kindly remedy this problem. -- You are receiving this mail because: You are on the CC list for the bug.