You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Did you ever manage to start an interactive getty on the console? #25
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?
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.
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.
Repository owner locked and limited conversation to collaborators on Feb 24, 2022
Activity
cfergeau commentedon Feb 23, 2022
I can interact with the VM terminal after starting it with example/virtualization if this is what you are asking?
deitch commentedon Feb 23, 2022
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 commentedon Feb 23, 2022
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 commentedon Feb 24, 2022
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 commentedon Feb 24, 2022
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.