Rastafabisch's Posts

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. 

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. 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. 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.  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. Like @Technogeezer said: It's mostly for convenience. But how does that differ to booting BOOTCAMP as a vm? 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?  

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.

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"   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. 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.