Many people on the forum have reported that their VMs have "stopped working" or "failed to boot" after applying the latest updates to Ubuntu 22.10. The latest kernel update 5.10.0-31 that the latest Ubuntu update installs has broken the console display under Fusion.
Until Ubuntu fixes this (and there is a bug report that's been sent to them about this), the workaround is to boot an older kernel. Most Ubuntu updates will leave the last 2 older kernels installed for just such an occurrence. Also do not apply any more updates to the Ubuntu VM until they fix this issue.
Here's how to boot an older kernel:
If you initially installed Ubuntu Server with its default disk partitioning, it's relatively straightforward. The boot process will display the GRUB boot loader prompt upon initial power up:
Click in the window and use the keyboard down arrow (not the mouse) to select "Advanced options for Ubuntu" and press "return". The following screen will appear:
The first entry (Ubuntu, with Linux 5.19.0-31-generic) is the default kernel that would have been booted, and is the one that is the cause of the problem. Use the keyboard down arrow to select the next kernel down - that is the kernel that was replaced by the updates that installed the broken kernel. In my case, that was 5.19.0-29-generic.
Once you highlight the kernel you wish to boot, press "Return" or "Enter" to boot that kernel. The VM should now boot and the console should display as it did before.
If you installed from an Ubuntu 22.10 daily build and took the default disk layout, the GRUB boot loader does not appear automatically and it's difficult (if not impossible) to reliably get to the boot loader prompt using the procedures that Ubuntu recommends. This default behavior can be changed to match what is seen in the Ubuntu Server- that is, the GRUB boot loader menu can be configured to appear on each boot of the VM.
If you're seeing the symptom described in this post, boot the Ubuntu VM and never mind that the screen is blank. Wait a couple of minutes for the VM to finish booting.
Next, find the IP address of the VM. That should be found by highlighting the running VM in the left hand panel of the Virtual Machine Library, and then looking toward the bottom of the right hand panel, where the IP address should be visible. It should look something like this:
Next, on the Mac open the Terminal app, and then use the ssh utility to remotely log into the VM:
ssh username@ip-address
Where username is your username in the Linux VM, and ip-address is the IP address of the VM.
You may be asked about the authenticity of the fingerprint for the VM. If asked, accept the fingerprint.
Provide the user's password, and you should be logged into the VM.
Once logged into the VM, sudo into a root shell, and edit the file /etc/default/grub.
Two changes need to be made:
First, find the line that reads
GRUB_TIMEOUT_STYLE=hidden
Change that to
GRUB_TIMEOUT_STYLE=menu
This change configures the GRUB boot menu to always display at boot.
Next, find the line that reads:
GRUB_TIMEOUT=0
Change it to
GRUB_TIMEOUT=5
This change will set the boot loader to automatically boot the first entry in the boot loader menu if no input is received for 5 seconds. Using the keyboard up/down arrows or entering any GRUB boot loader command will cancel the 5 second timer. (You can increase this timer if you so desire)
After making these two changes, save the file and exit the editor.
Now rebuild the GRUB boot configuration with the command
update-grub
Power down the VM after the GRUB update is finished:
systemctl poweroff
Now power back on the VM, wait until the screen flashes, and you should now see the GRUB boot loader menu. Follow the instructions earlier in this post for Ubuntu Server to select an older kernel that does not exhibit the issues.
Yeah, I'm going to do that because knowing Ubuntu they'll issue three more updates before fixing it, and push the working kernel off the stack 
@ColoradoMarmot wrote:Yeah, I'm going to do that because knowing Ubuntu they'll issue three more updates before fixing it, and push the working kernel off the stack
I'm taking a different approach. I just installed the latest mainline kernel 6.1.12-060112-generic using the good ol' 'mainline' utility that I used back in the early tech preview days. It works fine. Took me a few iterations to install all the dependent utilities and packages needed to build it, but once I did that the install and reboot has gone well.
That kernel won't get overwritten until I remove it.
As Mr. Spock would say: "Fascinating". The 'mainline' Linux kernels sourced from upstream and built using Ubuntu configuration files works fine, but the kernel they ship with their other modifications doesn't. Inquiring minds want to know what they did.
Thanks. I commented there and linked to banackm's post above with VMware's analysis, which does suggest an incomplete backport. Kai-Heng Feng, who commented there earlier, works for Canonical, so I think they did take note. 
