Did you ever manage to start an interactive getty on the console?

[deitch]

Did you succeed? What device did you use? It looks, based on your description, that it should be /dev/hvc0, but that doesn't seem to do anything.

[cfergeau]

I can interact with the VM terminal after starting it with example/virtualization if this is what you are asking?

[deitch]

Hmm. Then I'm wondering what I'm doing wrong.

I'm running it not with a standard distro, but with a composed minimal one. It's got a small script to read cmdline and determine where to start getty. Yet despite starting several - including to /dev/hvc0 - nothing is interacting.

Do you know what device the actual console is using?

[deitch]

It turns out to be using hvc0, as we suspected; I had permissions wrong on my getty in the minimal OS. This part is fine now.

[deitch]

Actually, I tried your approach. I just built from example/ dir, pulled down the Ubuntu 20.04.3 iso, extracted the vmlinuz and initrd, set them to env vars, and tried to boot it. It just sits there.

[cfergeau]

You must gunzip the kernel or it will just sit there indeed. (forgot if this step is m1 specific, or is also needed on x86_64)

[deitch]

It is an arm64 issue. For some reason, arm64 kernels are gzipped (which qemu and others can handle, but macOS VF cannot 🤷‍♂️ ) while x86_64 use built-in compression.

It isn't that, I definitely was using an extracted kernel.

[deitch]

The uncompressed kernel requirement is well-documented at kernel.org. Apparently qemu can handle this, because qemu unzips the kernel in memory, and then passes that memory pointer to the VM.

Since it is an NSURL under the cover, using a FileURL here, we could use a URLWithString with base64-encoded data.

Would you consider an option to pass a []byte to NewLinuxBootLoader ? Or at least a base64-encoded string?

[deitch]

Proposed a PR, see #27