Running Linux with GUI under Virtualization framework unexpectedly stuck after several minutes

My device is MacBook Pro 13-inch, M1, 2020

Use source code provided by article https://developer.apple.com/documentation/virtualization/running_gui_linux_in_a_virtual_machine_on_a_mac

When installing Debian, Fedora or Ubuntu, installation process can stuck at any point and cause the installation failed. Even if it is lucky enough to pass the installation phase, stuck could still happen at any time when the virtual machine is started.

It seems that there is some low level error that cause the Linux kernel panic, while during this process error seems to be accumulated--it starts with some user level application in Linux starts to behave weirdly, such as sudo does not authenticate a valid user, apt can not run properly, then Linux kernel panic. Sometimes it behaves like the VM get stuck where it is not sure what happened inside it.

I can't provide more detail as it happens randomly and the phenomenon differs each time. While generally it appears to be an accumulated error and eventually the VM get stuck.

Post not yet marked as solved Up vote post of mark07 Down vote post of mark07
3.9k views

Replies

Thanks for reporting this error.

One thing that comes to mind is the disk might be full on the host system. When that happens, the guest would see I/O errors for legitimate block operations. The Linux kernel handles that smoothly but user-space apps may not expect such failures.

Could you share the panic logs from the Linux kernel?

  • I'm still trying to do that as for sometimes the VM just get stuck where I can't see any message.

    I'm currently testing different configurations and my conclusion is:

    VM could get stuck with only networkDevices, storageDevices and serialPorts added, and other devices have no influence on it.It seems only affect VZEFIBootLoader, VZLinuxBootLoader seems not affected.There are plenty of space on the host, and stuck could still happen if I pre-allocate all disk space using dd.
  • I have put the screenshot on the reply.

Add a Comment

The screenshot is above

I'm having the same problems on my new MacBook Air 2022 M2 running ventura 13.1. No matter which virtualisation tool I use (UTM, tart), as long as I use Virtualization.Framework I keep getting these kernel oops Unable to handle kernel paging request at virtual address early during installation of Ubuntu. It's very consistent and usually happens after a few seconds or minutes after the installation process starts (writing data to drive). A few times, however, the VM just freezes before even starting installation, (without any kernel message). I tried with multiple versions of ubuntu 20.4, 22.04, 22.10 and 23 - all the same. I tried graphical ubuntu desktop installer and console based ubuntu server installer. However if I boot the live desktop ubuntu and surf the web or use other apps, it hasn't yet Oopsed on me yet. But once I start the installation process, it Oopses, so it seems to be related to writing data to the drive. If I choose a different file system, like ZFS or BTRFS, it happens more rarely, and I was even able to perform a couple of full installations (but sometimes also that crashed). Because this exact same thing happens not only with one Virtualization.Framework-based tool, but apparently with all of them, it leads me to believe the problem lies within the Virtualization.Framework. I've tried also removing all kernel extensions in MacOS, removing all /Library/PrivilegedHelperTools and rebooting - No difference.

I have the same symptoms on my m2 with 13.2 (22D49). Oddly enough, I also had an m1 with 13.1 and it worked fine there. I tried many different configurations of running Ubuntu as a VM (a lot of space/RAM/CPU, LVM, BTRFS, EXT4, and none of those in different combinations). It always ends in kernel panics on my M2. This is before I'm doing anything company specific. I'm just installing the OS (Ubuntu 22.10 ARM), installing Rosetta for Linux, and getting the latest updates from apt. The same steps that work on my M1 to get a reliable VM up and running, do not work on my M2 to achieve the same.

A bit out of things to try, I attempted at installing Debian Bullseye just now, just to see if that would make any difference. The answer is no:

