<br><br>On Friday, November 12, 2021,  <<a href="mailto:mnieuw@zap.a2000.nl">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">Andrew, thanks for the links. I followed mostly the procedure of<br>
the DVD:<br>
<a href="https://blog.lazym.io/2021/04/16/Run-ARM-MIPS-Debian-on-QEMU/" target="_blank">https://blog.lazym.io/2021/04/<wbr>16/Run-ARM-MIPS-Debian-on-<wbr>QEMU/</a><br>
<br>
Still, it took almost 2 hours until it was finished, that was after<br>
downloading the ISO. Host CPU load was rarely above 15%, and host disk<br>
access was almost absent. ISO version was as specified in the<br>
procedure, but further in the procedure is the wrong version (easy to<br>
correct).<br>
<br>
Some notes:<br>
1) I tested this on Fedora_35 with the latest qemu 6.1 release.<br>
2) The procedure specified system-arm, that does not exists (anymore). I<br>
used aarch64. I specified 4G memory, 4 CPUs.<br>
3. I did not do anything from that procedure regarding networking.<br>
Fedora has by default a bridge device setup, and it simply worked,<br>
looked fast too (not measured). I did see it going out during the<br>
install, and network detection and dhcp was very quick.<br>
4. I did follow his procedure regarding the cdrom, but it is possible<br>
this later qemu version has a working cdrom device. TODO.</blockquote><div><br></div><div>found this remark in debian bugtracker:</div><div><br></div><div>---</div><div>USED QEMU COMMANDS (All options should be on single line; SCSI seems </div><div>necessary for Debian installer to detect CD-ROM properly on ARM64):</div><div><br></div><div>qemu-system-aarch64</div><div> -nographic -machine type=virt</div><div> -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd</div><div> -netdev user,id=vnet,ipv4=on,ipv6=off,hostfwd=tcp::60010-:60000</div><div> -device e1000,romfile=,mac=52:54:00:12:34:56,netdev=vnet</div><div> -cpu max -smp cores=1 -m 1024</div><div> -device virtio-scsi-pci</div><div> -blockdev driver=raw,node-name=hd,file.driver=file,file.filename=HD.img</div><div> -device scsi-hd,drive=hd</div><div> -blockdev driver=file,node-name=cd,filename=DEBIAN-NETINST.iso</div><div> -device scsi-cd,drive=cd</div><div>---</div><div><br></div><div><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990190">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990190</a></div><div><br></div><div>but apparently by itself this line does not give you graphical/kbd/mouse enabled VM... </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. During the install near the end I was asked if I wanted to install<br>
some extra utilities, but it failed when I tried it. In the end, the<br>
qcow2 diskfile was 1.6G, quite small.<br>
5. To extract the boot kernel and initrd I did not use sudo as<br>
specified with virt-copy-out, failed for some reason. Without sudo it<br>
was fine. His command virt-ls was nowhere to be found (not in the<br>
package manager), but during the install I noted the exact version<br>
numbers and used those.<br>
6. After installation the system restarted itself, but because the<br>
qemu parameters were still those from the original start, it came back<br>
to the installer. I just killed it.<br>
7. When starting the system with the supplied example (with adapted<br>
kernel/initrd numbers) and 4G memory, it starts fine to a cmd prompt.<br>
But networking does not work. Possibly it will if I use the same <br>
networking parameters as when doing the install. Even ifconfig was not<br>
there.<br>
8. When using virt-manager, you can create a new VM (in virt-manager)<br>
from an existing OS image (the .qcow2 file in this case). But it boots<br>
an UEFI (and that doesn't react to kbd entries, likely because unlike<br>
a PC boot, it cannot setup kbd/mouse for this "virt" VM), and apparently<br>
the image is not set up for that. But it does generate a .xml file with<br>
lots of details, more than specified on the cmd line from the<br>
instructions. I suspect I can modify it to not use an UEFI firmware<br>
file and associated nvram file (this is how it works normally), but use<br>
directly the supplied kernel/initrd.<br>
<br>
So, quite nice so far. Networking next, else this is unusable for<br>
testing (the building of) an ARM version of CinGG.<br>
Is there no video-like device anywhere in this "virt" arm machine?<br>
Shouldn't one be able to have an "headless" Debian with a GUI terminal<br>
on the remote end (in this case the host)? <br>
<br>
MatN<br>
</blockquote>