Kali on Mac M1

[theakshat1]

I Installed kali Linux ARM64 on utm and it booted in first go but when I closed utm and reopen my Virtual Kali it is showing me to install

Configuration
UTM Version: Latest
OS Version: Mac OS 11.4
Apple Silicon

Debug log

FRunning: -L /Applications/UTM.app/Contents/Resources/qemu -S -qmp tcp:127.0.0.1:4000,server,nowait -vga none -spice port=4001,addr=127.0.0.1,disable-ticketing,image-compression=off,playback-compression=off,streaming-video=off -device virtio-ramfb -cpu cortex-a72 -smp cpus=8,sockets=1,cores=8,threads=1 -machine virt,highmem=off -accel hvf -accel tcg,tb-size=768 -bios /Applications/UTM.app/Contents/Resources/qemu/edk2-aarch64-code.fd -boot menu=on -m 3072 -device intel-hda -device hda-duplex -name "Kali Linux" -device qemu-xhci,id=usb-bus -device usb-tablet,bus=usb-bus.0 -device usb-mouse,bus=usb-bus.0 -device usb-kbd,bus=usb-bus.0 -device ich9-usb-ehci1,id=usb-controller-0 -device ich9-usb-uhci1,masterbus=usb-controller-0.0,firstport=0,multifunction=on -device ich9-usb-uhci2,masterbus=usb-controller-0.0,firstport=2,multifunction=on -device ich9-usb-uhci3,masterbus=usb-controller-0.0,firstport=4,multifunction=on -chardev spicevmc,name=usbredir,id=usbredirchardev0 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0 -device virtio-blk-pci,drive=drive0,bootindex=0 -drive "if=none,media=disk,id=drive0,file=/Users/akshat/Library/Containers/com.utmapp.UTM/Data/Documents/Kali Linux.utm/Images/disk-0.qcow2,cache=writethrough" -device usb-storage,drive=drive1,removable=true,bootindex=1 -drive if=none,media=cdrom,id=drive1 -device virtio-net-pci,mac=FE:50:17:00:C4:C0,netdev=net0 -netdev user,id=net0 -device virtio-serial -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,id=vdagent,debug=0,name=vdagent -uuid 659534A9-DABE-4590-9F14-EAC148A20EBA -rtc base=localtime
qemu-aarch64-softmmu: -spice port=4001,addr=127.0.0.1,disable-ticketing,image-compression=off,playback-compression=off,streaming-video=off: warning: short-form boolean option 'disable-ticketing' deprecated
Please use disable-ticketing=on instead

[conath]

This is a duplicate of #2503. However I have created a workaround that has been verified to work with Kali ARM guest on M1 Mac:

The issue stems from the fact that QEMU (UTM backend) doesn't store modified EFI variables between sessions (after the VM is shut down). The Kali installer uses EFI variables to store the proper boot configuration. Luckily, we can enable this storage with two custom image files.

Download this ZIP archive: QEMU EFI for AARCH64.zip. It contains two files.

EFI_Code-AARCH64.img contains the same UEFI BIOS that is included with UTM, but in an uncompressed image. This is required for the EFI size to match what QEMU expects. EFI_VARS.img is the same size (64k x 1024) and contains zeroes (nothing).

If you want, you can recreate these images yourself using dd (in macOS Terminal):

mkdir "~/Desktop/QEMU UEFI for AARCH64/"
cd "~/Desktop/QEMU UEFI for AARCH64/"
dd if=/dev/zero of=EFI_Code-AARCH64.img count=64k bs=1024
dd if=/Applications/UTM.app/Contents/Resources/qemu/edk2-aarch64-code.fd of=EFI_Code-AARCH64.img conv=notrunc
dd if=/dev/zero of=EFI_VARS.img count=64k bs=1024

Now open UTM and open the Drives configuration for the Kali VM. If you don't have a Kali VM yet, create a new VM with the AARCH64 system, save it, then click it in the sidebar and open the configuration again. Click the Drives tab.

