http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c1 --- Comment #1 from Lawrence Somerville <l_pat_s@hotmail.com> --- Created attachment 850057 --> http://bugzilla.opensuse.org/attachment.cgi?id=850057&action=edit A report of errors during an attempt to have VirtualBox Guest Additions "built" Today I have a total of three files to attach to this "bug" report: vboxadd-setup.log.1, vboxadd-setup.log.2, and vboxadd-setup.log.4. I hope I can find some way to get all three of these files attached to this "bug" report. So far it appears that I am only attaching one file at a time to this "bug" report. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c3 --- Comment #3 from Lawrence Somerville <l_pat_s@hotmail.com> --- Okay, gratefully it appears that I succeeded in getting the files vboxadd-setup.log.1, vboxadd-setup.log.2, and vboxadd-setup.4 all included in this "bug" report. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c6 --- Comment #6 from Lawrence Somerville <l_pat_s@hotmail.com> --- Thank you, Larry Finger, for kindly taking some time to within only hours after my Bugzilla posting here to promptly reply to it. Concerning your phrase ���openSUSE has backported a number of kernel API changes into their kernels,��� I don���t know the details or maybe even understand much of the operational part of that phrase. The term ���backport��� was a term I did not understand. From https://www.webopedia.com/definitions/backport/ on the Internet I could see that at least one definition of backporting is the process of applying a computer-software patch to an older version of software than the software for which the patch was originally intended. But the trouble with this definition here is that, according to you, backporting has been applied to one or more Linux kernels in Leap 15.3, which was only released 11 days ago, so could hardly be considered old software. I assume that the abbreviation API you used would stand for Application Programming Interface. I assume that openSUSE would begin with a version of the Linux kernel from https://kernel.org/ and afterward adapt that kernel version in some ways to an openSUSE ���environment.��� So would you please provide some teaching for me here? That is please provide a definition of backporting which would apply to the changes made in the versions of the Linux kernel which openSUSE would provide. In detail please explain with some real examples appropriate for openSUSE Leap what is considered new and what is considered old software in such ���backporting.��� Please explain why it is even necessary to make any changes to the version of the Linux kernel which https://kernel.org/ would provide to make such a modified kernel version work in an openSUSE software ���environment.��� I have learned that a so-called driver file is needed to provide ���communication��� between an operating system and an item of computer hardware in order to make that piece of hardware function in that operating system. But modifying a Linux kernel so that it will be workable in an openSUSE operating system seems to be more basic than a driver to make a piece of computer hardware work in an operating system in the sense of modifying one piece of computer software to make it work with another piece of computer software. I assume that OBS would stand for openSUSE Build Service with the lower-case ���o��� in openSUSE modified as a capital letter ���O��� in the abbreviation OBS. I guess that at least some of the source computer code in the openSUSE software package entitled kernel-source might be written in the C computer language. And I further guess that the API changes that would be in versions of the Linux kernel supplied by openSUSE would be included in kernel-source. Please provide some examples of such necessary API changes in openSUSE Leap. You may correct any of my mistaken assumptions or guesses here. You might have to consult some openSUSE computer-code writers to obtain answers to some of my questions and/or to correct some of the thinking I express here; and, if so, that process might result in the good outcome of each of us learning some new things and/or to understand some basic things concerning openSUSE computer software. And you might even be successful in having one of the computer-code writers provide some relevant teaching here. I can imagine that a main purpose of a Bugzilla posting could be for an openSUSE user to report problems with openSUSE computer software so that openSUSE computer-code writers can become aware of those problems and hopefully fix them and then afterward for someone, maybe one of the actual computer-code writers, to hopefully eventually report here that the reported computer-software problem will have been fixed. But let���s here have something even beyond those good purposes! That is let���s have some teaching and learning take place here as well! If we would be in the same room having a conversation, I could now say, ���What will you say to that?��� But since we instead are online and communicating in writing I instead write, ���What will you write in response to my proposal that a Bugzilla posting also include some specific teaching and learning relating to, for example, why a computer-software problem exists, how the computer software has been designed to work, how various parts of the computer software are designed to work together, what has to occur to make the computer code work successfully, what the precise software problem was, the process and software diagnostic computer code or codes someone used to specifically locate an error in computer software, what process he used to fix an item of computer software, with these last two processes included in the so-called ���debugging��� process; et cetera?��� I think you have at least begun to write in a general way along some of these lines. But to have more specific information with examples of specifically named items of computer software provided in pedagogical way such that I could understand some details would hopefully be more satisfying for me, even though information provided in that way might raise further questions in my mind. But I think that asking questions and obtaining answers to them is a good way to learn and gain understanding. And besides that, that process could be fun. Do you agree with me? Actually either an openSUSE online ���forum��� or a Bugzilla posting could in principle be a ���vehicle��� by which such teaching and learning could take place. I further think that having begun a discussion in either place, it could be natural to continue it there, except in an openSUSE online ���forum��� posting when it becomes clear that a software problem needs to be reported in a Bugzilla posting so that it can be fixed. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c8 --- Comment #8 from Lawrence Somerville <l_pat_s@hotmail.com> --- From the Internet I learned that SUSE stands for Gesellschaft f��r Software-und SystemEntwicklung (Software and System Development in the English language) and that SLE in turns stands for SUSE Linux Enterprise. I gather from your writing that versions of the Linux kernel which have been in time behind the latest versions of the Linux kernel released by https://kernel.org/ on the Internet were being used in SLE. Therefore it makes sense that the decision to in openSUSE use Linux kernels in use in SLE would also mean that the kernels in use in openSUSE would have also been in time behind the version of the Linux kernel that was most recently released by and/or through https://kernel.org/. I gather that the numbering system for Linux kernels is such that a Linux kernel numbered 5.13 is newer than a Linux kernel numbered 5.3 with the number 13 being larger than 3 indicating a later version of the Linux kernel when those version numbers increase with time. This feature differs from the fact that the number 5.13 is smaller than the number 5.3. Someone might mistakenly think that, for example, version 5.10 came first, then version 5.13, then version 5.20, then version 5.22; and then version 5.30 or 5.3 came into existence. A numbering system for versions of computer software, including for Linux kernels, which might help to avoid this kind of mistaken idea, could be to instead write the kernel versions as 5:3 and 5:13 using number-separating colons instead of number-separating periods. Eventually I think I ���grasped��� the idea of the ���bind��� that you mentioned.--That is it appears to me that the users of SLE who had maintenance contracts with SLE to help them solve software problems for the fees they paid for such service in their maintenance contracts also wanted their SLE computer software to be able to work with the modern-computer hardware of their computers. Perhaps there are no software maintenance contracts for openSUSE users, since openSUSE is a free operating system; but there are only such software maintenance contracts for SLE and SUSE users?? Assuming so, the openSUSE users would not share with SUSE and SLE users an interest in keeping software-maintenance contracts, but would share the interest with SLE and SUSE users of desiring the Linux kernels to work well with their modern-computer hardware. So then comes the need to add the capabilities of modern-computer hardware support, which are contained in the new versions of the Linux kernel, to the older versions of the Linux kernel in SLE, SUSE, and openSUSE Linux operating systems, which is called backporting. And I suppose the mechanics of such backporting would include adding to and/or modifying the source code in the older software package entitled kernel-source or else kernel-devel to include support for the modern-computer hardware and then compiling kernel-source or kernel-devel to make the software packages kernel-default and kernel-preempt; and perhaps the software packages ���kernel-devel��� (assuming kernel-source is needed), ���gcc��� (GNU���s Not Unix [GNU] Compiler Collection), and ���make��� might also be needed in such a compilation. So I thank you, Larry Finger, for explaining this need to backport features from new Linux kernels, I suppose originally issued through https://kernel.org/, into older Linux kernels in use openSUSE quite well for me! I think you have done a good job teaching me something here!! Since I am, in effect, your student; and you are, in effect, my teacher, you are welcome to correct any mistaken ideas I have here in my understanding. Does your backporting of computer code from modern Linux kernels into older Linux kernels in use in openSUSE include you writing computer source code, as well as compiling source code? Since late July of the year 2020 I was gratefully usually successful in having VirtualBox Guest Additions ���built��� for either a new version of the Linux kernel or a new version of VirtualBox by executing the file VBoxLinuxAdditions.run obtained from the latest released version of VirtualBox. And note that within probably usually just some days after a new version of VirtualBox was released, this process was usually still successful. So if the code to accommodate that new version of VirtualBox had not yet been incorporated in the latest Linux kernel version released by openSUSE, it usually did not matter!--That is such ���building��� of VirtualBox Guest Additions was usually still successful! This usual success encompassed the Linux kernel versions 5.3.18-lp152.26-default through 5.3.18-lp152.75.1.x86_64-default released through an openSUSE repository and VirtualBox versions 6.1.12 through 6.1.22 (If there was any failure in such ���building,��� without checking all of my records, I suppose it would have been minor and/or temporary.). But I could not do that successfully immediately after an update of an upgrade of Leap from version 15.2 to version 15.3 of it using Leap 15.3���s Linux kernels 5.3.18-57.3-default or 5.3.18-57.3-preempt and VirtualBox 6.1.22���s VBoxLinuxAdditions.run. And, as I discussed in the Bugzilla posting on https://bugzilla.opensuse.org/show_bug.cgi?id=1174048, I had even greater trouble in Leap 15.2 after updating my upgrade of Leap from version 15.1 to 15.2 of it in July of the year 2020. Based on your writing I assume that computer code backported into the Linux kernel used in openSUSE Leap would have been needed every time I had new VirtualBox Guest Additions produced by executing VirtualBox���s file VBoxLinuxAdditions.run following the installation of either a new version of the Linux kernel released via openSUSE Leap���s repositories or a new version of VirtualBox released by Oracle Corporation. And note that the beginning of the kernel designation 5.3.18 has been the same in Leap 15.2 and 15.3. Yet in this respect I suppose that there must have been something unusual associated with updating Leap after upgrading from at least version 15.2 to version 15.3 which prevented the success of the command ./VBoxLinuxAdditions.run with VirtualBox 6.1.22 installed. Assuming so, specifically what was it? In support of this suspicion of mine is the fact that I could have VirtualBox Guest Additions ���built��� successfully using VirtualBox 6.1.22���s VBoxLinuxAdditions.run in an up-to-date, Leap-15.2 installation, but not with that same VirtualBox-6.1.22 version in an up-to-date, Leap-15.3 installation using either one of the Linux kernels supplied with it. One obvious difference is the Linux kernel version in use: 5.3.18-lp152.75.1.x86_64 late in my use of Leap 15.2 and 5.3.18-57.3-default or 5.3.18-57.3-preempt in Leap 15.3 after my upgrade and shortly afterward update of Leap, yet before my Linux kernel update to version 5.3.18-59.5.2.x86_64, default and preempt, on June 16, 2021. But my experience in Leap 15.2 was that beginning on July 23, 2020 I at least generally had multiple successes executing the command VBoxLinuxAdditions.run after having Linux kernel updates installed. Was a kernel change in an upgrade or a rapid update of an upgrade of Leap different from a kernel update without an upgrade of Leap? Regarding updating Leap 15.3 after upgrading Leap 15.2 to Leap 15.3 it seems likely, especially considering your following writing and when I suspect that there may well be some specific things in the following general writing of yours which I do not know: ���openSUSE has backported a number of kernel API��� (Applications Programming Interface) ���changes into their kernels. That is the reason your builds are failing.��� It is interesting that after updating an upgrade of Leap that in the two instances of Leap 15.2 to Leap 15.3 and Leap 15.1 to 15.2 I had at least some partial successes using a version of the Linux kernel used in the version of Leap before the Leap upgrade that I did not have in the updated Leap installation a relatively short time after that upgrade of Leap. Therefore, considering what you wrote, it seems that one or more of the API changes made in the Linux kernel installed after updating or during an upgrade of Leap may have been faulty, or in the case of the function of VirtualBox 6.1.22 in Leap 15.3, at least deficient with respect to a successful execution of VirtualBox 6.1.22���s file VBoxLinuxAdditions.run. After I learned the large number of changes made to a Linux kernel from my next paragraph here, I supposed that you likely would not know all of the specific API changes made to the Linux kernels released with Leap 15.3 and their purposes. In that case you could comment on whether the number of API changes made to a Linux kernel released in a Leap upgrade is greater or not than the number of API changes made in a version of the Linux kernel released between two, released upgrades of Leap. Even better might be if you could comment on whether the number of API changes made to a version of the Linux kernel released in a Leap upgrade that would affect the operation of Leap in VirtualBox would be greater or not than in a Linux kernel released between two Leap upgrades. I had a look at the ���change log��� for kernel-preempt, version 5.3.18-59.5.2.x86_64. That list of changes to that version of the Linux kernel and/or the descriptions of those changes was quite lengthy; and I did not closely read all of the changes posted there. And astonishingly at the end of that description of changes 13,759 more changes were reported to have been made for that release of the Linux kernel which were not listed in that lengthy description of changes! After the Linux kernel versions 5.3.18-59.5.2.x86_64, preempt and default, were installed, I made another test execution of the VirtualBox 6.1.22 file VBoxLinuxAdditions.run and unfortunately again had a failed result. From that test I am going to attempt to attach to this report the three output files from that test named vboxadd-install.log, vboxadd-setup.log.A, and vboxadd-setup.log.B, after having appended ���.A��� or ���.B��� to two of those file names. Somehow (perhaps either from uninstalling and reinstalling virtualbox-guest-x11 and virtualbox-guest-tools or from the recent update of the Linux kernel) I lost the file sharing capability between my Windows ���host��� and Leap-15.3 ���guest��� operating systems using the Linux kernel-preempt-5.3.18-59.5.2.x86_64 in a folder Windows and Leap 15.3 share via VirtualBox; but I could gratefully have it again when booting into Leap 15.3 using the Linux kernel-preempt-5.3.18-lp152.75.1, which was probably ���inherited��� from my Leap-15.2 before upgrading it to Leap 15.3. How may I learn if and when a Linux kernel version for Leap 15.3 has been released which can work well with VirtualBox 6.1.22 when its file VBoxLinuxAdditions.run is executed? At the end of the ���change log��� for the Linux kernel-preempt version 5.3.18-59.5.2.x86_64 I read that the command ���rpm -q ���changelog kernel-preempt-5.3.18-59.5.2��� would result in output of the complete ���change log��� for that version of the Linux kernel. That would likely be too lengthy for most people to want to read. But perhaps an alternate command could be found on the Internet to write the output of a similar command into a text file such that afterward a search for ���VirtualBox��� or ���6.1.22��� could be performed in that so-produced text file to make such searching easier than otherwise. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c10 --- Comment #10 from Lawrence Somerville <l_pat_s@hotmail.com> --- Created attachment 850394 --> http://bugzilla.opensuse.org/attachment.cgi?id=850394&action=edit 2nd of 3 files produced as a result of testing VBoxLinuxAdditions.run with Linux kernel preempt-5.3.18-59.5.2 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c12 Larry Finger <Larry.Finger@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Larry Finger <Larry.Finger@gmail.com> --- The usual interpretation of a kernel version such as X.Y is not as a decimal number, but as major version X, and minor version Y. Thus 5.13 is 10 releases after 5.3. Each such release takes a minimum of 9 weeks, thus 5.3 is pretty old as things go in the software business. If you insist on using the .run files from Oracle on your systems, then you will need to get Oracle to make the changes that support Leap 15.3, or you will need to fix the code yourself. If you choose the latter, then file fixes_for_leap15.3.patch at site https://build.opensuse.org/package/show/openSUSE%3AFactory/virtualbox will show you what you need to do. On the other hand, you can install the VirtualBox packages from the Leap 15.3 repos. Almost all users follow this route as they have the necessary patches to allow them to build. That is my main duty as the maintainer of the software. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1187011 http://bugzilla.opensuse.org/show_bug.cgi?id=1187011#c14 --- Comment #14 from Lawrence Somerville <l_pat_s@hotmail.com> --- I discovered that on https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/fix... all references to VirtualBox were to version 6.1.20 of it. However, I had grateful success executing VBoxLinuxAdditions.run to have VirtualBox Guest Additions ���built��� for a Leap-15.2 ���guest��� operating system in VirtualBox 6.1.22r144080 (amd64), which I likely installed on April 29, 2021, using at least the Linux kernel version 5.3.18-lp152.72.1.x86_64 on April 30, 2021 and, with no indication of any problem in my notes in such ���building,��� using the Linux kernel version 5.3.18-lp152.75.1.x86_64 on May 13, 2021! During the interim of time from the release of Leap 15.2 on probably July 2, 2020 up to the release of Leap 15.3 on June 2, 2021 the following VirtualBox versions were released by Oracle Corporation (reference: https://www.virtualbox.org/wiki/Download_Old_Builds_6_1 on the Internet): 6.1.12 (released on July 14, 2020), 6.1.14 (released on September 4, 2020), 6.1.16 (released on October 16, 2020), 6.1.18 (released on January 19, 2021), 6.1.20 (released on April 20, 2021), and 6.1.22 (released on April 29, 2021). And on July 2, 2020, the probable date of Leap 15.2���s release, VirtualBox 6.1.10 was already publicly available, as of June 5, 2020. Yet there is no mention on https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/fix... of any changes within openSUSE Leap-15.2, VirtualBox-related computer software to accommodate versions 6.1.12-6.1.18 of VirtualBox! I note that the time interval between the releases of VirtualBox 6.1.20 and VirtualBox 6.1.22, was unusually short, only nine days (references: https://www.virtualbox.org/ and https://www.virtualbox.org/wiki/Download_Old_Builds_6_1 on July 10, 2021). So otherwise lacking explanations for these data, I here use reason to make some guesses, which might be incorrect, to TRY to explain these and other data. My guesses: 1. Perhaps versions 6.1.20 and 6.1.22 of VirtualBox could work with the same Linux kernel versions released by openSUSE Leap 15.2 regarding the execution of VBoxLinuxAdditions.run from VirtualBox. Assuming so, after the backporting of computer code to make VirtualBox 6.1.20 work in this regard with the latest Linux kernel released through a Leap-15.2 repository had been kindly completed by you, Larry Finger, perhaps no additional backporting of computer code was necessary to make VirtualBox 6.1.22 work in this regard in Leap 15.2. 2. Perhaps on https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/fix... only necessary changes made which would include making the execution of VBoxLinuxAdditions.run from VirtualBox work for the latest version of VirtualBox were displayed on https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/fix.... So how well did I do, Larry Finger, in my above guesses? Now, Larry, you might have wondered why I would be interested to know from you to which versions of the VirtualBox and the Linux kernel your backporting of Linux-kernel code would apply without me testing this matter by executing VBoxLinuxAdditions.run from a version of VirtualBox. If so, here is one answer to this question.---On August 1, 2015 on https://forums.opensuse.org/showthread.php/508902-Issues-installing-guest-ad... poster tsu2 was quoted as probably previously writing or saying, ���If you think you might be happy with just re-sizing the display, check whether that still works or not. If not, then your attempts to build your own Guest Additions may have broken it and may need to be replaced anyway.��� And unfortunately this might have already occurred in my Leap-15.3 computer software. In addition, somehow I lost the capabilities 1) to see folders in my Windows-10 ���host��� operating system in my openSUSE ���guest��� operating system using a folder set up within VirtualBox to be shared between my Windows-10 ���host��� and openSUSE ���guest��� operating systems and 2) to copy and ���paste��� text between those two operating systems via the computer ���clipboard.��� The logically simplest, yet most time-consuming option I can imagine to solve all three of these problems is for me to return to a state of my Leap-15.3 ���guest��� operating system in which none of those three problems existed by a) restoring my Leap-15.2 computer software from a backup of the data on my computer���s hard-disk drive, b) upgrading from Leap 15.2 to Leap 15.3, c) at least partially updating Leap 15.3 computer software. Then, assuming I will then have a well-working Leap-15.3 installation, I should have another backup of the data on my hard-disk drive written. At that point in time I would have a way to recover my Leap-15.3 installation if I would cause any problems for myself by, for example, failing a test of the execution of VBoxLinuxAdditions.run from Oracle Corporation���s VirtualBox 6.1.22 or a later version of its VirtualBox. But, of course, it would be better if I would instead of making such a test with ahead of time an unknown result know from you, Larry, whether your backporting work will have been completed successfully or not for a given version of VirtualBox and version of the Linux kernel released from an openSUSE, Leap, online repository. Now, Larry, you might recall or else be interested to know why I prefer to have VirtualBox Guest Additions ���built��� by executing Oracle Corporation���s VirtualBox file VBoxLinuxAdditions.run instead of relying on VirtualBox Guest Additions from an online, openSUSE repository. It is actually a preference you can find on https://en.opensuse.org/VirtualBox, which reads, ���By default openSUSE installs the Virtualbox guest additions automatically when it's installed as a Virtualbox guest. However, as of openSUSE 11.4 the packaged Guest Additions version is slightly old, and may not allow use of Shared Folders with a Windows XP host for example.��� ���To install the latest version from terminal follow these steps:������ Assuming that it might take openSUSE software developers some time to produce and release VirtualBox Guest Additions from openSUSE online repositories which would be compatible with a version of VirtualBox just released by Oracle Corporation, instead whenever I have gratefully been successful in having VirtualBox Guest Additions ���built��� using Oracle Corporation���s own VirtualBox computer software this has in part been relying on Oracle Corporation���s computer software to be compatible with itself. And in Leap 15.2 this procedure gratefully at least eventually worked well for me for a number of versions of the Linux kernel supplied through an online, openSUSE, Leap repository and for a number of versions VirtualBox supplied by Oracle Corporation. Thank you, Larry, for your past work of backporting computer code which has made the execution of files with the name VBoxLinuxAdditions.run from Oracle Corporation���s VirtualBox work for me in a number of versions of VirtualBox and Linux kernels supplied through an openSUSE Leap repository! -- You are receiving this mail because: You are on the CC list for the bug.