virtualbox.org

Hi all, perhaps someone would know bit more on this one. Happens both on VB on Linux and Mac. Guest is Centos 7 installed from minimal iso, and afters kernel updated to 4.7.0. Installation and update of kernel works fine, including reboots etc...up to a point where I install additions (5.2.1) and reboot. After that kernel panics on every single boot.

What happens if you do a cold boot instead of a warm boot?

In any event post the guests log file ( as an attachment ). Right click on the guest in the Main Manager then click show log. Save and post as an attachment. Compress if it is too large to post.

Thanks for the prompt reply.

What happens if you do a cold boot instead of a warm boot?

Same thing, kernel panic.

Guest log attached to the reply.

For what it's worth, I initially discovered this when creating vagrant box for my kubernetes deployment, you should be able to reproduce it by running: Above is same box, Centos 7 with 4.7.0 kernel and linux additions installed inside - fails to boot with kernel panic, although it was created with earlier version of virtual box, 5.0.1 I think.
Since then I have ditched vagrant and used VirtualBox directly to create the box and see what happens, and as a result it led me to conclusion that kernel panic happens after installation of guest addition.

OK this is going to take a bit to diagnose but I need to know exactly what the guest is and how the kernel was updated. Be specific so I can see if I can replicate this.

As you know the guest additions will not give you much in a console guest. Just basically the shared folder and time sync, which is why I don't usually install GAs in a console guest, which may be I have missed this issue.

Note: it was a good idea to eliminate the vagrant part as this would have been a show stopper to get help here.
Note2: I don't do a lot with Mac so lets use Linux if you don't mind.

I have two means of creating the box:

