Unable to launch a VM after fresh install with latest technology preview on M1

[Neil_Young]

Since the update to the latest tech preview a couple of days ago I can open my older VMs only in recovery mode. Trying to install a 20.04.3 as a new VM works, but the thing is stuck at first boot as all the old ones are and recovery doesn't work anymore

The screen is attached.

What am I doing wrong?

[ColoradoMarmot · Accepted solution]

There's another thread where it looks like a ubuntu kernel update broke compatibility.  I've rolled back my VM and disabled auto-updates.

[Neil_Young]

Yeah, I suspected this too. Because I was able to recover from older kernels.

But now with a brand new VM. I tried to stop the installation after it shows "installing security updates" to no avail and I found no way to hinder the 20.04 installer to not update at the first installation. Seems, that this update brings the new kernel, since my copy of 20.04 is an older one. Do I have to unplug the network ? 🙂

PS: Do you have the link to the thread?

PS: Do

[ColoradoMarmot]

found it: https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/Building-Ubuntu-VM-challenges/td-p/2...

[ColoradoMarmot]

Forgot to add - I'm about done fighting ubuntu.  Between their constant buggy updates, lack of historical build downloads, and general hostility to stability, I'm going to look for a different distribution to switch to.

[Neil_Young]

Well up to now I didn't have any major issues. But AFAIK there is no 18.04 running on a M1

[Neil_Young]

I was already reporting my results, but it didn't appear here.

Again: I finally was able to install it in a new VM by unplugging the network. Next apt update/upgrade brings the new bad kernel again and the mess restarts

[Technogeezer]

Yeah those new updated kernels are forcing me to hold off on any future updates to VMs that I have working now. Ive also got backups and snapshots of those VMs on the off chance one of these updates gets installed without my having a chance to stop it. 

[Neil_Young]

At least I'm back on track for today. I will try again tomorrow with this kind of hack:

- Install new VM w/o network

- Enter the VM after first installation

- Enable network

- sudo dpkg-reconfigure unattended-upgrades (select NO)

- sudo apt-mark hold linux-image-generic linux-headers-generic (in the hope it will not update the kernel again)

- sudo apt update && sudo apt upgrade

Will report

[Neil_Young]

OK, to finally provide a working solution, this is a stable pattern to overcome the kernel incompatibilities introduced somewhere between 5.4.0-81 and 5.4.0-105 (wondering how one can blow everything with a patch update...)

- Disable your network and fire up a new VM

- Install a new VM from an older 20.04 version (I was using an iso image from December 21, this has kernel 5.4.0-81)

- Once this is done enter the VM and issue these commands in order to prevent unattended updates and especially any changes in the kernel version:

sudo dpkg-reconfigure unattended-upgrades

(choose NO)   -- or--

sudo apt remove unattended-upgrades

sudo apt-mark hold linux-image-generic linux-headers-generic

- Enable your network again

You can now issue "sudo apt update && sudo apt upgrade" w/o being concerned that the kernel will be updated. You can also reboot and restart your VM and it will NOT hang as it does with kernel 5.0.4-105 (for example)

HTH

[wackybacky]

you previously helped me with an alpine linux install and this is broken with the update too... the only way i can get a new machine going now is to copy a previous VM and repurpose it. and i can't run any updates against it as it breaks.

exactly what were vmware thinking of when they sent this out? and how exactly is it an improvement?

[Neil_Young]

I'm sure it wasn't me who helped you. But I'm not sure if VMWare is to blame here. This problem can also be seen with e.g. Parallels. It probably just an incompatibility which bites at VM level

[wackybacky]

you're right, it was 'technogeezer' and i thought i was replying to his comment on this post, somehow it ended up at the bottom.

but just to highlight i'm using alpine linux and i can't install verified working versions as they refuse to boot now. that isn't down to recent kernel changes in distro's it must be down to changes in fusion.

you say it's happening in parallels? common boot rom changes?? do they use the same sources for this kind of stuff?

[Neil_Young]

OK, that doesn't match my observation with Parallels and Fusion and it doesn't also explain, why a 5.0.4-81 kernel boots perfectly with the latest Fusion following my little "gist" above.

If you don't have a chance to bring up a menu with old recovery versions then I suppose the VMs are not useable anymore

[Technogeezer]

@wackybacky this appears to be something the Linux kernel maintainers are doing as the issue cropped up with VMware, Parallels and QEMU. (The latter two I read about when doing some research, but have not experienced personally). The commonality among these 3 virtualization solutions appears to be the Linux changes being introduced and backported to older Linux releases to address a security vulnerability. The minute the change hits  distros (and because it’s a security issue it will hit sooner rather than later), all of these VM solutions will see the problem.

QEMU may have added code to address this. We’re still waiting on what VMware will do. 

[wackybacky]

ah, thank you for the info. i suppose i have to wait with baited breath for a patch then. and not too long i would have thought, as it scuppers everybody. 🙂

[rhaleblianbeta]

Posted about one Ubuntu release that I could get working:
https://communities.vmware.com/t5/Fusion-for-Apple-Silicon-Tech/Ubuntu-hanging-on-boot-up-Try-Ubuntu...

... albeit by avoiding newer kernels in the boot loader.

Oh, and I hope the ISO under that link hasn't been updated...

[sitkak]

Thankyou! I am able to boot my VM now!

Just so people can find this thread I am pasting the text of the boot message (yay apple preview can OCR any image)

8 Ubuntu 64-bit Arm Server 20.04.3
Loading Linux 5.4.0-105-generic
Loading initial ramdisk

EFI stub: Booting Linux Kernel.
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DIB from configuration table
EFI stub: Exiting boot services and installing virtual address map.

If one goes to "Advanced Options" from the grub boot menu and selects an older kernel, they should be able to boot their VM. The newest kernel I am able to boot from is:

Ubuntu, with Linux 5.4.0-100-generic

[Neil_Young]

> If one goes to "Advanced Options" from the grub boot menu and selects an older kernel, they should be able to boot their VM. The newest kernel I am able to boot from is:

Confirmed. But doesn't help if you install a new VM 🙂

Anyway, the problem is identified and there is a work around.

[Technogeezer]

---

@Neil_Young wrote:

Confirmed. But doesn't help if you install a new VM 🙂

---

Unfortunately you're right. If you need a new VM you have to find an installer of ANY distribution built before this month, and don't let it update the kernel.

I'm still concerned that we've heard crickets from VMware on this. Even an acknowledgment that they know of the issue and are looking into it would be helpful.