On Monday, November 15, 2021, <[email protected]> wrote:
I got Debian on arm64 working in non-graphical mode. As before, I used Fedora_35 and qemu 6.0.1.
My earlier attempts follow web instructions failed, so I decided to do it the easy way and use virt-manager.
This is an GUI interface to libvirt; virsh is the cmd line version. libvirt is a generic interface to various emulation platforms, like qemu in system mode, qemu in user mode, XEN, and libvirt-LXC. What these emulator emulate is irrelevant to libvirt, so to answer your earlier question, libvirt can handle anything qemu can handle, and that includes arm64 (called aarch64). Although virt-manage gave me only two architecture choices, but that might be because I only installed those two qemu targets.
Anyway, I assumed that both qemu and libvirt with each new release have more built-in knowledge of the various emulators, like how you set up a cdrom device for iso installs. So I used virt-manager to set up a new Debian 11 aarch64 VM.
I downloaded the Debian 11 netinstall (< 320 MB); the one I tried previously was 4.4 GB. In virt-manager, I started a new machine, qemu/kvm user session, use local install media (the downloaded iso), set architecture option to aarch64, gave it extra memory and cpus, have it generate virtual disks of 30G (that is the max it will use), and then take it from there; I used user-mode networking. Install was dead easy, it just worked. It took three hours, surprising little network traffic, but that went up to 10 MB/s in places. I selected the XCFE desktop, even though I did know that graphical likely would not work. Do remember the root password you make.
The slow install is because of the apparent use of single thread, not because of network of disk access ( gave the VM 4 cpus and 4 G memory). The virtual disk in user mode will end up in .local/share/libvirt/images. If you do "ls" there, you'll the the 30G disk, but "du" will show the the actual size; in some places, like configuring the kernel, the progress on the screen did not change, but "du" showed the actual disk growing. Be patient. You have to answer some questions now and then, but largely you can do other things. At this point, you have a 80x22 screen.
In the end, it rebooted by itself, and I got a working system, inclusive network. It was fully up to date too (e.g. during the install a newer kernel was installed), and the disk was < 5.4 GB. Do add the user you created to the sudoers file, to avoid having to be root many times.
You can start/stop the VM nicely via virt-manager (the "stop" knob at the top sends a nice shutdown signal by the looks of it, not just kill it), and it also has a built-in viewer for the client. You "open" a VM, via "view", select "console" (client screen, can be GUI or character based), or "details", where you can visually change VM machine details, much like in VirtualBox; but you must enable editing the xml via virt-manager edit->preferences. If a VM is running, you must click in its console to have it grab the keyboard (like any other window), the mouse works seamlessly. Anyway, because the VM was not configured with a graphical card, I used the "details" view to Add a video card, I tried various types, but settled for now on "virtio", that seems to have a driver for it (under aarch64). If you then start the VM, you still get a character screen, but you can drag it to whatever size you want, which is handy when editing or building software.
If you install inxi (apt install inxi), then "inxi -F" will show the VM machine details as Debian detected them.
I also added a AC97 sound card to it in the same way, no idea if it will work, but inxi shows it is there.
Anyway, with this setup there is a working environment to test cinGG arm64 builds. A character-based editor would be handy, maybe "ne".
Hope this helps you with the arm testing.
thanks a lot for detailed writeup! (currently am a bit short on storage for trying proot-distro - with normal glibc and such, as opposed to termux/android bionic libc.)
MatN