1. Automated with packer (in case you are familiar with packer): my github account name is dekstroza and repo name is kubernetes-dev-stack see the packer configuration (won't let me paste address here)
2. Manually with VirtualBox (the usual, create new VM, attach install cdrom with iso) etc..

I will describe second option in details since I have included logs for that one.

1.Box is installed Centos 7, installed using centos-minimal iso (won't let me post address to it on centos site).
2.Once the installation is completed, log into the guest, and do yum -y update and reboot after,
then after reboot as root yum localinstall -y elrepo-release-7.0-2.el7.elrepo.noarch.rpm from kernel-ml (again, it won't let me paste the address).
3. yum remove kernel-devel kernel-headers kernel-tools-libs
4. yum --enablerepo=elrepo-kernel install kernel-ml kernel-ml-devel kernel-ml-headers kernel-ml-tools-libs gcc bzip2 make dkms perl
5. At this point rpm -qa | grep kernel should show only running kernel (verson 3.xx) and everything else 4.7.0
6. Reboot into kernel 4.7.0
7. yum remove kernel (remove the only trace of 3.x.x kernel which came with original Centos 7) - this is optional, makes no difference, since at this point you are running 4.7.0 kernel and all kernel sources are 4.7.0

8. On virtual box select Insert Guest Additions CD Image
9. On guest as root: mkdir /mnt/cdrom AND mount /dev/cdrom /mnt/cdrom
10. cd /mnt/cdrom AND ./VBoxLinuxAdditions.run --nox11
11. It should install fine and lsmod | grep vb should show two modules, also dmesg will show few lines when they are loaded
12. As root shutdown -r now (or use VirtualBox to shutdown/reboot) any combination will trigger kernel panic on restart

Let me know if I can provide any more details, or you need any more help.

Edit: I have missed the part about linux - that's fine with me, as I can reproduce it both on Mac and Linux VirtualBox, and I am as well more familiar with good old Linux then Mac. Above steps are same for both though. Bit annoying it won't let me post urls to the exact iso and rest I have used for it.

No worries. I was able to mirror your guest and steps to reproduce the issue although I have not put a finger on the exact cause. It looks like there is something with the kernel that is keeping this from working at least in this build. I tested on a few other console guest ( debian based at this point ) up to kernel 4.5* and it works as it should. Now I need to test a little with rpm based some more but I have a gut feeling it has to do with the kernel and existing build packages on the guest not dealing with this properly.

Have you asked the elrepo folks about this yet? It might help.

Have you asked the elrepo folks about this yet? It might help.

Didn't ask yet, that was on my todo for tomorrow.

If I remember well, earlier versions of my box were running 4.4.5 and 4.5.x at some stage and those have worked fine, it is only the latest 4.7.0 version that is acting up. Had similar issues with guest tools for Parallels on Mac, since I am building boxes both for VirtualBox and Parallels, with 4.7.0 kernel, had to patch source of Parallels guest additions, and it worked fine afters - it seems there has been some work done inside kernel that was backward incompatible, among others mutex_lock/mutex_unlock has been replaced with inode_lock/inode_unlock, however these seem to be fine in VirtualBox additions as they compile and load fine.

If I get some time I might try to compile 4.7.0 kernel inside guest instead of using elrepo and kernel-ml rpm's, to see if it makes any difference.

I will update here if I get something useful from elrepo guys.

Messed around with this some more and on a Fedora 25 ( easier rpm base for me to test ) I got a complaint about not being able to handle ( null ) after installing the GAs followed with a panic. I have not had time to research it through but I suspect the guest additions are not compatible with 4.7 kernel yet and 4.8 which is what F25 was using. I also noticed that one had to apply special patches to get 4.7 working in Debian based systems. You could post a ticket at bugtracker with appropriate information and see what the DEVs have to say.

Perryg wrote:Messed around with this some more and on a Fedora 25 ( easier rpm base for me to test ) I got a complaint about not being able to handle ( null ) after installing the GAs followed with a panic. I have not had time to research it through but I suspect the guest additions are not compatible with 4.7 kernel yet and 4.8 which is what F25 was using. I also noticed that one had to apply special patches to get 4.7 working in Debian based systems. You could post a ticket at bugtracker with appropriate information and see what the DEVs have to say.

Thanks for the help, 4.8 is for sure not supported, 4.7 should be, I think I have seen that somewhere in Changelog or Readme of 5.1.2 VirtualBox.
Ticket opened #15769
Will see how it goes with VB devs. Thanks again.

Dejan

After bit more messing around with this, I have nailed down the cause of kernel panic, and can reproduce it now even without restart. Kernel panic is caused by vboxvideo module, after installing guest addition:
Will cause kernel to panic straight away.
Same happens with test builds of VirtualBox and additions (5.1.3).
I wonder if it would be possible to exclude this one somehow, so it doesn't get loaded, perhaps blacklist it?

I did research this some more and found the 4.7 kernel "fix" was for a host issue. Not sure that it was tested with the GAs at all. I also saw your ticket and two others that are posted with regards to the GAs and they are still not resolved. Use bugtracker search and "4.7 kernel" as the search criteria.

Got a workaround for it:

1. Install guest additions as usual
2. dracut -o "vboxvideo" -f /boot/initramfs-$(uname -r).img $(uname -r)
3. echo "blacklist vboxvideo" >> /etc/modprobe.d/blacklist-vboxvideo.conf

Reboot works fine, and other two modules are loaded fine. Deffo problem with vboxvideo.ko

Edit: This works for me fine as I don't need anything else then ability to mount host dir to the guest.

I am getting the same problem.
Blacklisting vboxvideo helps avoid the kernel panic, but then VBoxService would hang on startup.
Seems to be a problem with the vboxguest driver, as VBoxService works on a 4.6.6 kernel.

Just to add, this is failing on openSUSE TumbleWeed once it's updated to 4.7 (and interesting, it will still fail if you go back to try and use a previous kernel of 4.6.x).

I also just updated my Antergos VBox install, and it went from 4.6.x to 4.7.x, and it also failed to boot fully. However, unlike openSUSE TW, it didn't kernel panic (or at least not on screen), and you could still switch to a VT and log in. Graphical boot didn't work though.

Hi,

As you can see in the ticket: https://www.virtualbox.org/ticket/15769 - it has already been addressed, in case you don't want to wait, apply the changes from the ticket and it will work as expected (4.7.0 works just fine with it):
Regards,
Dejan