[  558.955855] ---[ end trace a3e4cf1d0e54fe7c ]---
[  559.692513] Unable to handle kernel paging request at virtual address ffff0000fd3c3000
[  559.692535] Mem abort info:
[  559.692542]   ESR = 0x96000047
[  559.692550]   EC = 0x25: DABT (current EL), IL = 32 bits
[  559.692560]   SET = 0, FnV = 0
[  559.692567]   EA = 0, S1PTW = 0
[  559.692574] Data abort info:
[  559.692581]   ISV = 0, ISS = 0x00000047
[  559.692589]   CM = 0, WnR = 1
[  559.692597] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000046a325000
[  559.692608] [ffff0000fd3c3000] pgd=000000046fff8003, p4d=000000046fff8003, ***=000000046fa92003, pmd=000000046f8a8003, pte=0000000000000008
[  559.692628] Internal error: Oops: 96000047 [#2] SMP
[  559.692638] Modules linked in: joydev hid_generic usbhid hid apple_mfi_fastcharge binfmt_misc aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul libaes nls_ascii sha3_ce nls_cp437 sha3_generic sha512_ce vfat fat sha512_arm64 virtio_gpu sha2_ce virtio_dma_buf drm_kms_helper virtio_console virtio_balloon sha256_arm64 evdev sha1_ce efi_pstore virtiofs drm fuse configfs efivarfs virtio_rng rng_core ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic virtio_net net_failover failover virtio_blk xhci_pci xhci_hcd usbcore usb_common crct10dif_ce crct10dif_common virtio_pci virtio_ring virtio
[  559.692719] CPU: 4 PID: 12267 Comm: dpkg Tainted: G      D W         5.10.0-21-arm64 #1 Debian 5.10.162-1
[  559.692732] Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 1916.80.2.0.0 12/19/2022
[  559.692748] pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)
[  559.692764] pc : clear_page+0x14/0x48
[  559.692774] lr : kernel_init_free_pages+0x6c/0x9c
[  559.693346] sp : ffff800012743710
[  559.693791] x29: ffff800012743710 x28: ffff00042df07800
[  559.694232] x27: ffff00042df07800 x26: ffff00042df07800
[  559.694674] x25: 0000000000000000 x24: ffff80001188ad00
[  559.695114] x23: 0000000000000001 x22: ffff000000000000
[  559.695576] x21: 0000000003f4f100 x20: ffff0000c6ad6ac0
[  559.695999] x19: 0000000003f4f0c0 x18: 0000000000000000
[  559.696416] x17: 0000000000000000 x16: 0000000000000000
[  559.696833] x15: 0000aaaafb5d5430 x14: 0893670003000000
[  559.697283] x13: 0000000418000000 x12: 0000000000000040
[  559.697694] x11: ffff00042b54a6c8 x10: ffff800012743d40
[  559.698094] x9 : ffff80001039acb4 x8 : ffff800008dd9df0
[  559.698520] x7 : ffff0000c6ad6ac0 x6 : 0000000000000004
[  559.698922] x5 : 000000000000fffd x4 : 0000000000000001
[  559.699297] x3 : 0000000000000981 x2 : 0000000000000004
[  559.699653] x1 : 0000000000000040 x0 : ffff0000fd3c3000
[  559.699994] Call trace:
[  559.700325]  clear_page+0x14/0x48
[  559.700643]  prep_new_page+0x64/0xe0
[  559.700947]  get_page_from_freelist+0x163c/0x1a60
[  559.701252]  __alloc_pages_nodemask+0x174/0xeac
[  559.701552]  alloc_pages_current+0x90/0x150
[  559.701851]  pagecache_get_page+0x21c/0x380
[  559.702149]  grab_cache_page_write_begin+0x30/0x50
[  559.702455]  ext4_da_write_begin+0x130/0x430 [ext4]
[  559.702767]  generic_perform_write+0xb4/0x1d0
[  559.703082]  ext4_buffered_write_iter+0xa4/0x184 [ext4]
[  559.703400]  ext4_file_write_iter+0x64/0x6c0 [ext4]
[  559.703718]  new_sync_write+0xf0/0x18c
[  559.704038]  vfs_write+0x228/0x2bc
[  559.704358]  ksys_write+0x70/0x100
[  559.704680]  __arm64_sys_write+0x24/0x30
[  559.705008]  el0_svc_common.constprop.0+0x80/0x1d0
[  559.705337]  do_el0_svc+0x2c/0x94
[  559.705674]  el0_svc+0x20/0x30
[  559.705998]  el0_sync_handler+0xb0/0xb4
[  559.706377]  el0_sync+0x180/0x1c0
[  559.706735] Code: 37200121 12000c21 d2800082 9ac12041 (d50b7420)
[  559.707124] ---[ end trace a3e4cf1d0e54fe7d ]---

This is on:

$ uname -a
Linux vbox.transloadit.com 5.10.0-21-arm64 #1 SMP Debian 5.10.162-1 (2023-01-21) aarch64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 11 (bullseye)
Release:	11
Codename:	bullseye

Did Apple test this functionality before shipping? It seems like a very basic use case when it comes to running VMs (Installing a Linux ARM VM on top of Apple Virtualization on Apple Sillicon, doing nothing particular yet outside of enabling Rosetta and installing updates), yet me and all of my collueges on M2 are having these issues, while for my collegue on an M1, it is running fine, just like on my previous M1, with identical setup steps.

Post not yet marked as solved Up vote reply of kvzz Down vote reply of kvzz

I upgraded the VM Guest's Debian to Linux kernel 6.0.12-1~bpo11+1 (coming from 5.10.158-2), and since then I have not had problems (too early to celeberate but this is aprox ~20hrs, where before this, there would be a kernel panic roughly every 5 minutes), instructions used inside the VM were:

# Update Debian apt sources list to include backports (and contrib, non-free)
sudo apt install lsb-release
releaseName=$(lsb_release -cs)
echo "deb http://deb.debian.org/debian/ ${releaseName} main contrib non-free
deb http://deb.debian.org/debian/ ${releaseName}-updates main contrib non-free
deb http://deb.debian.org/debian ${releaseName}-backports main contrib non-free
deb http://security.debian.org/debian-security ${releaseName}-security main contrib non-free" | sudo tee /etc/apt/sources.list

sudo apt update

## Install kernel from backports
sudo apt install linux-image-6.0.0-0.deb11.6-arm64
reboot

Worth noting is that my collegue reported similar issues again on a yet even newer kernel, 6.1.7-1.

Post not yet marked as solved Up vote reply of kvzz Down vote reply of kvzz

I encountered the same problem and after a lot of attempts found that distros with Linux kernel 5.15 work fine. For example, one of them is Ubuntu 22.04. It needs more testing, but from first glance it's already working much better, installing and first hours of using showed excellent results with or without GUI. Lower and higher versions of kernel always freeze and sometimes are not even installing.

  • It appeared that after some hours of work crashes are still present. I think it's better to stick with QEMU for now.

Add a Comment

can still conform this bug.

Macmini m2 chip, Ventura 13.5.2.

have tried linux guest os debian 11/12, ubuntu 22.04

mark & look forward the fix notification.