bhyve ubuntu 18.04.4 crashing in with kernel 4.15.0-96

[TM Rydland]

After updating to latest freenas my ubuntu VMs also got rebooted, and the latest kernel initiated. This kernel does boot, but very shortly it reports write errors, and become unresponsive.
After some fidling i found that if i boot with kernel 4.15.0-91 everything seems to work as it should.
I think they have some setting in the lates ubuntu kernel that makes crash. Does anybode else have this problem?

 

[gth871r]

I got this problem starting today too. I'm getting a bunch of errors that look like I have a bad disk. No IRQ handler for vector and Failed command: READ FPDMA QUEUED and other things like that. All my old VMs seem to work just fine but when I try to install a new copy of Ubuntu server, the install seems to work but then I get the disk errors at the login screen.

 

[gth871r]

Just did another test. I cloned my old VM and it still worked. As soon as I did and apt update and apt upgrade and rebooted it immediately failed. I'm guessing that this may be a Linux issue.

 

[skullitor13]

I am also having this issue with a new install on Ubuntu 18.04.4 LTS. it boots but when I go to login it freaks out after I put in the user name. it gives me a bunch of failed to write errors... My other VMs which are older work fine on the same Ubuntu Version. I think this might have something to do with the way its creating new Virtual Disks? but that is just a guess.

 

[skullitor13]

I am also having this issue with a new install on Ubuntu 18.04.4 LTS. it boots but when I go to login it freaks out after I put in the user name. it gives me a bunch of failed to write errors... My other VMs which are older work fine on the same Ubuntu Version. I think this might have something to do with the way its creating new Virtual Disks? but that is just a guess.

I take this back I restarted the VM that was working on 18.04.4 and it now is not letting me login. I changed the number of virtual CPUs. (I was going to install what I wanted to run on the new VM on the old one that was still working.)

 

[TM Rydland]

This seems to me that it is a Linux issue, My current sollution to this problem is to boot the VMs with the older version of the kernel. The one that and with 91, the one with 96 at the end is the bad one.

 

[gsrcrxsi]

if you don't need the desktop GUI, try changing the disk type to VIRTIO instead of AHCI. that helped me. but you will lose mouse function if you use anything but 1 or 3 cores

 

[Skro]

I had the same IO errors/mouse issues as OP with my Ubuntu 18.04.4 LTS VM when I updated to 11.3-U2. I tried changing from AHCI to VIRTIO and that unfortunately did not fix the issue (regardless of the number of cores).

My VM was using grub 5.3.0-46; changing it to use 5.3.0-45 fixed it for me. Since I wanted the change to survive a reboot, I set it as the default.

In case anyone needs to know how to do that, I followed the accepted answer from https://askubuntu.com/questions/216398/set-older-kernel-as-default-grub-entry, and set GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 5.3.0-45-generic"

 

[jigery]

I am also experiencing this issue on an Ubuntu Server 18.04.4 LTS VM since April 13 after an update and subsequent reboot.
I suspect it is an issue with the Ubuntu VM and not FreeNAS because I am still using FreeNAS-11.2-U6 and nothing else changed there.
Hoping to add some clarity here with what I have found....
My VM has been configured with 3 Virtual CPUs.
After reading the comments here I tried reconfiguring the VM with 2 Virtual CPUs and it worked without issue.
Having 2 Virtual CPUs seems to work OK but trying with either 3 or 4 results in errors. I haven't bothered reverting the OS kernel yet so I am just running 2 Virtual CPUs for now. I might revisit this weekend if I find some time available.

 

[jigery]

Further clarification, I am using AHCI for the VM disk and virtio on the nic.

 

[McD]

I have the same problem, which at least in my case appears to be caused by this Linux kernel commit:
https://lore.kernel.org/linux-pci/87imkr4s7n.fsf@nanos.tec.linutronix.de/

 

[Yorick]

I was able to recreate this problem on my Ubuntu 18.04.04 by changing vCPUs to 3. I was able to then resolve it by changing both disk and network to virtio. I'll see whether it remains stable this way.

 

[jigery]

Confirmed, changing both disk and network to virtio seems to work now, even with changing vCPUs to 3. Back up and running as before, at least for me. Lesson learned, always use virtio as the default choice for all devices in a virtual environment so long as it is supported by the virtualized Operating System.