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