Support Booting native (Asahi) Linux Installations on Apple Silicon

[Rastafabisch]

The title is pretty self explanatory. It would be very useful if it were possible to boot residing native Linux installations from within macOS, just like we used to have support for booting BOOTCAMP installs on Intel Macs.

I already tried to archive this, using the cli raw disk creator, but this did not work.

[Rastafabisch]

Since the VMware Fusion 13.01 Update raw drives should work again (as does BOOTCAMP support on Intel Macs), creating the raw disk works fine now. On a default Apple Silicon system with a default Asahi Linux installation the appropriate Linux related partition numbers are 4 (EFI, including Grub) and 5 (Linux home, ext4 partition) on the internal NVMe SSD (disk0). 

vmware-rawdiskCreator create /dev/disk0 4,5 ~/Asahi nvme

Editing the .vmx file of a default Linux Kernel 5 virtual machine to refer to the just created (and moved into the vm) vmdk files (Asahi.vmdk & Asahi-pt.vmdk) works and the resulting vm tried to boot but gets stuck searching for a bootable network instance.

nvme0.present = "TRUE"
nvme0:0.fileName = "Asahi.vmdk"
nvme0:0.present = "TRUE"

Spoiler

Does not work using other interfaces either. Tested with SATA, IDE & SCSI. (Reflecting those changes on the previous cli command, too.)

Checking the EFI environment (pressing F10 on vm boot) reveals that the vm cannot actually see the assigned partitions.

Spoiler

Only network boot paths available in the boot from file menu.

Thus I suspect Fusion needs to be updated to support this BOOTCAMP support alike functionality on Apple Silicon.

[ColoradoMarmot]

Bootcamp isn't supported on M1 macs, so there's nothing for Fusion to support.

[Technogeezer]

The real problem is that Apple Silicon does not use a "standard" UEFI boot loader, it uses Apple specific Low Level Bootloader (LLB) firmware.

Fusion implements UEFI firmware (as required by the ARM SystemReady specifications) for its virtual machines, not Apple's LLB firmware. That's probably why Asahi won't recognize any devices since it's expecting Apple's LLB firmware.

It's not going to be easy to boot anything Apple Silicon native until Fusion can provide an LLB firmware implementation. Or implements Apple's high level virtualization framework which I don't see happening any time soon because it's too far away from their ESXi roots.

[Rastafabisch]

I think you are missing the fact that Asahi Linux is already working on Apple Silicon natively and nicely. Including graphics acceleration. So there no issue on that side. Booting is handled via a custom boot loader which runs on apple silicon and chain loads uboot to provide a UEFI environment. From there on it's just grub booting a custom linux kernel. So it is kinda like BOOTCAMP, but for Linux rather than Windows. As it is basically just a linux on a current kernel it thus should be possible to boot it as a virtual machine, if VMWare Fusion was up to the task, which it apparently isn't according to my testing.

[ColoradoMarmot]

It is unsupported by Apple.  As such Fusion will not support it.

[Technogeezer]

You are correct that Fusion isn't up to the task currently. The lack of an Apple Silicon LLB boot loader in a Fusion VM is a big hurdle in my mind, as that's what Asahi expects the initial boot to come from. Perhaps you can hack the Asahi boot process to stop the chain boot to uboot and go directly to grub - using the UEFI environment already provided by Fusion. 

That leads to other questions in my mind.

I question whether running Asahi in a Fusion VM would have any benefits over a natively booted Asahi operating system other than convenience. It certainly would have no benefit over the numerous arm64 Linux distros that already run in a VM. Consider that an Asahi Linux VM would not have direct access to the hardware features of the M1/M2 SOCs - it would be dealing with a virtualized vmwgfx display adapter, an e1000e or vmxnet3 virtual network adapter, and virtualized hard drives (even though it would be direct access to a hard disk partition rather than a VMware formatted VMDK). 

[ColoradoMarmot]

Great summary of the hardware limitations (which are pretty severe), and all on a niche distribution without much real software support.  It's much more a science project than anything else, and only one apple OS update from rendering the whole machine unbootable.

Until Microsoft licenses Windows on Mac, and Apple builds bootcamp for it, Fusion isn't going to pay any attention to it.  Even then, I'd seriously doubt that Apple enables bootcamp for Asahi (if they do it for anything, it'll be a mainstream distro).

[Rastafabisch]

I totally get where the sepsis is coming from. However I feel like you misjudge the situation. Thought that might be true or me as well.

1. Asahi is less of a bistro, but more of an upstreaming project, thus enabling any up to date linux distro to support Apple silicon hardware. As a matter of fact freeBSD already supports Apple Silicon due to this and Fedora developers are on their way, too.
2. Running alternative kernels and thus OS is a supported scenario by Apple. They even developed an environment to set this up (kmutil) and even introduced further updates to ease the development by deliberately enabling non mach kernels to be booted natively. 
3. The Asahi Linux project provides the boot loader (combination - m1n1 + uBoot). to enable UEFI booting (including external media). While this is needed for any distro with current upstream kernel (which already is enough to boot on Apple Silicon) it is not unlike BOOTCAMP back when Windows used to require BIOS mode to boot (As in having a custom Boot environment.) However kernels could be booted without this and it is only to facilitate the process. The difference still is, of course, that BOOTCAMP was (is) a first party implementation, while m1n1+uBoot is only an apple-sanctioned implementation.
4. Like @Technogeezer said: It's mostly for convenience. But how does that differ to booting BOOTCAMP as a vm?
5. The low level boot process is totally irrelevant as in the end the kernel is booted by a stock Grub aa64 environment. - Just as stock linux vm use them. 

I do very well understand how this makes it different from supporting BOOTCAMP in the past, however being officially unsupported @ColoradoMarmot does not seem to be a valid argument, as Windows VMs are officially unsupported by Microsoft either, and Fusion still supports Windows nonetheless.

Also we are not talking about some niche distro, but Linux in general. Asahi is just the project enabling any Linux to be Apple Silicon compatible.

So the issue currently boils down to: Why do raw vmdks to not work on apple silicon. They sure seem to be a supported scenario in general, aren't they?

[ColoradoMarmot]

Remember that Fusion is a commercial product.   I seriously doubt there are incremental sales at sufficient level to justify building support in fusion for a project that Apple doesn't support.

Windows is a different story, because there absolutely is commercial demand for it - in fact, I'd argue that without Windows support, Fusion would likely go EOL.  

Put it another way - absolutely fair to make the request.  Just understand that it'll be queued and prioritized based on revenue potential....and the Fusion team is clearly struggling to deliver things that have much higher business value.

[Rastafabisch]

Thank you very much @ColoradoMarmot. That is a reasonable explanation. I still hope VMWare will address the issue as it basically seems to be broken functionality, that raw vmdk do not work on apple silicon even though they work on Intel Macs (since 13.0.1). If the Fusion team considers to implement support via the GUI it would be even better of course, but I'm fine dealing with the CLI as long as it works. Let's hope for the best.