Add support for AARCH64 builds via QEMU

ripleymj commented 3 years ago

This is a terrible idea and barely works at this point, but I'm putting it in public anyways.

Edit: additional thoughts.

I've got eyes on UTM.app for running this on M1. UTM appliances are a zip of a qcow2 disk image and a plist file. I haven't found a definitive reference for the plist schema, but their gallery has samples we can borrow from.
If Fusion becomes available through student licensing that may be an option, and qemu could likely convert the disk image to vmdk. The cost of Parallels makes it unattractive for use here.
The most practical build server found so far is AWS a1.metal (get a spot instance in Ohio). This also boots on RPi4 with appropriate memory sizing, but I don't have the patience to see it through to completion yet. I've done a few tweaks to get it started in emulation on x86, but it looks like about 12hr for build completion. M1 Minis are believed to available on the Scaleway cloud, at a substantial cost.
~~I've got a y86 build elsewhere~~ #458
~~I need to see if the linux*oem packages are worth the trouble of separating~~
~~spice-vdagent should probably be installed as the preferred guest additions~~
~~The firmware parameter is likely all that's separating this from Packer 1.6 compatibility. Packer externalizing plugins may be causing packaging difficulties for 1.7.~~
This is using the daily Ubuntu installer, making it a moving target. I'm open to discussion on using Ubuntu Server with the graphical packages added, but would require the switch to subiquity/cloud-init, which might be lighter weight and work better in emulation. There is also the possibility of Debian+Cinnamon, which would trade a slightly incompatible core OS for visual compatibility.
None of this should be taken as a commitment to delivering a working VM for the Fall 2021 semester, but I felt we have enough pieces available now to make an honest try at it.
~~It'd be nice to support sftp for Ubuntu. Nautilus appears to support similar syntax to Nemo for connecting.~~ #465

ripleymj commented 3 years ago

A prototype image is now available https://w3.cs.jmu.edu/uug/testing/jmu-ubuntu-fa21-utm.zip

laurelmay commented 3 years ago

So far this seems to be going pretty well. I definitely recommend against enabling Retina mode. Not sure what to call a bug because of UTM, because UTM uses an RC qemu, or because I am on the Monterey beta. I seem to be experiencing some memory leaks especially but again... not sure where to put that blame at the moment.

ripleymj commented 3 years ago

I can't reply to your other comment inline. Are you saying we need to do more to disable Retina mode, or just be sure to preserve the <key>DisplayRetina</key><false/>? You may not be alone in graphics memory leaks: https://github.com/utmapp/UTM/issues/2720

laurelmay commented 3 years ago

I can't reply to your other comment inline. Are you saying we need to do more to disable Retina mode, or just be sure to preserve the <key>DisplayRetina</key><false/>? You may not be alone in graphics memory leaks: utmapp/UTM#2720

<false/> is good enough. Just wanted to drop a note about the importance of keeping that attribute as-is.

laurelmay commented 3 years ago

Want to provide some thoughts on some of the opening comment notes:

plist schema: Not sure if that's defined with the supported keys seem to be in the Configuration/UTMConfiguration*.h files in the repo: https://github.com/utmapp/UTM/tree/master/Configuration
Parallels: I think Parallels has gotten better at importing other types of VMs (though not yet a raw qcow2)
UTM: The only issue here is when someone shows up with an ARM64 Windows machine. But as you said, ARM64 isn't totally guaranteed for the fall.
Virtual M1: This will always be expensive since the macOS license requires a minimum 24hr for hosting providers so not we'll ever be able to affordably do this natively. I am happy to offer my M1 for building images if we want to do this "natively"
Base OS: I'd rather stick with Ubuntu that try to test our Debian support. Might be fun to bring up Bullseye along with 22.04. I really hope we see Mint add ARM64 support but that feels unlikely. I don't want to do Ubuntu Server unless we make that the default for all Ubuntu. I mean... we could do Ubuntu desktop but apt install cinnamon...

Finally, is there any way that we could move 2c0c7c7 to its own PR so that we can have that fix in place for the fall image regardless of the status of this change set? For that also, ! -z == -n

jmunixusers / cs-vm-build

Add support for AARCH64 builds via QEMU #457