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

Thread: VM not working after upgrade, suggests I sign kernels

  1. #11

    Default Re: VM not working after upgrade, suggests I sign kernels

    Here is what those commands turn up:

    "locate virtualbox" produces a huge output which is too big to display. But somehow none of the files that it displays mention the version number.

    Code:
     linux-vqod:~ # locate Virtualbox 
    /home/Documents/Random/Back Ups/Virtualbox Install.odt 
    /home/Documents/Random/Back Ups/Virtualbox Install.pdfp { margin-bottom: 0.1in; line-height: 115%; background: transparent none repeat scroll 0% 0%; }
    Code:
     zypper si make gcc kernel-devel kernel-default-devel 
    Reading installed packages... 
    Loading repository data... 
    Package 'kernel-devel' has source package 'kernel-source'. 
    Package 'kernel-default-devel' has source package 'kernel-default'. 
    Resolving package dependencies... 
    
    The following NEW package is going to be installed:
     hmaccalc 
    
    The following 4 source packages are going to be installed:
     gcc kernel-default-4.12.14-lp150.12.67.1 kernel-source-4.12.14-lp150.12.67.1 make 
    
    1 new package to install, 4 source packages. 
    Overall download size: 123.3 MiB. Already cached: 0 B. After the operation, additional 245.1 MiB will be used. 
    Continue? [y/n/...? shows all options] (y): y 
    Retrieving srcpackage gcc-7-lp150.2.3.1.noarch                                                                                                 (1/5) 
    Retrieving: gcc-7-lp150.2.3.1.src.rpm ........................................................................................................[done] 
    Retrieving package hmaccalc-0.9.14-lp150.2.3.1.x86_64                                                          (2/5),  23.7 KiB ( 96.1 KiB unpacked) 
    Retrieving: hmaccalc-0.9.14-lp150.2.3.1.x86_64.rpm ...............................................................................[done (6.6 KiB/s)] 
    Retrieving srcpackage kernel-source-4.12.14-lp150.12.67.1.noarch                                                                               (3/5) 
    Retrieving: kernel-source-4.12.14-lp150.12.67.1.src.rpm ..........................................................................[done (3.7 MiB/s)] 
    Retrieving srcpackage make-4.2.1-lp150.6.3.1.noarch                                                                                            (4/5) 
    Retrieving: make-4.2.1-lp150.6.3.1.src.rpm .......................................................................................[done (1.7 MiB/s)] 
    Retrieving srcpackage kernel-default-4.12.14-lp150.12.67.1.noarch                                                                              (5/5) 
    Retrieving: kernel-default-4.12.14-lp150.12.67.1.nosrc.rpm .......................................................................[done (4.1 MiB/s)] 
    Checking for file conflicts: .................................................................................................................[done] 
    (1/5) Installing: gcc-7-lp150.2.3.1.src ......................................................................................................[done] 
    (2/5) Installing: hmaccalc-0.9.14-lp150.2.3.1.x86_64 .........................................................................................[done] 
    (3/5) Installing: kernel-source-4.12.14-lp150.12.67.1.src ....................................................................................[done] 
    (4/5) Installing: make-4.2.1-lp150.6.3.1.src .................................................................................................[done] 
    (5/5) Installing: kernel-default-4.12.14-lp150.12.67.1.src ...................................................................................[done] 
    Just as a reminder, the problem with my VM not working actually started before I upgraded to the new version. I assumed it was because the current one was out dated (because it had prompted me to update at the same time), but that would be unusual. We may be searching in the wrong place.

    Also, yes, my system may have both Oracle and the other versions of VM. Because recently I had a different problem and people in this forum helped me fix it by installing the VM software through the command prompts. But normally I always go through YAST, which is what I did this time.

    I hope that helps.

  2. #12
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,927
    Blog Entries
    2

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by rgietzen View Post
    Here is what those commands turn up:

    "locate virtualbox" produces a huge output which is too big to display. But somehow none of the files that it displays mention the version number.

    Code:
     linux-vqod:~ # locate Virtualbox 
    /home/Documents/Random/Back Ups/Virtualbox Install.odt 
    /home/Documents/Random/Back Ups/Virtualbox Install.pdfp { margin-bottom: 0.1in; line-height: 115%; background: transparent none repeat scroll 0% 0%; }
    Code:
     zypper si make gcc kernel-devel kernel-default-devel 
    Reading installed packages... 
    Loading repository data... 
    Package 'kernel-devel' has source package 'kernel-source'. 
    Package 'kernel-default-devel' has source package 'kernel-default'. 
    Resolving package dependencies... 
    
    The following NEW package is going to be installed:
     hmaccalc 
    
    The following 4 source packages are going to be installed:
     gcc kernel-default-4.12.14-lp150.12.67.1 kernel-source-4.12.14-lp150.12.67.1 make 
    
    1 new package to install, 4 source packages. 
    Overall download size: 123.3 MiB. Already cached: 0 B. After the operation, additional 245.1 MiB will be used. 
    Continue? [y/n/...? shows all options] (y): y 
    Retrieving srcpackage gcc-7-lp150.2.3.1.noarch                                                                                                 (1/5) 
    Retrieving: gcc-7-lp150.2.3.1.src.rpm ........................................................................................................[done] 
    Retrieving package hmaccalc-0.9.14-lp150.2.3.1.x86_64                                                          (2/5),  23.7 KiB ( 96.1 KiB unpacked) 
    Retrieving: hmaccalc-0.9.14-lp150.2.3.1.x86_64.rpm ...............................................................................[done (6.6 KiB/s)] 
    Retrieving srcpackage kernel-source-4.12.14-lp150.12.67.1.noarch                                                                               (3/5) 
    Retrieving: kernel-source-4.12.14-lp150.12.67.1.src.rpm ..........................................................................[done (3.7 MiB/s)] 
    Retrieving srcpackage make-4.2.1-lp150.6.3.1.noarch                                                                                            (4/5) 
    Retrieving: make-4.2.1-lp150.6.3.1.src.rpm .......................................................................................[done (1.7 MiB/s)] 
    Retrieving srcpackage kernel-default-4.12.14-lp150.12.67.1.noarch                                                                              (5/5) 
    Retrieving: kernel-default-4.12.14-lp150.12.67.1.nosrc.rpm .......................................................................[done (4.1 MiB/s)] 
    Checking for file conflicts: .................................................................................................................[done] 
    (1/5) Installing: gcc-7-lp150.2.3.1.src ......................................................................................................[done] 
    (2/5) Installing: hmaccalc-0.9.14-lp150.2.3.1.x86_64 .........................................................................................[done] 
    (3/5) Installing: kernel-source-4.12.14-lp150.12.67.1.src ....................................................................................[done] 
    (4/5) Installing: make-4.2.1-lp150.6.3.1.src .................................................................................................[done] 
    (5/5) Installing: kernel-default-4.12.14-lp150.12.67.1.src ...................................................................................[done] 
    Just as a reminder, the problem with my VM not working actually started before I upgraded to the new version. I assumed it was because the current one was out dated (because it had prompted me to update at the same time), but that would be unusual. We may be searching in the wrong place.

    Also, yes, my system may have both Oracle and the other versions of VM. Because recently I had a different problem and people in this forum helped me fix it by installing the VM software through the command prompts. But normally I always go through YAST, which is what I did this time.

    I hope that helps.
    Based on what you posted, you have a Frankenstein combination of Oracle Virtualbox and openSUSE Virtualbox on your system.
    Before removing and purging your Virtualbox packages and files, you need to decide what you want when you re-install...

    You need to decide whether you want to install Oracle Virtualbox which will compile kernel modules on your system or openSUSE Virtualbox, which is compile by Maintainers in the Cloud and then the results are simply copied to your system. There not too much difference otherwise, of course compiling on your system involves some complexity which you would need to troubleshoot if you have any problems.

    Since I don't think your Guests have been upgraded to 6.0, you also need to decide whether you want to return to 5.2 or upgrade to 6.0, 5.x is solid and reliable and supported and 6.0 is very, very new with some possible risk associated with anything brand new. Basic features haven't changed much between the two but if you're chasing an extra bit of performance or an optional feature that might work better, then 6.0 should be considered.

    Both 5.2 and 6.0 are available both as Oracled Virtualbox downloads and openSUSE packages for 15.0, unlike 15.1 and TW which only have 6.0 now.

    As for the purging and re-installation,
    They're pretty straight forward...
    1. Do the "locate" searches I described to understand what files will need to be removed.
    2. If you have any HostOS custom configurations (not Guests), you should copy those to an alternate location, otherwise a re-install after thorough purging will return you to install defaults.
    3. Do a package uninstall, typically this simply involves substituting "rm" for any zypper "si" commands. This only removes packages <safely> but purging is more thorough.
    4. After package uninstallation, update your "locate" database by running "updatedb" and run your commands again to get an updated list of Virtualbox files that still exist on your system.
    5. Remove the files listed by "locate" in step 4 using "rm" command or use a file manager (if you can see the files). Remember, using a file manager can simply move your files into a trash so might not be removed permanently. There's a good and a bad side to this, on one hand if you make a mistake of some sort you can undo easily but on the other hand you may need to take extra steps to remove permanently.
    6. Remove the Oracle Virtualbox repository. This can be done in YaST Repository Management or the following where repo_id can be anything unique about the repo... the repository number, the repo name, etc
    Code:
    zypper rr
    7. Re-run Step 4 updating the locate database and searching for files on your system.
    8. When your system has been completely purged of Virtualbox files, you can now re-install Virtualbox, exactly what you do will depend on your pre-purge decisions what version of Virtualbox you want and from Oracle or from openSUSE.

    If you have specific questions or issues,
    Post again.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  3. #13

    Default Re: VM not working after upgrade, suggests I sign kernels

    Thanks for the patience and detailed answer. But, I feel like I better describe exactly what I planning to do first.

    Based on what you said, I would prefer to downgrade back to the 5.2 VM version. I just want something stable and have not done any custom configurations. I would prefer to use the version that I download through YAST, is that the Opensuse version?

    Assuming those choices, would you still recommend the same sequence of steps? Also using the locate file command, I don't recall many of the files declaring themselves as 5.2 vs 6.0, or Oracle vs. Opensuse. I'm not confident that I know how to identify which files to remove. Can you clarify that better for me?

    Thanks again.

  4. #14

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by tsu2 View Post
    Based on what you posted, you have a Frankenstein combination of Oracle Virtualbox and openSUSE Virtualbox on your system.
    Before removing and purging your Virtualbox packages and files, you need to decide what you want when you re-install...

    You need to decide whether you want to install Oracle Virtualbox which will compile kernel modules on your system or openSUSE Virtualbox, which is compile by Maintainers in the Cloud and then the results are simply copied to your system. There not too much difference otherwise, of course compiling on your system involves some complexity which you would need to troubleshoot if you have any problems.

    Since I don't think your Guests have been upgraded to 6.0, you also need to decide whether you want to return to 5.2 or upgrade to 6.0, 5.x is solid and reliable and supported and 6.0 is very, very new with some possible risk associated with anything brand new. Basic features haven't changed much between the two but if you're chasing an extra bit of performance or an optional feature that might work better, then 6.0 should be considered.

    Both 5.2 and 6.0 are available both as Oracled Virtualbox downloads and openSUSE packages for 15.0, unlike 15.1 and TW which only have 6.0 now.

    As for the purging and re-installation,
    They're pretty straight forward...
    1. Do the "locate" searches I described to understand what files will need to be removed.
    2. If you have any HostOS custom configurations (not Guests), you should copy those to an alternate location, otherwise a re-install after thorough purging will return you to install defaults.
    3. Do a package uninstall, typically this simply involves substituting "rm" for any zypper "si" commands. This only removes packages <safely> but purging is more thorough.
    4. After package uninstallation, update your "locate" database by running "updatedb" and run your commands again to get an updated list of Virtualbox files that still exist on your system.
    5. Remove the files listed by "locate" in step 4 using "rm" command or use a file manager (if you can see the files). Remember, using a file manager can simply move your files into a trash so might not be removed permanently. There's a good and a bad side to this, on one hand if you make a mistake of some sort you can undo easily but on the other hand you may need to take extra steps to remove permanently.
    6. Remove the Oracle Virtualbox repository. This can be done in YaST Repository Management or the following where repo_id can be anything unique about the repo... the repository number, the repo name, etc
    Code:
    zypper rr
    7. Re-run Step 4 updating the locate database and searching for files on your system.
    8. When your system has been completely purged of Virtualbox files, you can now re-install Virtualbox, exactly what you do will depend on your pre-purge decisions what version of Virtualbox you want and from Oracle or from openSUSE.

    If you have specific questions or issues,
    Post again.

    TSU
    I can easily deinstall the 6.0 version in YAST and then install the 5.2. But I'm not sure how to identify the wrong files do delete them.

    Any advice?

  5. #15
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,927
    Blog Entries
    2

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by rgietzen View Post
    I can easily deinstall the 6.0 version in YAST and then install the 5.2. But I'm not sure how to identify the wrong files do delete them.

    Any advice?
    I outlined what you need to do to "purge" anything from a system...

    1. Use your package manager (zypper or YaST) to remove as many packages as possible. This will remove most files safely but will leave a number of configuration files and perhaps some components.
    2. Use the "locate" utility (my recommendation) or something similar like Find to identify remaining files not removed by the package manager.
    3. Remove the identified files.
    4. Usually a good idea to reboot before re-installing.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  6. #16

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by tsu2 View Post
    I outlined what you need to do to "purge" anything from a system...

    1. Use your package manager (zypper or YaST) to remove as many packages as possible. This will remove most files safely but will leave a number of configuration files and perhaps some components.
    2. Use the "locate" utility (my recommendation) or something similar like Find to identify remaining files not removed by the package manager.
    3. Remove the identified files.
    4. Usually a good idea to reboot before re-installing.

    TSU
    Thanks again. Maybe you didn't see my other post in this thread. I tried to follow those steps for purging, but when I use the locate utility and look at the files, it isn't clear to me which ones I need to purge. Almost none of them have the version number in the title (5.2 vs 6.0). So that leaves me baffled about how to know which ones. Can you give me some more guidance there?

    Should I use different keywords other than virtualbox and Virtualbox?

  7. #17
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    10,927
    Blog Entries
    2

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by rgietzen View Post
    Thanks again. Maybe you didn't see my other post in this thread. I tried to follow those steps for purging, but when I use the locate utility and look at the files, it isn't clear to me which ones I need to purge. Almost none of them have the version number in the title (5.2 vs 6.0). So that leaves me baffled about how to know which ones. Can you give me some more guidance there?

    Should I use different keywords other than virtualbox and Virtualbox?
    Typically Virtualbox fifes will be within a directory with "Virtualbox" in the name.
    Typically configuration files will either be within the application directory or a directory under /etc/
    Library files will generally be within a lib or lib64 directory.
    You can be more certain the file(s) are related to Virtualbox if the full "virtualbox" name is in the file or directory name, if the file has only "virtual" in the name, then look a bit deeper or post the file and ask about it.

    If you successfully uninstalled Virtualbox packages, you shouldn't be seeing a large number of Virtualbox related files remaining... Maybe at most a dozen or so.

    If you make a mistake and damage your operating system (unlikely but mistakes can happen), you should be able to repair using your openSUSE DVD (followed by an update). But, the better option is to just post a file list of anything you're not certain and ask.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  8. #18

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by tsu2 View Post
    Typically Virtualbox fifes will be within a directory with "Virtualbox" in the name.
    Typically configuration files will either be within the application directory or a directory under /etc/
    Library files will generally be within a lib or lib64 directory.
    You can be more certain the file(s) are related to Virtualbox if the full "virtualbox" name is in the file or directory name, if the file has only "virtual" in the name, then look a bit deeper or post the file and ask about it.

    If you successfully uninstalled Virtualbox packages, you shouldn't be seeing a large number of Virtualbox related files remaining... Maybe at most a dozen or so.

    If you make a mistake and damage your operating system (unlikely but mistakes can happen), you should be able to repair using your openSUSE DVD (followed by an update). But, the better option is to just post a file list of anything you're not certain and ask.

    TSU
    Problem solved! It was so simple it leaves me baffled as to what the original problem was. Here is what I did in case others get in the same predicament:

    In YaST I deleted the 6.0 Version and installed the 5.2 version all at the same time. Then I updated the extension pack by downloading the matching version from here: https://download.virtualbox.org/virtualbox/

    It opened perfectly. Then I updated the guest additions from inside the Windows 10 machine. Now all is back and operating smoothly.

    I wonder if the reason my old version wasn't working is because it was a mix of 5.2.32 and 5.2.18. I am guessing that because the guest additions before I updated them were 5.2.18, while the host VM was 5.2.32.

    I also noticed that I usually install the VM from the YaST, (the OpenSUSE version) but use the Oracle ext pack and guest additions. That has always seemed to work fine, but maybe that is a bad practice?

    Anyways, thanks for the coaching. Got this up and running just in time, as I have some accounting I need to do for my business before the end of the month. Phew.

  9. #19
    Join Date
    Nov 2011
    Location
    Seville, Spain
    Posts
    4

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by rgietzen View Post
    5.2 VM wouldn't run today and before it gave me and error, I received a message suggesting I update to 6.0.

    So I went into YAST deleted the 5.2 version and installed the 6.0. I then installed the matching extension pack. When I went to start it, I got the usual reminder to run /sbin/vboxconfig.

    Unfortunately it won't start still. Here is the result of that command:

    Code:
    /sbin/vboxconfig
    Created symlink /etc/systemd/system/multi-user.target.wants/vboxdrv.service → /usr/lib/systemd/system/vboxdrv.service.
    Created symlink /etc/systemd/system/multi-user.target.wants/vboxballoonctrl-service.service → /usr/lib/systemd/system/vboxballoonctrl-service.service.
    Created symlink /etc/systemd/system/multi-user.target.wants/vboxautostart-service.service → /usr/lib/systemd/system/vboxautostart-service.service.
    Created symlink /etc/systemd/system/multi-user.target.wants/vboxweb-service.service → /usr/lib/systemd/system/vboxweb-service.service.
    vboxdrv.sh: Stopping VirtualBox services.
    vboxdrv.sh: Starting VirtualBox services.
    vboxdrv.sh: You must sign these kernel modules before using VirtualBox:
      vboxdrv vboxnetflt vboxnetadp vboxpci
    See the documenatation for your Linux distribution..
    I tried searching this forum about how to sign those kernel modules and cannot find a solution posted.

    Can anyone help with this?
    I run into the same problem and after digging in the initialization scripts I found the cause. In fact I found a couple of mistakes. When running /sbin/vboxconfig will try to start the service instead of configuring. The other thing is that it recognizes secure boot in SUSE, but handles it only for Debian. I modified the file /usr/lib/virtualbox/vboxdrv.sh so that it runs 'setuo' when appropriate and also to ignore the 'SecBoot enabled' in SUSE as modules are not signed. This should be allowed or restricted by the allow_unsupported_modules in /etc/nodprobe.d

    This is the patch:

    *** vboxdrv.sh Mon Jul 29 15:49:27 2019
    --- vboxdrv.sh.orig Mon Jul 29 16:14:47 2019
    ***************
    *** 94,100 ****
    *"SecureBoot enabled"*) HAVE_SEC_BOOT=true;;
    *) unset HAVE_SEC_BOOT;;
    esac
    ! # So far we can only sign modules on Ubuntu and on Debian 10 and later.
    DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der
    DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv
    unset HAVE_DEB_KEY
    --- 94,105 ----
    *"SecureBoot enabled"*) HAVE_SEC_BOOT=true;;
    *) unset HAVE_SEC_BOOT;;
    esac
    ! # In SUSE and OpenSUSE HAVE_SEC_BOOT would not allow loading the modules even
    ! # if 'allow_unsupported_modules' is set to 1. So we unset it.
    ! if egrep -q '^NAME="(openSUSE Leap|SLES)"' /etc/os-release 2>/dev/null; then
    ! unset HAVE_SEC_BOOT
    ! fi
    !
    DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der
    DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv
    unset HAVE_DEB_KEY
    ***************
    *** 568,574 ****
    ## than the fall-back. Unnecessary duplication?
    stop && cleanup
    setup_usb "$GROUP" "$DEVICE_MODE" "$INSTALL_DIR"
    ! start
    ;;
    cleanup)
    stop && cleanup
    --- 573,579 ----
    ## than the fall-back. Unnecessary duplication?
    stop && cleanup
    setup_usb "$GROUP" "$DEVICE_MODE" "$INSTALL_DIR"
    ! setup
    ;;
    cleanup)
    stop && cleanup
    I understand that patching a file from a package is not the best solution, but it is the only way I managed to make it work.

  10. #20

    Default Re: VM not working after upgrade, suggests I sign kernels

    Quote Originally Posted by juando View Post
    I run into the same problem and after digging in the initialization scripts I found the cause. In fact I found a couple of mistakes. When running /sbin/vboxconfig will try to start the service instead of configuring. The other thing is that it recognizes secure boot in SUSE, but handles it only for Debian. I modified the file /usr/lib/virtualbox/vboxdrv.sh so that it runs 'setuo' when appropriate and also to ignore the 'SecBoot enabled' in SUSE as modules are not signed. This should be allowed or restricted by the allow_unsupported_modules in /etc/nodprobe.d

    This is the patch:



    I understand that patching a file from a package is not the best solution, but it is the only way I managed to make it work.
    Interesting. Thanks for sharing.

    I noticed that it was having a problem with the secure boot. That makes sense.

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
  •