Use the "Import Drives" button to import both image files into the VM. Then change both to have type Disk Image and interface PC System Flash. Make sure the EFI_CODE file is in front of the VARS file in the list. It does not matter if there are other drives before these in the config, but the CODE file must be before the VARS file. This is what it should look like when you're done:

Now you have to reinstall Kali to have the EFI variables set properly. This time, the variables will be stored in the VARS file and therefore they are not deleted when the VM is closed.

[theakshat1]

Thank you so much I wasn't able to boot since last one month but it worked like charm thank you once again

[BigBrayn]

There is a faster way to do this with no install. You have to edit the startup.nsh file to link to your efi file. To do this you have to hit escape in the UEFI screen which brings up a command prompt with the name Shell> Type FS0: then edit startup.nsh, you should get a text editor. In the startup file type fs0:\efi[your install of Debian, in this case kali]\grubx86.efi(or grubaa64.efi if you have an ARM based computer). then exit the text editor with ctrl-q and reboot. Should boot into kali then.

[conath]

There is a faster way to do this with no install. You have to edit the startup.nsh file to link to your efi file. To do this you have to hit escape in the UEFI screen which brings up a command prompt with the name Shell> Type FS0: then edit startup.nsh, you should get a text editor. In the startup file type fs0:\efi[your install of Debian, in this case kali]\grubx86.efi(or grubaa64.efi if you have an ARM based computer). then exit the text editor with ctrl-q and reboot. Should boot into kali then.

Thanks for this. However I believe that while this works for some Linux distros, Kali specifically will boot into a rescue environment if you just start the grub file from the EFI shell like that. It seems to require some other parameter to boot normally, I haven’t looked into that. I know that using my method above works for Kali, for sure.

Update: apparently editing the startup script works, too. No need to reinstall if you’ve already installed Kali. See this comment.

[ajay-mandal]

Worked for me! Thank you very very much @conath ❤️

[usr-ein]

There is a faster way to do this with no install. You have to edit the startup.nsh file to link to your efi file. To do this you have to hit escape in the UEFI screen which brings up a command prompt with the name Shell> Type FS0: then edit startup.nsh, you should get a text editor. In the startup file type fs0:\efi[your install of Debian, in this case kali]\grubx86.efi(or grubaa64.efi if you have an ARM based computer). then exit the text editor with ctrl-q and reboot. Should boot into kali then.

Thanks for this. However I believe that while this works for some Linux distros, Kali specifically will boot into a rescue environment if you just start the grub file from the EFI shell like that. It seems to require some other parameter to boot normally, I haven’t looked into that. I know that using my method above works for Kali, for sure.

I have just tested @BigBrayn 's method on kali 2021-2 for arm64 and it worked flawlessly. Just to sum up, here are the exact steps:

• Get into the UEFI shell with yellow writing
• Type fs0:
• Type edit startup.sh
• Type fs0:\efi\kali\grubaa64.efi
• Hit Ctrl-q and then y
• Enter exit and reboot the VM

Kali boots without any warning, though the QEMU UEFI warning screen still shows up, but only for 2 seconds before it decides to run startup.nsh and then Kali boots without any issues.

[anvit1618]

• Get into the UEFI shell with yellow writing
• Type fs0:
• Type edit startup.nsh
• Type fs0:\efi\kali\grubaa64.efi
• Hit Ctrl-q and then y
• Enter exit and reboot the VM

this is the right order there was a mistake

[vordenken]

Works fine for me. Thanks guys!

[conath]

Beta 2.2.3 includes a fix btw

[M3D1K]

• fs0:\efi\kali\grubaa64.efi

i could not get this to work, it is saying access denied when i try to "edit startup.nsh"

[KDViper]

I had some trouble opening after creating the VM, could it be because my OS is outdated?
Big Sur 11.0.1

[conath]

@KDViper I definitely recommend 11.3 or later for UTM, it improves stability and networking.

[SH2282000]

On the last version of UTM, after running the installer you just need to modify the EFI partition to VirtIO as shown below:

[anvit1618]

you can now try the vm ware public version

[UriZafrir]

I suggest a permanent fix in #4002